Re: D/DoS mitigation hardware/software needed.
Dobbins, Roland wrote:
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.
Ok, I'll bite. What firewalls are you referring to?
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.
So then you're talking about CPU-driven firewalls, without ASICs e.g., consumer-level gear? Well, that would explain why you think they fail before the servers behind them.
I've been a sysadmin
Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? How would S/RTBH and/or flow-spec protect against that? Roger Marquis
On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote:
Ok, I'll bite. What firewalls are you referring to?
Hardware-based commercial firewalls from the major vendors, open-source/DIY, and anything in between. All stateful firewalls ever made, period (as discussed previously in the thread).
So then you're talking about CPU-driven firewalls, without ASICs e.g., consumer-level gear? Well, that would explain why you think they fail before the servers behind them.
You obviously haven't read the thread. No, I'm not talking about little firewalls, and no, I don't 'think' anything - I *know* it, because I've seen it over and over again, including during my tenure at the largest commercial firewall vendor in the world. See here for a high-profile example: <http://files.me.com/roland.dobbins/k54qkv> I've personally choked a hardware-based firewall rated at 2gb/sec with only 80kpps of traffic from an old, PowerPC-based PowerBook, for example. And again, as noted repeatedly in the thread, all that's required to effectively DDoS servers behind firewalls is to programmatically generate well-formed, completely valid traffic which passes all the firewall rules/inspectors/what-have-you - enough to 'crowd out' legit traffic from legit users. I strongly suggest reading the thread before commenting.
Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? How would S/RTBH and/or flow-spec protect against that?
We're talking about DDoS mitigation in order to keep the servers up and running, so that they don't go down ungracefully and corrupt anything in the first place. Placing a stateful inspection device in a topological position where no stateful inspection is possible due to every incoming packet being unsolicited makes zero sense whatsoever from an architectural standpoint, even without going into implementation-specific details. Once again - read the thread. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Sat, Jan 9, 2010 at 10:21 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote:
Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? How would S/RTBH and/or flow-spec protect against that?
We're talking about DDoS mitigation in order to keep the servers up and running, so that they don't go down ungracefully and corrupt anything in the first place.
have you noticed how putting your DB and WEB server on the same hardware is a bad plan? separate the portions of the pie... only let the attack break the minimal portion of your deployment. Use the right tool in the right place. -chris
On Jan 10, 2010, at 10:33 AM, Christopher Morrow wrote:
separate the portions of the pie... only let the attack break the minimal portion of your deployment. Use the right tool in the right place.
An excellent point. A Web front-end server should be that - merely the front-end. Situationally-appropriate functional separation is a key architectural principle. Combine that with the measures outlined in <http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html>, coupled with a functionally-separated, bulkheaded DNS infrastructure pictured in <http://files.me.com/roland.dobbins/m4g34u>, and one will end up with a much more robust, scalable, and defensible system. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
participants (3)
-
Christopher Morrow -
Dobbins, Roland -
Roger Marquis