[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <112783.1376859390@turing-police.cc.vt.edu>
Date: Sun, 18 Aug 2013 16:56:30 -0400
From: Valdis.Kletnieks@...edu
To: Jann Horn <jann@...jh.net>
Cc: Full Disclosure List <full-disclosure@...ts.grok.org.uk>,
Jann Horn <jann+couchdb-dev@...jh.net>
Subject: Re: Who's behind limestonenetworks.com AKA DDoS
on polipo(8123)
On Sun, 18 Aug 2013 10:04:58 +0200, Jann Horn said:
> On Sat, Aug 17, 2013 at 07:50:34PM -0400, Valdis.Kletnieks@...edu wrote:
> > Not all DDoS are pure bandwidth based. Consider SYN flooding, where the
> > packets sent are relatively small and often not even all that frequent, but can
> > tie up large amounts of resources on the target machine. This sort of attack
> > works particularly well against sites that have a big blind spot because they
> > think that all DDoS attacks are massive bandwidth hosedowns.
>
> So, why would an attacker use a distributed attack for that? Wouldn't
> one machine with good connectivity be sufficient (assuming that you spoof the
> source address differently each time)?
(a) Because 75% of the Internet doesn't allow spoofing of source addresses,
and (b) Although there's a chance that one machine throwing 3,000 SYN
packets a second will show up on somebody's network monitor, you're never
going to see 3,000 network monitors pop on 1 SYN packet per second.
And oh yeah, (c) sometimes you don't want to spoof the connection but
want to actually *make* the connection, in order to send them stuff that
will consume even more system resources than just a dangling half-open
connection....
> > How many connections/sec does it take to forkbomb your Apache server into
> > uselessness? And if you rate limit your Apache so your system doesn't
> > forkbomb, how many does it take to prevent legitimate traffice from being
> > serviced?
>
> Right, that would be much harder to block if it was distributed.
Remember - *you* are the guy who thinks that a DDoS is just bandwidth, it's
going to take you a while to look in your Apache logs. And then it's going to
take you even longer to twig into what's going on, because it all looks like
normal traffic until you pay attention to the timestamps. And then you'll find
it's *very* hard to block requests that belong to a malicious attack because
they look *real similar* to legitimate traffic. Sometimes, they look identical.
You don't believe me - ask anybody who's site has ever folded under the load
after they got mentioned on Slashdot. Every single hit looked like a
legitimate request - because it *was* a legitimate request coming from an
actual like human using a browser. Sure - you can then turn around and put in a
filter for references to your homepage to "stop" the attack.
But then you're just cutting off your nose to spite your face, because now
your legitimate customers/readers/visitors/whatever can't actually use your
site either.
Near as I can tell, they've stopped teaching Evil 101 to the newbies. Doesn't
anybody spend any time anymore thinking about "Wow, if I'm going to attack
this site, what can I do to maximize the pain per packet?"
Content of type "application/pgp-signature" skipped
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists