Re: Effective ways to deal with DDoS attacks?

["Christopher L. Morrow" <chris () UU NET>]

On Thu, 2 May 2002, Avleen Vig wrote:

> On Wed, 1 May 2002, Pete Kruckenberg wrote:
>
> > A rather extensive survey of DDoS papers has not resulted in
> > much on this topic.
> >
> > What processes and/or tools are large networks using to
> > identify and limit the impact of DDoS attacks?
>
> Hazaa.. something I know a little about.
>
> DDoS attacks by their very nature, are distributed.
> The primary purpose of more DDoS attacks is to flood the target's upstream
> connection to the point of saturation.
>
> 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?)

Let me say this one more time... "RATE LIMITS DON'T DO SHIT TO STOP
ATTACKS" for the victim atleast, all they do is make the job of the
attacker that much easier.  For instance:

1) I synflood www.avleen.org
2) you rate-limit syns to 1MB
3) I now only flood 1MB and I still win

So, don't rely on a rate-limit as its not going to help.

> 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.

This point is very good, depending on the attack your ISP (or you) might
have to take different counter measures to stop the attack... You (or your
ISP) will need to know as much as possible about the attack, the defenses
available on the hardware/software in the network, and actually be
available when there is a problem.

> 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.

This depends :) Call us, if you are our customer, and I guarantee that
someone will be there to resolve your issue, most times in 5 minutes or
less. Perhaps other ISP's should start having some folks on staff and
available for these tasks????? (hint, Hint, HINT!!!)

> 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

This is a wasted effort. It's not feasible, nor is it reasonable. There
are tools in place today that perform this function without the required
changes to protocols/functionality. Why would you want to make things
incrementally more difficult when the technology exists today to do this?

-Chris