Cloud Security ~ Why Use a VPN for Remote Administration?
Any time you are using public wifi, or in other words a network you don’t own and secure yourself that allows anyone to connect, it’s a good idea to use a VPN (virtual private network). A VPN provides an authenticated, encrypted connection that hides information in about the sites you are visiting from attackers. This protected connection makes it harder to intercept your connections, steal or read your data, or insert attacks into the traffic as it flows from your system to other sites.
To give you an idea what I’m talking about, let me first show some information retrieved by a sniffer when I navigate to Amazon.com in a web browser. When visiting this site, many different URLs are used to pull together the content you see when you visit the home page. One of the domain names is read.amazon.com. If I run a sniffer while visiting that web page, without a VPN, I can see the request to this domain name in plain text.
As an attacker there are many ways I can use this information, not to mention any other information sent clear text in payloads of other packets. On an insecure wireless network, anyone with a sniffer could see this traffic. Even on some of the newer, more secure networks, there may be ways for an attacker to intercept and view this data.
Now let’s look at what I see when connected to an IPSEC VPN. All the packets pretty much look like this — because the data is flowing through an encrypted tunnel:
In addition to limiting exposed data while using an insecure network, A VPN also allows network administrators to create firewall rules for your company systems, to allow traffic only from the VPN connections rather than the whole Internet. Why does this matter? Any time the network rules expose a host to the Internet, any open ports will be scanned and attacked. You can reduce the “attack surface” (what an attacker can attack) by limiting what you expose to the Internet to only what is required. I talked about this in a presentation on AWS network security at our AWS meetup in Seattle. Here’s the most critical slide:
If you don’t believe your systems are subject to attacks when exposed to the Internet, go into your AWS account right now. Start up an EC2 instance. Turn on VPC Flow Logs and wait about 5 minutes. Then look at all the traffic that is trying to hit the system you just turned on in the VPC Flow Logs. Next, turn on SSH or RDP and open up the network to provide access to those services from the Internet. Turn on Amazon GuardDuty. Then wait to see how long it takes GuardDuty to report RDP or SSH brute force attacks. In most cases, it will be less than one day, if not less than one hour.
What if we need to allow someone to administer a system running on AWS, Azure, or Google Cloud from varying remote locations but don’t want to expose SSH and RDP to the entire Internet? One option would be to provide VPN access, which allows the person to connect from anywhere on the Internet to the corporate network. Then only allow access to the Bastion host via RDP or SSH from the corporate network. The VPN will be another layer the attackers have to get through before they can get to RDP or SSH.
One concern with a VPN is the fact that traffic has to be back-hauled back to the corporate network however some creative cloud architecture solutions could get around this problem. Another issue is that you’ll still need to protect your VPN endpoint from attacks similar to those used while cloud penetration testing to simulate real-world attacks. You should implement two-factor authentication with your VPN solution and ensure you are using a secure VPN configuration.
Teri Radichel — Follow me on Twitter @teriradichel