[nycbug-talk] Some DoS benchmarking

[Isaac Levy]

On Mar 19, 2005, at 12:23 AM, Charles Sprickman wrote:

[snip]
> 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 
attack.

>
> 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 
machines.
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 :)

>
> http://www.dslreports.com/forum/remark,12920826
>
> Thanks,
>
> Charles

Good luck- sounds like fun!

Rocket-
.ike