[121077] in North American Network Operators' Group
Re: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Sat Jan 9 21:29:56 2010
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Date: Sun, 10 Jan 2010 02:21:47 +0000
In-Reply-To: <20100110020325.3918D2B2152@mx5.roble.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 10, 2010, at 9:03 AM, Roger Marquis wrote:
> That hasn't been my experience but then I'm not selling anything that mig=
ht have a lower ROI than firewalls, in small to mid-sized installations.
I loudly evinced this position when I worked for the world's largest firewa=
ll vendor, so that dog won't hunt, sorry.
Think about it; firewalls go down under DDoS *much more quickly than the ho=
sts themselves*; Arbor and other vendor's IDMSes protect many, many firewal=
ls unwisely deployed in front of servers, worldwide. Were I that sort of p=
erson (and I'm not, ask anyone who knows me), it's in my naked commercial i=
nterest to *promote* firewall deployments, so that *more* sites will go dow=
n more easily and require IDMSes, heh.
> Firewalls are not designed to mitigate large scale DDoS, unlike Arbors, b=
ut they do a damn good job of mitigating small scale attacks of all kinds i=
ncluding DDoS.
Not been my experience at all - quite the opposite.
> Firewalls actually do a better job for small to medium sites whereas you=
need an Arbor-like solution for large scale
> server farms.
No, S/RTBH and/or flow-spec are a much better answer for sites which don't =
need IDMS, read the thread. And they essentially cost nothing from a CAPEX=
perspective, and little from an OPEX perspective, as they leverage the exi=
sting network infrastructure.
> Firewalls do a good job of protecting servers, when properly configured, =
because they are designed exclusively for the task.
No, they don't, and no, they aren't.
> Their CAM tables, realtime ASICs and low latencies are very much unlike =
the CPU-driven,
> interrupt-bound hardware and kernel-locking, multi-tasking software on a
> typical web server. IME it is a rare firewall that doesn't fail long,
> long after (that's after, not before) the hosts behind them would have
> otherwise gone belly-up.
Completely incorrect on all counts. Sales propaganda regurgitated as gospe=
l.
> Rebooting a hosed firewall is also considerably easier than repairing
> corrupt database tables, cleaning full log partitions, identifying
> zombie processes, and closing their open file handles.
Properly-designed server installations don't have these problems. Firewall=
s don't help, either - they just go down.
> Perhaps a rhetorical question but, does systems administration or operati=
ons staff agree with netop's assertion they 'don't need no stinking firewal=
l'?
I've been a sysadmin, thanks. How about you?
You can assert that the sun rises in the West all you like, but that doesn'=
t make it true. All the assertions you've made above are 100% incorrect, a=
s borne out by the real-world operational experiences of multiple people wh=
o've commented on this thread, not just me.
I've worked inside the sausage factory, FYI, and am quite familiar with how=
modern firewalls function, what they can do, and their limitations. And t=
hey've no place in front of servers, period.
;>
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
