[nycbug-talk] Some DoS benchmarking
ike at lesmuug.org
Sat Mar 19 13:24:27 EST 2005
On Mar 19, 2005, at 12:23 AM, Charles Sprickman wrote:
> Anyhow, the site was recently DDoS'd and the frontend box couldn't
> handle it. Their upstream apparently was able to squash some of it so
> that it wasn't a bandwidth DoS, but the Linux 2.4.? kernel was
> spending an inordinate amount of time servicing interrupts from the
> network card.
Did they post configuration and attack details, for the record, once
they solved the problem? (or did I it them somewhere in the thread?)
I'm kindof interested in how this attack worked- though I'm not
surprised that some default in a Linux install was so susceptible to
> This thread has the site owner/admin musing over how to improve it.
> Needless to say the 3 BSD guys there didn't say "dude, drop linux and
> go to BSD", but we did all do some testing. I'm "sporkme". That
> "eatmeingreek" guy seems pretty clever... :)
> As you can see down the line I eventually wrangled some decent
> hardware and it performed great. I'm a bit stuck as far as getting
> the *senders* to generate more than 130,000 pps and 65Mb/s. At one
> point I had one dual 2.8 Xeon, one dual 2.0 Xeon and one dual 1.0 PIII
> box hitting it. The receiving box was totally responsive (running
> 4.11, BTW) and was only spending about 8% of the CPU servicing
> interrupts, and that's WITHOUT polling enabled in the kernel. Pretty
> impressive. I'm wondering if my little backend switch (I used the
> internal network for this) is the bottleneck?
Well, to throw my quick .02¢ into this one; while your switch may be a
bottleneck, I've found that reproducing true distributed network loads
on servers is nearly impossible- insomuch as it's extremely difficult
to repoduce the *type* of traffic that comes from say, a few thousand
Sick asynchronys entropy in packet latency, types of packet header
changes based on routing, etc..- it all becomes an insane number of
variables, which in most attacks, is more critical than the actual
bandwidth consumed by a ddos.
That said, a single box slinging fat packets is far easier for any
system to deal with than a few thousand boxes trickling out a few
packets in semi-synchronized bursts. I mean there's tons of ways to
tweak out packets from a few boxes to come *closer* to all that
distributed entropy and chaos, but in the end, it's still limited to
the number of actual boxes and networks in the mix...
> Thoughts? Observations? Hints on tuning polling (Hz value) if this
> were a real-world DDoS and I wanted to make sure I'm not wasting
> cycles processing garbage?
Nah- I don't think you'll waste cycles- totally bound to learn some
interesting stuff about performance/behavior, but I've just found for
performance/etc... testing there's just nothing that compares to
thousands of machines from around the world slamming things- production
webserver traffic is the best place to learn, and the kiddies keep us
busy with *plenty* of chances to learn :)
Good luck- sounds like fun!
More information about the talk