On Mon, May 22, 2006 at 10:52:53PM -0500, Jacob Yocom-Piatt wrote:
> let's say that someone doesn't like me and/or a site that i run and they
> decide
> to DDoS me. i have a couple of questions since i'm not too familiar with the
> mechanics of a DDoS.
>
> what are some methods of launching a DDoS attack?
>
> what countermeasures can i take against such an attack?
>
> feel free to reply off list if you like ;). i am asking this here since, IMO,
> openbsd has highest average "1337n355" among its user base.
I hope not... 1337n355 is not associated with 'good' in my mind.
Anyway, a DoS attack is usually aimed at using up all of a finite
resource[1]. A DDoS is not very different, it just involves the
attacker(s) using more (usually compromised) hosts - but the mechanism
is largely the same as in a 'classical' DoS using only a single
attacking host.
The next question, of course, is what resource to exhaust. There are
many options here; the most classical example is the TCP state table,
the well-known SYN flood. This attack is not much use against modern
systems with a halfway decent TCP stack, due to a technique known as SYN
cookies, which basically lets the connecting host keep the state for
you.
There are other options, though. At the network level, most hard- and
software does not deal well with small packets. A sufficiently slow
connection can be saturated by a single host; a more beefy one can be
saturated by a large number of machines.
In the first case, more efficient/beefy network hardware and dropping
most of the small traffic could mitigate the attack; the second requires
the help of some upstream provider with more bandwidth.
At the application level, most servers are built to handle some
percentage more than usual load. A dedicated attacker might well be able
to exhaust some finite resource on the server - CPU time, memory,
database connections, you name it.
In OpenBSD's case, some important settings (not only memory, but notably
the number of open files) are set to a lowish amount. While this does
prevent DoS by a single process exhausting the memory or somesuch, it,
ironically, makes DoS by process limits easier. This is arguably better
than exhausting all memory, though (for one, other daemons on the same
box will be relatively unaffected).
A good firewall or IPS might be of some assistance in preventing this
attack; however, even a big company like Microsoft[2] has been forced
to simply give up the domain name windowsupdate.com after the MS Blaster
worm was released into the wild - this worm had a DDoS attack built-in.
(Though I presume that, in this case, it would have been possible but
not economical to weather the storm; that, and the problem might well be
that bandwidth got exhausted.)
Also, note that it is non-trivial to configure an IPS to actually work,
*and* not DoS your own machines, *and* have enough power to be able to
inspect stuff in case of a DoS (most such systems are lacking in power,
especially when many small packets are sent).
This is all assuming that applications and firewall(s/ rulesets) are
well-written and well-configured; quite a few contain a possibility for
DoS attacks. For instance, an application might be a very fast
single-threaded process that handles clients one by one; this doesn't
scale too well, but will work for a largish number of clients - provided
that they don't play such tricks with the TCP stack as allowing the
server to only send a single byte each time[3].
As to misconfigured firewalls, imagine a firewall dropping UDP packets
from any source that sends more than a specified amount. If this does
not ring alarm bells, think 'DNS server' and 'IP spoofing'[4].
DNS is vulnerable in many ways; especially since there are many bad
implementations and/or configurations. DNS poisoning, for instance,
might lead to problems as well.
Simply compromising a machine works, too; or, for additional points,
compromise a router and make it tell its peers to do really strange
things - like taking all the traffic for a stroll around the network
before sending it out. Or to peer only with some small ISP in an Asiatic
country with the bandwidth of three 56K modems.
So, plenty of options (the above is probably only a small collection)
for an attacker. Some are easily avoided - one should always be aware of
potential problems when configuring a firewall, for instance - but
others are very hard to defend against - possibly the worst is a large
botnet saturating the network connection. Many ISPs will not be happy
with a customer under attack, and may be less helpful than they could
be.
Joachim
[1] Other options *do* exist, though. For example, getting a border
router to repeatedly drop a BGP session would effectively kill a network
without a need for the attacker to use much bandwidth. Fernando Gont has
brought this to the attention of most security people on Bugtraq and
Full-Disclosure about a year ago; see Google.
OpenBSD incorporates several fixes against this sort of attack, partly
stemming from this discussion.
[2] Yes, yes, I know.
[3] When done in reverse, i.e. the server doing this, this is commonly
known as tarpitting.
[4] For DNS clients, proper source tracking on outgoing requests ('keep
state' in pf(4) lingo) might solve this problem; for DNS servers, the
problem is more interesting. Consider an entity having two datacenters,
one of which contains the DNS server. Causing the firewall in front of
the DNS server to drop all traffic from the second datacenter would
produce interesting results.
