[47298] in North American Network Operators' Group
Re: Effective ways to deal with DDoS attacks?
daemon@ATHENA.MIT.EDU (Hank Nussbacher)
Thu May 2 04:09:48 2002
Message-Id: <5.1.0.14.2.20020502104821.00ff27a8@max.att.net.il>
Date: Thu, 02 May 2002 10:51:17 +0200
To: Avleen Vig <lists-nanog@silverwraith.com>,
Pete Kruckenberg <pete@kruckenberg.com>
From: Hank Nussbacher <hank@att.net.il>
Cc: "nanog@merit.edu" <nanog@merit.edu>
In-Reply-To: <20020502013505.R4182-100000@apple.silverwraith.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Errors-To: owner-nanog-outgoing@merit.edu
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
