Why Your Firewall Could Fail During a DDoS Attack


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.

The Setup

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:

The Results

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.

Conclusion

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.

DDoS_Handbook_glow

Download Radware’s DDoS Handbook to get expert advice, actionable tools and tips to help detect and stop DDoS attacks.

Download Now

Ron Winward

As a Security Evangelist at Radware, Mr. Winward is responsible for developing, managing, and increasing the company’s security business in North America. Ron’s entire career has been deeply rooted in internet and cybersecurity. For over 20 years, Ron has helped design complex solutions for carriers, enterprises, and cybersecurity providers around the world. Ron is an industry-recognized expert in the Mirai IoT botnet and its modern variants. Ron conducted the industry’s first complete analysis of the Mirai attack vectors, producing forensic examples for public distribution of each attack and the specific impact each attack had on networks. His work on IoT attack analysis has been presented at conferences worldwide and has been referenced by NIST. Prior to joining Radware, Ron was Director of Network Engineering for a global datacenter provider and ISP. In this role, Ron oversaw the growth and development of a global network infrastructure that delivered services to other ISPs, hosting providers, and enterprises around the world. During this time, Ron assisted some of the world’s top businesses in mitigating cyberattacks on their infrastructure, cultivating an extensive knowledge in DDoS attack methodologies. Ron holds a Bachelor of Science degree in Business and has earned many technical certifications throughout his engineering-focused career. Ron acutely understands the impact of technology and security on business and is enthusiastic about their interrelation.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center