D/DoS mitigation hardware/software needed.

Mailman List Mirror (Read Only)
1

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

2

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.

3

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

4

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.