A Dynamic VPN Defense Guide

VPNs are under active and ongoing attack. This is not only due to a near-constant stream of VPN-related CVEs, but also due to what appears to be a growing tactic of using leaked enterprise VPN account user names. Anecdotally, in just the past few weeks, I’ve heard of several enterprises whose VPNs are under attack via a low tech password spraying method. The criminals behind these attacks don’t have enterprise users’ passwords, but apparently have, or have figured out, valid enterprise usernames, and are using those to attempt to log into VPN. This results in an effective denial of service attack, either by causing account lockouts after N invalid authentication attempts, or by overloading the VPN server.

I’ve had a number of conversations with enterprise security teams about this, and have come up with a set of defense (or at least mitigation) mechanisms described below.

The best, right answer is to move away from VPNs entirely. Migrating to a modern remote access method – Zero Trust Network Access (ZTNA) – eliminates open ports, and makes it so that this type of attack is not possible at all. This is, by far, our preferred defense here, but we know that that is not always possible to achieve immediately. So consider the approaches below as “Band-Aids “, potentially useful for the short to medium term. Ultimately, we strongly recommend shifting over to ZTNA as quickly as reasonably possible.

We’ve put together this helpful flowchart as a VPN Defense Decision Tree, to guide you through the process of deciding how to best defend your VPN (and – hopefully sooner rather than later – replace it). For the remainder of this blog, we’ll be walking you through the decision tree, with commentary and context.

Your first task, of course, is to determine whether your VPN is currently under active and disruptive attack.

It’s important to distinguish between ordinary, everyday nuisance probes of your VPN server, and more concerning activity – which includes failed user authentications, volumetric denial-of-service attacks, or attempts to exploit flaws in your specific VPN version.

The key here is to determine how disruptive your current situation is, in order to in turn determine the appropriate level of urgency and resource allocation. 

Several of the enterprises I’ve spoken with are seeing ongoing and active login attempts by the threat actors, with valid usernames but guessed passwords. These password spraying attacks generally do not result in successful logins, but they do unfortunately result in disruption. Specifically, users’ accounts are being locked out after several failed login attempts, and in some cases, VPN servers themselves are getting overloaded by the attempts. 

So do this assessment, and determine your currency state. If you’re not being actively attacked…

If you don’t have an urgent situation, use this time to plan for how you will migrate away from your VPN to a modern and much more secure Zero Trust Network Access solution. If you’re looking for guidance on this, we offer a free Zero Trust Strategy Kickstart session – get full details and sign up here.

If you are under active and disruptive attack, our next question is:

This question determines how you need to defend your enterprise. A volumetric attack means that the threat actors are “flooding your pipes” with data, and overloading your upstream network circuits. If this is the case…

This type of attack has to be defended by an upstream service provider – by the time a large volume of network data is hitting the front door of your network, it’s too late. So evaluate your ISP, and CDN (if you have one) to determine the services they offer, and whether they can help you in a cost-effective and timely manner.

In addition, evaluate whether your VPN needs to be listed in public DNS. In many cases, you can simply remove it, so that attackers will no longer see the IP address associated with vpn.company.com, and recognize it as a target. Clearly, you’ll need to test this to make sure that using an IP address only is compatible with your VPN system and the surrounding systems that make use of it. Yes, this is to some degree “security through obscurity”, but everything you can do to eliminate attacker visibility into your environment helps.

If this is not a volumetric attack, but instead is  something that takes the form of many attempted logins, the next question is to evaluate where the traffic originates from, and whether it lends itself to simple blocking.

If the attacks come from an easily recognizable and repeatable set of source locations, then you should be able to effectively set up block rules on your firewall. These rules should naturally be tailored to the source locations that you’re seeing, but are often drawn from specific countries, TOR exit nodes, and even IaaS IP ranges.

Of course, especially for IaaS blocking, you need to test those carefully, as those IP ranges are used for significant amounts of legitimate business. But blocking TOR exit notes, and traffic originating in countries in which you don’t do any business are easy decisions to make, and should have a very low likelihood of disrupting legitimate network traffic.

If you’re seeing disrupted activity from an unpredictable set of IP addresses, then you need to implement a form of dynamic VPN defense.

The idea behind this concept is that we take a halfway step toward ZTNA by implementing a mechanism that hides the VPN server from unauthorized entities (this is sometimes referred to as cloaking). We’ve identified two ways to accomplish this, which we’ll talk you through below. These two approaches, while different, share a common concept of deploying a default-deny firewall in front of the VPN server. This firewall blocks all unauthorized users, and makes the VPN server invisible and inaccessible to threat actors. The systems then utilize an out-of-band mechanism to identify legitimate users’ IP addresses, and add firewall rules to allow traffic from that source IP address through.

Let’s take a look at the two scenarios we’ve outlined. 

Using a SaaS Service Desk to Uncloak VPN Server

Our first scenario utilizes a SaaS-based service desk platform. Because it’s SaaS, it’s globally accessible to your legitimate users, and likewise, you will have already set up a strong user authentication mechanism. That is, you have a high degree of confidence that a user in your Service Desk tenant is in fact a legitimate user. 

In your service desk environment, create a simple form for users to submit a request for VPN access. These platforms generally all have scripting APIs, and can pull the user’s IP address into the submission process. Then, use the platform to make an API call or assign a task to your IT helpdesk, to update your firewall rule to allow that user’s IP address through to the VPN server.

While this does require a small amount of scripting or coding, it’s relatively lightweight and pretty simple. Even the manual ticket-based approach can work if you have a relatively low volume of users. One side note to think about is the lifespan for these allow rules. Users’ home IP addresses are typically long lived, so a longer timeout (say 30 days) is reasonably low-risk. Even for public locations, a multi-day period is also reasonable. It’s very unlikely that a malicious actor will be in the same coffee shop or airport lounge as your end user. In all cases 15 to 30 days is probably a safe timeout period, balancing out user convenience with pruning of your firewall rule sets.

If you don’t have a SaaS-based service desk, or are looking for an alternate solution, we’ve outlined a second approach below. This alternative uses a concept called Single-Packet Authorization (SPA). Also known as network hiding, this approach utilizes a simple but effective form of cryptography to identify legitimate users and cloak the VPN. Let’s dive in.

Using Single-Packet Authorization to Uncloak VPN Server

Single-Packet Authorization (SPA) is a concept that was popularized as part of the Software-Defined Perimeter specification from the Cloud Security Alliance. SPA utilizes a cryptographic secret that’s shared between user devices (clients) and the SPA server, and is used to generate a one time password. This password is embedded in a single network packet, either UDP or TCP, sent from the client device to the SPA server. If the server recognizes this as a legitimate, and new (un-replayed) SPA packet, it modifies its firewall to allow traffic from that user’s source IP address through. All the user device needs to do is to run a quick command to send the SPA packet. Then, their network traffic will be allowed through, so the user can then operate the VPN normally.

There are a number of commercial products that implement SPA, but they tend to be part of a larger platform solution. For this particular use case we recommend using the open source SPA implementation, the Firewall Knock Operator (fwknop), available here.

With this approach, you can set up a simple linux server to host the SPA server, and deploy it in front of your firewall. Then create a simple script or quick-launch icon for your users to run just before they log into the VPN. 

Conclusion

Threat actors are an annoyance, and a disappointing aspect of human nature. However, as information security professionals, this is what we signed up for. We hope that this guide and the associated PDF link are useful for you, and will help you both better defend your VPN, and begin planning for your migration away from it.

If you’re interested in talking through this further, getting access to our technical step-by-step guide for the SPA solution, or obtaining some help in planning and executing this, reach out to us at info@numberlinesecurity.com, or via the form here.