“We’re network engineers. We’re not supposed to be this popular,” my beleaguered colleague said.
While the economy is clearly taking a hit in the world of COVID-19, we have seen a slight bump in service requests here at Mirazon. The number–one request? Remote access: VPN, RDS, Citrix, you name it. The vast majority of users that can work remotely are working remotely.
10 years ago, this would have been harder to pull off. Fifteen to 20 years ago? A nightmare. Have you deployed an RRAS server with modem banks? Shudder. Working remotely is convenient, but it is a change of pace and how we do business. Do you know who things are business as usual for? Hackers. As a matter of fact, that business is booming.
Networks that were locked down now have just a little bit more to exploit and with direct access to boot!
Here are some guidelines for allowing remote access without making yourself complete vulnerable:
Direct Internet RDP access is not a solution.
Don’t. Do. It. Period. RDP’s vulnerabilities go beyond exploiting weak passwords. The protocol itself is vulnerable. There has been something of a renaissance in RDP exploits since people tend to open it up in Azure and/or AWS. Instead of opening TCP port 3389 to the world, deploy a proper RDS environment with RD Gateway. RD Gateway tunnels the traffic through a secure connection and the full RDS deployment leverages network policies to secure your remote desktop access.
Use secure passwords.
Good passwords are the first line of defense in protecting your systems. Passwords should be unique, of length, have a level of complexity, not be repeated. Diversity is our strength especially when it comes to passwords. Don’t use the same password on multiple systems. If a door has seven locks that use the same key, the door only has one lock.
Speaking of passwords, use a password/account policy.
You should enforce password length, resets, etc. Additionally, you should enable your account lockout policy. You don’t need to do anything crazy like lockout after two or three attempts. If you have ever seen security logs during a dictionary or brute force attack you will see dozens (even hundreds) of failed login attempts. You can easily set your lockout policy to lock an account after 10 failed attempts in five minutes. You can even have the account unlock on its own. You’ll generate helpdesk calls, but it can clue you in to an attack.
Use Multifactor Authentication (MFA) where you can.
MFA can be implemented with your VPN, Citrix and other systems. A system protected by MFA is prohibitively hard to exploit when passwords are compromised.
Use real certificates.
RD Gateway, Citrix and SSL VPNs use certificates. Out of the box most systems come with self-signed certificates out of the box. These are the certificates that give you an error message and warning. Those are there for a reason. It is impossible to guarantee that certificate was legitimately issued. If the certificate was issued by a bad actor, none of your traffic is secure.
Secure your VPN.
I have a personal preference for IPsec VPNs. I hold this opinion due to the deluge of security vulnerabilities that are constantly discovered with SSL. Use modern protocols. Use Active Directory integrated authentication. Use MFA.
Consider not using split-tunneling. Split-tunneling eases the load on your network but does not protect systems that are connected to your network. If you backhaul all your users’ traffic over the VPN you can control what is accessed. With split-tunneling, a system can get compromised, communicate with a botnet AND be connected to your network. Also consider using Network Access Control to make sure systems are secure (patched, modern AV, etc.) before being allowed to connect.
These steps seem daunting but are simple to deploy. Security does not have to make things hard to use.