VPNs are supposed to be a secure remote access solution for your customers, but have you done enough to protect them? A VPN’s primary purpose is to is to provide an encrypted tunnel prevent eavesdropping. VPN’s by themselves cannot stop a myriad of cyberattacks into corporate networks that are launched from the remotely connected system.
If you take a moment and think about the recent infiltration of CCleaner, hackers could have easily remotely installed a keylogger to grab usernames and passwords remotely. It has been less than 5 years since both USPS and Target were victims of stolen VPN credentials.
There are additional steps you need to evaluate and deploy to further secure your customer environments:
Enabling 2Factor authentication is one of the strongest protections against compromised credentials, but 2FA won’t stop hackers from surreptitiously attacking the corporate network from the remote computer while the VPN is connected.
Geo Block VPN access
If user credentials are compromised this prevents the use of the VPN from countries other than those you allow. Just remember to keep this list as short as possible.
Use firewall rules to restrict what remote resources are accessible over the VPN. Ideally this would be a situation where only the necessary applications , firewall ports, and remote subnets are opened.
User accounts should be temporarily locked out if there are too many password guesses in a short time period. You should also see if you can setup alerts so that you can review the relevant logs to determine whether this was a brute force attack and possibly export those logs for future reference.
Security services for VPN traffic
Minimally Antivirus scanning and Intrusion Detection should be turned on and scanning all permitted traffic.
Single concurrent tunnel per user
Check and see if the customers firewall supports limiting users to a single concurrent tunnel. This would provide a layer of protection and possibly notification if the user account is being used at two different locations at the same time.
Logs need to be periodically reviewed for the following:
- Unusual day or time of access
Looks for patterns of successful or attempted logins that may be unusual. One example is if a user attempts to login when they are already at the office. Another example is if a user attempts to login during the early morning hours when they may be sleeping.
- IP addresses outside of the United States
Any successful logins from outside the customers home country should raise an immediate red flag for review and confirmation whether it is a legitimate session.
- Analyze successful user logins for different IPs used
Build a list of user ids to public IP mappings so you can build a history of what is normal and determine what may be abnormal.
- Password brute forcing
If you see evidence of brute forcing, then there is a high likelihood the customer may be targeted.
- Indicators of Compromise
IOCs are one or more signs that a system is compromised. This involves combining analytics with investigative techniques to determine what is normal or abnormal. Sometimes this can be as obvious as IDS flagging a system is trying to communicate with a botnet, or an inconspicuous as the remote system trying to talk to a malicious DNS server.
You can automate a number of the log file analytics by having the firewall send logs to a syslog server and into a database. From there a number of scripts can be written to automatically tag IP addresses with GeoIP information as well as accumulate statistical information.
Stay ahead of your competitors by taking the time to do more than they are!