D/DoS mitigation hardware/software needed.
rdobbins at arbor.net
Sat Jan 9 20:21:47 CST 2010
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 might 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 firewall vendor, so that dog won't hunt, sorry.
Think about it; firewalls go down under DDoS *much more quickly than the hosts themselves*; Arbor and other vendor's IDMSes protect many, many firewalls unwisely deployed in front of servers, worldwide. Were I that sort of person (and I'm not, ask anyone who knows me), it's in my naked commercial interest to *promote* firewall deployments, so that *more* sites will go down more easily and require IDMSes, heh.
> Firewalls are not designed to mitigate large scale DDoS, unlike Arbors, but they do a damn good job of mitigating small scale attacks of all kinds including 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 existing 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 gospel.
> 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. Firewalls don't help, either - they just go down.
> Perhaps a rhetorical question but, does systems administration or operations staff agree with netop's assertion they 'don't need no stinking firewall'?
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, as borne out by the real-world operational experiences of multiple people who'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 they've no place in front of servers, period.
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