What are best practices regarding remote access to work? There’s a VPN to connect (Fortigate) - and then what? Letting users directly map a share from vpn is bad? Allowing them to rdp is bad?
We are looking to make the whole “work from home” deal as easy as possible for users but at the same time to keep as secure as possible. Users would want to VPN to corporate and from there to feel as if they were in office: map a network share as a drive, and that’s basically it. There are a few apps that work in browser, through http or https, and thst’s basically it. They also have o365 so they can use mail (Outlook) and word/excel/etc.
There’s the vpn, users have a client that they log into and connect to your firewall and that brokers the connection to internal resources through a split tunnel (unless you want to backhaul all internet traffic through your firewall).
Or look into a ZTNA solution like zscaler or iboss that have private access tunnels that are always on, and the user can just log in and go.
You haven’t said what computer the users are connecting from. Are you allowing them to connect using their own personal PCs, or are they provided/managed by your company? If their personal PCs, then you’re in for a world of security and data protection nightmares. Once they connect to the VPN, any malware on their personal PC now has full access to scan your network (ever noticed how many more ransomware attacks there are these days?).
This is why many people use an RDP gateway instead of allowing direct access, as that gives you a very clear separation point between the personal and company computers/networks.
Modern VPNs are cloud based to be honest, I see ZTNA was mentioned here and that’s the path forward. Sase/Zero trust VPNs which give access to just the ports needed per user after things like antivirus is evaluated.
If you Google SASE + vendor names it should show you some ideas
Proofpoint Meta,
Zscaler,
PaloAltoNetworks,
Netskope,
Check Point,
Cloudflare,
Cisco
I see you already have MFA enabled for VPN access, that’s excellent
You should also lock down the VPN policy so that you have to be a member of a specific AD group to login to the VPN vs allowing every account in AD to be able to authenticate. This avoids common service accounts like Administrator and BackupExec (You’d be surprised how often I still find that account in customers ADs) etc from having VPN access as those are common targets for brute forcing.
Some of my customers maintain a terminal server jumpbox that all remote users are expected to use while working remotely, but this is rare. This is more for customers that already use a Terminal Server Farm for deploying apps to desktops or thin clients, so remote access becomes an extension of that.
Mostly just restrict your users VPN policies so that they only have access to the resources they need such as DCs, Fileserver, specific ports on the Database server for their apps, etc. You can go further and block access to RDP/SSH ports etc to slow down a potential hacker.
You can apply the same security policies to most users, just isolate IT people into their own policies.
IT staff by definition have more wide range access via VPN, but using an RDS jumpbox for IT staff may be preferable than opening up your entire network to a VPN tunnel. Use different accounts for Admin access vs the IT guys regular account for Email + VPN login, that way if a hacker breaches one of those accounts their access will be quite limited vs having all the keys to the castle.
If you have your servers on a separate LAN from your desktops you can easily allow RDP access to the users desktops if they prefer to work that way, but most remote users these days have laptops anyway so they just need access to their resources.
That’s pretty much it, that’s how we’re planing it.
But one colleague from another company said they’re using 2fa for vpn, then users have to rdp to jumpserver (and nowhere else, only thing allowed there is that server on port 3389) and there they (users) have to authenticate on domain, and from there they do another rdp to some workstations that are inside the corporate network, and work like that.
Seems like an overkill to me (us), we’d like to just use 2fa and vpn client (which also checks user’s workstation for patches we decide, for antivirus we decide which has been last updated at least x days ago (again we decide) and only then does it let vpn to connect. From there we’d (ideally) allow them to connect to a coulle of shares on a couple of servers, access said http/https apps we have internally (not open to outside in any way) and we’d cut internet traffic except for that needed for o365 to work correctly.
Valid point.
Users will only have company laptops for VPN. There are, however, a few of app vendors that use vpn, occasional IT stuff that might use a non-company laptop, but “ordinary users” would only use company-provided laptops (locked usb ports, no local admins, antivirus/malware regularly patched, windows patched etc)
Thanx for the input - there is 2fa already to establish vpn. It’s what should happen after that, after the vpn is set and connected, is it safe to allow pretty much everything that is allowed in the office or not…
I guess I would question the necessity of that. Is it for security reasons or for lack of networking experience? The point of 2fa is to have two levels of access, password and device. Seems just easier to mimic the office environment in the home. Also, how many people are using that jumpserver at once? Do you have multiple? How much resources is it/they consuming? What happens if the jumpserver goes down? Seems like a single point of failure that you want to avoid in the office or out.