Re: Effective ways to deal with DDoS attacks?

["Alexei Roudnev" <alex () relcom EU net>]

There is one more usefull policy to decrease effectiveness of attacks such as
DDOS.

This is _refusal_ policy. In case of SYN attack, if system ALWAYS accept SYN
packets, dropping old waiting half-open connections if there is not enougph room,
SYN attack became much less dangerous - if 90% traffic is DDOS and 10% traffic is
usefull, most _right_ connections will compleet succesfully (because if room for
the half-open connections is big enougph, DDOS packets will drop mainly other DDOS
related connections).

It's a common approach - NEVER refuse new requests for the resource, if there is
not enougph resource, drop some of the old users of the resource... In a lot of
cases, it will derevent deadlock because you will be dropping the users who
exhausted resource more than _correct_ users. It relay to the half connections,
memory, etc etc...

If case of _random_ IP addresses - ok, what's happen if you'll drop (always) FIRST
packet from any new IP address? For the good SYN packet, you will receive a second
request in a second; for a false one, you just filter out DDOS itself. This is not
universal, but for the simple DDOS it will work.

It's not too bad to slow down all connections (by requesting _repeated request_,
for example) instead of blocking them.

So, I think things are not so bad.

----- Original Message -----
From: "Hank Nussbacher" <hank () att net il>
To: "Avleen Vig" <lists-nanog () silverwraith com>; "Pete Kruckenberg"
<pete () kruckenberg com>
Cc: <nanog () merit edu>
Sent: Thursday, May 02, 2002 1:51 AM
Subject: Re: Effective ways to deal with DDoS attacks?


> At 01:49 AM 02-05-02 +0100, Avleen Vig wrote:
>
> > As time goes by, tools are being developed (in fact they're used now) that
> > completely randomize the TCP or UDP ports attacked, or use a variety of
> > icmp types in the attack.
> > So cuurrently the only way you can 'block' such attacks is to block all
> > packets for the offending protocol as far upstream as you possibly can,
> > but this is not ideal.
> >
> > If you're being attacked by a SYN flood, you can ask try to rate-limit the
> > flood at your border (possible on Cisco IOS 12.0 and higher, and probably
> > other routers too?)
>
> ACLs have been a good tool for the past number of years to stop DOS attacks
> but they suffer one very bad feature - they throw away the good packets
> along with the bad packets.  The same goes for CAR.  The same goes for
> taking a /32 and null routing it.  Consider Amazon being hit with a DDOS
> attack from random spoofed IPs to their web site.  You can't block on
> source IP since it is random.  If you block on destination IP - you end up
> taking Amazon off the network (the ultimate aim of the attacker) at a daily
> revenue loss of over $1M.
>
> Therefore, the solutions in the future will be mechanisms that can filter
> and sieve the bad packets out and let the good packets thru.
>
> Disclosure: I consult to an anti-DDOS company with this philosophy.
>
> Hank
> Consultant
> Riverhead Networks (formerly Wanwall Networks)
> www.riverhead.com
>
>
> > If you're being smurfed, you can block ICMP Echo Reply's inbound to the
> > target IP.
> >
> > It all depends on the TYPE of attack.
> >
> > Having said that, it's only a matter of time before somebody releases a
> > tool that saturates a line by spooofing the source, randomizing the
> > protocol, and ports, and maybe even atacking other hosts on the same
> > subnet, etc etc.
> >
> > The only thing you can try and do is work with your upstream provider and
> > try to trace the source of the attacks back, but that's incredibly
> > difficult.
> >
> > As a side note, does anyone know the status of the ICMP Traceback
> > proposal? The ieft draft expired yesterday:
> > http://www.ietf.org/internet-drafts/draft-ietf-itrace-01.txt