Why All The So-Called VPN Replacements Are Not VPN Replacements

ACM.473 Taking a closer look at AWS Verified Access and How It Works Compared to An IPSEC VPN — should you use it?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Network Security | AWS Security | Cloud Architecture

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is part of my series on configuring a Site To Site VPN from pfSense to AWS using a Virtual Private Gateway or a Transit Gateway. All the links are at the bottom of this post:

In the last post I showed how to set up a Transit Gateway and connect it to pfSense with proper routing to send all traffic out via a NAT.

However, this solution is a bit pricey for small businesses and home network operators.

Some companies are offering what they call “VPN Replacements” at times. They supposedly cost less and the term “VPN-less” or “VPN replacement” seems to imply that these solutions are just as good as a VPN and offer the same level of security. But do people using these solutions actually understand the difference between what a VPN solution is doing and what these so-called replacements are doing? Just to make sure you are making an informed decision let’s dig into the details a bit more.

An IPSEC VPN is a TUNNEL

I explained down to the packet level how an IPSEC VPN works and how it protects data flowing across your network.

• An IPsec VPN (which is different from an SSL VPN) is a tunnel. It encapsulates all your packets in that tunnel.
• That tunnel encrypts all your data within that tunnel including the sending and receiving host information.
• That tunnel sends every single packet of any type of protocol because it doesn’t know or care what protocol is in the packet. It encrypts the packet and forwards it along. So it can send DNS traffic, HTTP and HTTPS traffic, TCP, UDP or anything else and encrypt all the data in the packet as it forwards it through the tunnel.
• It prevents an attacker from being able to see the host (via IP addresses) that are sending and receiving data to and from each other because it encapsulates and encrypts entire packets.

• If you use it with a NAT as I’ve described in this series, the private IP addresses of the hosts are hidden from the destination host. All it sees is the NAT endpoint IP address.
• A Site to Site VPN prevents an attacker from obtaining access to your network from the Internet. The attacker cannot get through the VPN without first getting onto a host that has access to send data through the VPN. In my case, I set up a very specific IP range allowed to access the VPN from my local network. I can create very specific firewall rules both in AWS and on my local network to disallow unwanted hosts from connecting to my resources.
• An IPsec VPN works at the IP layer of the packet. Meaning it can stop potential infiltration based on an IP address before the attacker gets to the application layer. If an attacker wants to attack a VPN they have to do something at the point of tunnel establishment to cause a connection to the incorrect host or to downgrade or break the encryption somehow. Once the VPN is established there is not a lot to attack that an attacker can manipulate.

Most of these other services work at the application layer. They are going to send data farther down in the packet and can infiltrate and break applications with malicious inputs. There is a much larger attack vector at the application layer than there is at the IP layer of a packet. Trust me. I’m a penetration tester and I have found high risk vulnerabilities (meaning an attacker can use that vulnerability to take over systems, steal credentials, deploy malware, or exfiltrate data) on systems of every client for whom I’ve performed a test.

When you’re using a VPN you can eliminate some attacks far upstream from the systems the attackers are trying to scan for vulnerabilities and inject with malware. If they are on the Internet, not your private network, their data never even makes it to your application to try to attack it. Their packet gets dropped or rejected way before that point.

AWS Verified Access

As far as I can tell, AWS verified access is similar to other solutions from Zscaler, Azure, and GCP that evaluate requests in detail to determine whether a request should pass or fail. Here’s the description from AWS:

AWS Verified Access evaluates each application request from your users and allows access based on:

Trust data sent by your chosen trust provider (from AWS or a third party).

Access policies that you create in Verified Access.

When a user tries to access an application, Verified Access gets their data from the trust provider and evaluates it against the policies that you set for the application. Verified Access grants access to the requested application only if the user meets your specified security requirements. All application requests are denied by default, until a policy is defined.

In addition, Verified Access logs every access attempt, to help you respond quickly to security incidents and audit requests.

This sounds like something operating at the application layer.

• It does not prevent routers from viewing source and destination IP addresses.
• It does not prevent man-in-the-middle (MITM) attacks as the packet flows over the Internet by injecting something into the original packet. There are other types of these attacks that would work in any case should an attacker get onto an endpoint. More on MITM attackers here:

• It allows the attacker to get all the way to the application layer before it stops the attack, so any vulnerability in the policy engine or logic could lead to an intrusion or exfiltration of data. This is a much greater attack surface than checking an IP address to see if it is on the private network — yes or no.
• It does not protect other protocols like DNS, ICMP, and anything other than what is destined for this application from prying eyes.
• It does not prevent tunneling data or sending commands through DNS, ICMP, and other protocols that may be used on your network.

So no, it is not the same as a VPN at all, nor is it a VPN replacement. Does that mean you should not use it?

No!

Let’s look at what this service can do that a VPN cannot do.

With AWS Secure Access you can integrate with third parties and create much finer grained policies than you can do with a VPN. For example, here’s a policy that is integrity with Jamf, a solution for security Apple devices. Jamf has various methods of determining whether a device is following your specific security policies and determines if the device is low or high risk. Your policy in AWS Secure Access can decide to reject the request if the device is high risk, for example.

You can’t do that with a VPN. But as you can see above, there’s a lot more for me to attack in that policy. I can try to insert something that tries to get Jamf to evaluate the system as low risk when it’s high risk. I can try to insert something in the email address field to perform all sorts of attacks. I can create all manner of malformed policies to try to break something, anything in that process.

You can do the same thing with network packets, but my options are more limited when it comes to breaking into the VPN. Most of the time VPNs are exploited because they use insecure configurations or the VPN software has a vulnerability which the user hasn’t patched. VPNs are often exploited so it’s really important to keep them updated. I explained VPN configurations in more detail in this post:

Limit the VPN to the IP addresses that need to communicate and the highest level of encryption both sides support.

So it seems to me that AWS Secure Access isn’t a VPN solution at all. But it’s a very powerful security tool which is similar to Microsoft Conditional Access which I loved from the start.

I would recommend combining the two. By doing so you can drop a lot of noisy scammer and scanner traffic right off the top.

You also protect your remote admin access when zero day vulnerabilities come out that require fast patching or system configuration updates like this one:

On the other hand, if an attacker somehow gets onto your network, you can perform a deeper level of inspection using a policy-based service to prevent complex attacks based on anomalous information in the request.

Why not both?

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2024

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab