Protect Your VPN by learning from DDoS attack test

In the wake of the COVID-19 pandemic, many IT organizations find themselves scrambling to meet the sudden spike in VPN traffic as most employees are choosing to (or have been mandated to) work from home. Unfortunately, this also presents a golden opportunity for malicious attackers to disrupt their targets by launching various types of attacks on the enterprise VPN infrastructure itself.

Most organizations use old, antiquated remote VPN applications and concentrators which work in a hub-spoke architecture. This is because VPNs were always considered to be a “fill the gap” piece of the IT infrastructure, meant for workers on business travel or for people accessing the company resources off-hours. The traffic expected to come thru the VPN was a small percentage of the total IT traffic.

A pharmaceutical industry customer actually prepped for this day. They anticipated a situation wherein most of their workforce would have to work from home and they designed their DDoS defenses around this assumption. Not only that, they hired an external DDoS testing company to run attacks on the VPN infrastructure to measure the resilience of the different components.

Some lessons learnt from the DDoS attack run on their VPN infrastructure :

Lesson #1: It is easy to exhaust resources on VPN concentrators and firewalls, even with a low volume attack.

Even at an attack volume as low as 1 Mbps, a fine-tuned TCP Blend attack–where the attacker sends a small amount of TCP packets with the SYN flag checked, another batch of TCP packets with ACK flag, another set of URG packets, and so on–was able to bring the network firewalls to a state where they could handle no more new connections. Most DDoS defenses do not trigger because the volume thresholds don’t trigger.

To protect against this type of attack, you need to tune your hosts, your firewalls and your DDoS policies. Many network firewalls have a “SYN defender” or “embryonic connection” feature, which can protect against SYN Floods. For the DDoS policy, use features which allow out of state packet detection and prevention.

An on-premise DDoS mitigation appliance will generally allow more options for fine-tuning during an attack than a cloud-based DDoS service, as the policies are completely in the customers’ control and not shared with other customers in the cloud. Finally, if you use rate limiting, it is best to set thresholds that match your expected number of VPN connections; many mitigation device have default parameters which don’t always work well for VPN applications.

Lesson #2: SSL VPNs are susceptible to SSL floods, just like your web servers.

Two of the DDoS tests were variations of an SSL flood attack. The first attack was a high-volume SSL connection flood. This attack tries to exhaust the server resources using a high volume of SSL handshake requests.

To protect against this attack, stateful devices like firewalls, VPN concentrators and load balancers should be carefully monitored for TCP sessions and states. Also, creating a baseline and setting up alerts against those baselines will help during troubleshooting during an actual attack.

On the firewalls, use features like “concurrent connection limit,” and reduce session timeouts for connections without any data packets. On the DDoS policy, allow a limited number of connections to be established concurrently from a given source IP address. Also, reduce session timeouts to free up the connection tables on the firewall.

Patented defense mechanisms  can help with SSL floods – both on-premise and in the cloud. DefenseSSL identifies suspicious traffic using behavioral analysis and then activates the in-the-box SSL module for decryption. Via a set of challenge response mechanisms, applied only to the suspicious traffic, the attack is identified and mitigated. If the client passes all the challenges, subsequent HTTPS requests are allowed to reach the protected server directly, thus creating a new TLS/SSL session between the client and the protected SSL server.

This unique deployment model enables a solution which introduces zero latency in peace time and minimal latency under attack – only on the first HTTPS session per each client. For scenarios where it is not possible to use a certificate for decryption, behavioral SSL protection can be used. This can protect against SSL floods without decrypting the SSL connection.

 An SSL/TLS renegotiation attack takes advantage of the processing power needed to negotiate a secure TLS connection on the server side. It sends spurious data to the server or constantly asks to renegotiate the TLS connection, thus exhausting the server’s resources beyond its limits.

To protect against this attack, disable SSL re-negotiation on the server. Weak Cipher Suites should be disabled as well. Another option is to use SSL offloading using high capacity external load balancers to relieve your firewall or VPN concentrator. Radware can protect against this type of attack in both on-premise and cloud-based deployments.

Lesson #3: VPNs are susceptible to UDP floods.

Two of the attack scenarios included UDP floods. One was a randomized UDP flood and the second was an IKE flood. IKE is used for IPSec VPNs for authentication and encryption.

Because the UDP port numbers are randomized, use a behavior-based DDoS defense mechanism. 

Lesson #4: Monitoring and alerting are mandatory.

Mitigation of many of the attacks conducted needed real-time visibility and tuning of parameters on the DDoS policy as well as on the network firewalls and VPN concentrators. To tune the thresholds accurately, it is imperative to have a thorough understanding of your normal VPN traffic, both the volume (in Mbps or Gbps) as well as the normal number of connections that are expected. Monitoring connections on different devices can be easier with a SIEM. Also, real-time measures like reducing session timeouts and rate limiting work best if you know the normal baselines.

While the above lessons were from a controlled DDoS test, many of the attack vectors used in the test are like what one can expect from malicious entities. As you scramble to get your VPNs up to capacity to support the increase in remote workers, please don’t forget to prepare for DDoS protection as well.

Stay safe and healthy – we all need to come out stronger on the other side of the tunnel.