The “State” of DDoS Mitigation Products and Vendors


DDoS attacks have become a mainstream topic frequently in the news with coverage in major news outlets around the globe from ABC News to ZDNet and most in between.  Attack campaigns by groups like Anonymous, DD4BC, Lizard Squad and Lulzsec have become dinner conversations in many homes and online businesses have been struggling to keep pace with the evolving threat landscape.

Vendors on the other hand see an opportunity.  The DDoS market is becoming flooded with security, network and application vendors all claiming some sort of DDoS protection.  It seems only logical to deliver timely products to a hungry market; good business sense right?  The problem is that some products reaching the market are not actually proven to protect against todays multi-vector DDoS attacks.

Are Stateful Devices Viable DDoS Mitigation Products?

Many vendors are claiming holistic DDoS protection capabilities that leverage stateful devices such as Firewalls, IPS, and Application Delivery Controllers/Load Balancers (ADCs).  Why is this a problem?  Well, before I go on a rant let’s be clear that I am an advocate for a multi-layered defense in depth – enable DDOS protections where you can, harden infrastructure ACLs, servers and applications, and yes, even leverage functions on those firewalls, IPS and ADCs.

Do you even need a firewall in front of your web servers? Take caution. A web application firewall, IPS and Application Delivery Controllers are stateful and not purpose built for DDOS mitigation.  These devices open connections and maintain session state tables between the client (or attacker) and the server.  Inherently, these DDoS security tools themselves are actually one of the most likely bottlenecks while under DDOS attacks due to their stateful nature.

Here is a look at a real world attack analysis from our Emergency Response Team.  Two thirds of the attacks can be prevented by protecting against DDOS in front of the firewall and other stateful devices.

Attacks (such as TCP SYN and UDP floods, application layer attacks on HTTP, DNS, SIP, SMTP, etc.) can take advantage of stateful devices by opening many sessions and eventually exhausting the state tables, preventing further connections from being established or causing device overloads.

In production environments, weary security teams often configure IPS to fail open.  When overloaded by DDoS attacks, the IPS causes the security protections that once were in place to be pulled back and be open to exploitation.  Hackers understand this and will often use attacks to simply tip over the IPS and exploit the target without security inspection.  If a security tool itself will fail or cannot withstand today’s threats, should the vendor be claiming DDoS protection?

Granted, perhaps it’s not cut and dry.  There may be features on a device that can be leveraged in a multi-layered defense, such as signatures for known DoS tools.  Some firewalls can also perform functions such as SYN cookie challenge to weed out spoofed TCP SYN packets.  Again, I’m an advocate for multi-layered defense, but the problem is when a buyer believes they are covered from DDoS because their Firewall has a “function” which can help play a role in the defense.

Lipstick on a Pig

The message is simple here:  beware of stateful devices and clever marketing campaigns.

Stateful devices and DDoS mitigation are a dangerous mix.  Vendors may use buzzwords and offer incomplete solutions and buyers are at the mercy of the data that is in front of them.  This influx of clever marketing can mislead buyers as vendors flock to this hot market and consumers may find subpar products reaching their production enterprise and carrier network architectures.

The decision to acquire DDoS mitigation solutions is NOT as straight forward as one would like.  On the surface many of the products appear to be leveraging similar technologies, methods, and even verbiage.  As the DDOS market grows it’s becoming difficult for the inexperienced buyer to differentiate between sound security solutions and clever marketing.  Dig into the details and you too will realize that all solutions are not equal.  Some vendors claim DDoS protection within existing gear revamped as DDoS mitigation.  Have they actually hardened these legacy devices or simply undergone efforts toward marketing “new” use cases?  You can put lipstick on a pig, but it’s still a pig.

Selecting the Best Premise-Based Solution

Dedicated solutions offering purpose built, tailored hardware is architected with 100% availability and security in mind.  Premise-based DDoS mitigation should be deployed as close to the perimeter (Internet transit point) of the network and always in front of stateful devices.  Placement in the frontlines of the defense, provide protection of the network infrastructure, stateful firewalls, load balancers/ADCs, IPS, servers AND applications.  A proper DDoS mitigation solution should be designed so that it will never become the bottleneck while under attack.

An example of this is the Radware DefensePro.  The DefensePro itself is not stateful.  It filters out attacks prior to the monitoring of legitimate sessions for misbehaving actors while never maintaining session state.  This allows identification sessions which are out of state (such as FIN or ACK packet floods) without existing sessions in place.  This unique approach ensures we monitor the sessions that matter only after attack mitigation occurs.  We often find ourselves in situations where a technical evaluation puts us to the test to prove we have the best solution.  DefensePro offers superior DDoS prevention with the industry’s best security inspection capabilities up to 160Gbps of legitimate traffic with mitigation capacity rates over 230Mpps in dedicated ASICs.

Validate: The Proof is in the Pudding

I’ll leave you with some final words of experience:  Take your DDoS equipment for a test ride and leverage real-world scenarios with real traffic.  Ensure that legitimate users can access your applications even when under attack.  Also validate that latency is at a minimum.  Severe latency can be as degrading as a complete outage.

Test, Test and Test Again

Often DDoS attack test plans focus on volume (bps/pps).  But, don’t forget about application layer floods including HTTP(s) GET, POST floods, DNS Recursive & Reflective, SIP, SMTP, UDP amplification and protocol attacks such as SSL renegotiation.  Encrypted attacks are on the rise with the advent of HTTP 2.0 and the increased need for privacy for many applications will be moving to full TLS encryption.  DDoS testing should be included in regular penetration and vulnerability assessments.

Dennis Usle

As Director, Security Solutions Architecture at Radware, Mr. Uslé is responsible for the security architecture design and implementation of Radware Security platorms. Before joining Radware, Dennis served as Senior Network Security Engineer at a major East Coast Cloud Security provider based in Philadelphia. Mr. Uslé has over a decade of experience designing, securing, deploying, and operating large-scale Service Provider and enterprise class networks, with a focus on availability and security.

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