D/DoS mitigation hardware/software needed.
rdobbins at arbor.net
Sun Jan 10 15:56:38 CST 2010
On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote:
> The only thing you've said that is being disputed is the the claim that a firewall
> under a DDoS type of attack will fail before a server under the same type
> of attack.
It's so obvious that well-crafted programmatically-generated attack traffic, if nothing else, will crowd out the good traffic that I'm just dumbfounded anyone thinks 'proof' of this is needed. Same thing for the fact that horizontally-scaled Web farm (with or without reverse caching proxies) will of necessity handle a great deal more TCP state than the biggest, firewall made to date.
> * because it doesn't correlate with my 22 years of experience in systems
> administration and 14 years in netops (including Yahoo netsecops where I
> did use IXIAs to compile stats on FreeBSD and Linux packet filtering),
It doesn't correlate with my 25 years in the industry, a good portion of the last 15 years spent handling DDoS after DDoS after DDoS, during which the biggest, baddest firewalls choked and died over and over again, through multiple generations of said firewalls.
Again, I was able to take down a hardware-based (for whatever value of 'hardware-based' is possible) firewall rated at 2gb/sec with 80kpps of traffic.
> * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment,
It correlates with my experience in large networks with geographically-dispersed IDCs with heterogeneous gear.
> * it doesn't correlate with server and firewall hardware and software designs, and last but not least,
Which is a non-sequitur.
> * because you have shown no objective evidence to support the claim.
I've my own broad subjective experience, and that of several other people who've commented on this thread have similar experiences. Since you haven't yet acquired this subjective experience, you can cause it to happen in a controlled test environment, should you so choose.
> Where then, can we find the results of your testing?
The testing I did when I worked for the vendor in question is proprietary, as you can well surmise. You're free to do your own testing and confirm these assertions for yourself.
> Nobody has "hurled insults" in this thread other than yourself Roland.
You accused me of acting in my own pecuniary interest, of trying to 'sell' things, *for no reason at all*.
> We just need some actual statistics.
If you actually care about the truth of the matter, you're free to generate your own. If you read the RoK/USA DDoS preso to which I linked, you see the attack throughput and bandwidth metrics/host, and you also see where I noted multiple 'Web Application Firewalls', load-balancers, and so-called 'IPS' falling over as a result of those attacks. That gives you a range right there, along with some attack traffic characteristics, including average packet size.
It makes no sense to put a stateful inspection device in front of servers, where *every single packet* is unsolicited, and therefore no state tracking is even possible in the first place. Stateless filters in hardware capable of mpps do a much better job, without the risk of falling over due to state-table exhaustion.
Folks who've been unlucky enough to be subjected to significant DDoS attacks have run into this issue again and again and again. Perhaps you've simply been lucky; but one can't count on one's luck holding forever.
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
More information about the NANOG