[47290] in North American Network Operators' Group
Re: Effective ways to deal with DDoS attacks?
daemon@ATHENA.MIT.EDU (Christopher L. Morrow)
Thu May 2 01:06:46 2002
Date: Thu, 2 May 2002 05:04:46 +0000 (GMT)
From: "Christopher L. Morrow" <chris@UU.NET>
To: Pete Kruckenberg <pete@kruckenberg.com>
Cc: <nanog@merit.edu>
In-Reply-To: <Pine.LNX.4.33.0205012014470.15300-100000@minot.kruckenberg.com>
Message-ID: <Pine.GSO.4.33.0205020500480.11583-100000@rampart.argfrp.us.uu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
On Wed, 1 May 2002, Pete Kruckenberg wrote:
>
> On Wed, 1 May 2002, Richard A Steenbergen wrote:
>
> > "DDoS attacks" is such a generic term. There are a wide
> > variety of attacks which each need to be handled in
> > their own way, the extra "D" is just one possible twist.
> > Can you explain what kind of attack you're interested
> > in?
>
> We experience a lot of types of attacks ("education/research
> network" = "easy hacker target"). With DDoS incidents, it
> seems we are more often an unknowing/unwilling participant
> than the target, partly due to owning big chunks of IP
> address space.
>
> We most frequently are the zombie/reflector participants in
> an attack that originates outside our network, to a target
> outside our network. As many as 8,000 hosts on our network
> are reflecting SYN floods in the current attacks.
Sounds like its time for a firewall on your network :)
>
> Identification doesn't seem to be a problem. Snort is doing
> far too well notifying us. Responding and managing all of
> the defenses is becoming a lot of pain-staking work, and
> error-prone (why can't Cisco make ACLs easier to manage).
>
they aren't tough to 'manage' they are sometimes tough to live with though
:(
> Our approach so far has been temporary blocks (via ACL) of
> the target address. Blocking 8,000 internal addresses, many
> legitimate (secured) Web servers, generates more complaints.
>
> I'm thinking about a scripted Zebra feed where route
> injections are triggered by Snort. Routes for the target
> and/or SYN flood reflector hosts could be injected
> temporarily during the attack to border routers, which would
> route-map those routes to Null0. Script periodically
> withdraws routes to see if the attack is over (some of these
> last weeks, some only last a few seconds), to minimize the
> impact on those otherwise legitimate hosts.
>
This is a nice idea, anything 'scripted' is prone to abuse though ;( all
of a sudden www.your.edu is dead.. on class registration day no less.
> Has anyone tried this kind of an approach or any other type
> of automated/efficient approach to dampen the "zombie" side
> of the DDoS attack?
>
