Can Your Firewall and IPS Block DDoS Attacks? This question is something we hear often at Radware. The concern surrounds the uncertainty that stateful devices (firewalls, IDS/IPS, and load balancers) could become the fault point in a network when it is under attack. According to our research of different attacks analyzed over the last year, approximately one third of the failures in attacks were attributed to stateful devices being placed in front of a web-facing resource. In other words, the devices that we deploy in the datacenter to maintain our uptime are sometimes the specific reason that networks fail when they come under attack.
I recently worked with a customer who was troubleshooting this exact issue. They purchased good firewalls from a reputable, well known vendor and deployed them in a high-availability (HA) architecture. The firewalls were configured correctly, hardened, deployed in HA – everything you would expect for a great deployment. And yet, seemingly every time they got attacked, these expensive firewalls would fall over. Even under relatively low-volume attacks that didn’t saturate their Internet capacity, these services would fail.
Statefulness is one reason for this. Stateful firewalls are specifically tasked with keeping track of open transactions in the network. Tracking that state requires finite compute resources on the firewall and eventually, when pushed, those resources become consumed. Individual performance can vary based on many things (CPUs, RAM, security features and policies, even enabling IPv6) but the risk is the same – consuming resources in a stateful device can ultimately make it fail.
What Does the Failure Look Like?
In the example above, the most obvious symptom is that the customer couldn’t reach their servers. But when we looked at the firewalls, we observed other symptoms like instability of device management, VPN disconnects, and even HA failovers. In the lab, we can capture the real impact of DDoS attacks on firewalls.
Let’s dig into this a bit. I setup a lab to test the impact of a small TCP-SYN flood on a modern firewall. This particular firewall has two CPU cores; one for control-plane functions like CLI, SSH management, SNMP, etc, and one for security-related functions like session setup, firewalling, IDS, NAT, and VPN. Having this separation is important because it allows us to see what happens to the security feature set when under attack.
The attack was approximately 280 Mbps of TCP-SYN flood from multiple random spoofed sources. 280 Mbps is not a very big attack these days and it might not even be enough traffic to be obvious if you’re looking at your Internet traffic graphs. Nevertheless, it’s a significant amount of new connections that the firewall has to process. Here’s what it looks like from the switch facing the firewall WAN port (inbound into the firewall):
The attack begins at approximately 18:35 and lasts for approximately two hours. Now let’s look at the impact on the firewall. This graph shows the CPU utilization during the attack. The red line is the Control CPU and the green line is the Security CPU:
What we can see here is that during this attack, the Security CPU on this firewall was 100% utilized for most of the attack. Remember, this particular CPU is responsible for all of the security features that the firewall handles. The impact of this attack would be severe to traffic traversing the firewall, ranging from latency and timeouts to VPN sessions dropping. At 100% CPU utilization, the firewall is exhausted and can no longer perform its function without impacting service.
SYN Flood Protection on the Firewall Might Not Help!
In this example, enabling SYN flood protection on the firewall does not help because we’ve consumed the CPU with the attack. SYN flood protections typically drop the packet at the firewall rather than forwarding it through, but the firewall still has to process it against policy and decide what action to take.
What Other Options Exist?
One of the first things that people think is “I need a bigger firewall.” There are big firewalls and it’s true that you can likely push this out by adding resources to the firewall layer (more processing, bigger firewalls, etc.). However, I’ll suggest that if DDoS protection is a concern, adding more resources to a stateful perimeter is just delaying the problem. The servers that are being used to generate these attacks are also stronger than ever before. An exploited server with a 10 Gbps NIC in a datacenter can cause a lot of damage to a stateful device that is being targeted.
At Radware, we approach this problem differently. Our DDoS prevention solution, DefensePro, is not stateful and can assess and mitigate these threats before they consume your firewall or other stateful devices. By inserting a purpose-built DDoS mitigation device inline before that attack traffic reaches your stateful devices, you can eliminate the threat of connection exhaustion and other risks.
As security people, it would be difficult to find anyone to challenge the importance of a firewall. Firewalls are critical devices in today’s networks. However, what I think you will find is that people will advise caution as to where the firewall sits and what its purpose is. For the reasons above, many DDoS security experts will advise against deploying a stateful firewall in front of any web-facing resource that needs to maintain uptime. Every network is different, but if uptime is important to your network, you should have a plan for handling attacks and you should know the limits of your existing architecture. It doesn’t take much to impact a stateful device, which is why purpose-built DDoS mitigation devices are becoming a necessary part of today’s network.