Subject: Re: Internet SYN Flooding, spoofing attacks

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 16 Feb 2000 14:59:55 -0500

In message <v0422080cb4d099a84d13@[171.78.30.107]>, Stephen Kent writes:
> Steve,
> 
> The AT&T experiences might be different, but at GTE-I, a SYN flood 
> was the primary attack mechanism for one major web site that we host. 
> Also, it is not at all clear that our network had a problem handling 
> the other flooded traffic (ICMP Echo Reply and UDP traffic) that was 
> sent to 3 other targets on our net, but the web hosts that were 
> targets certainly did suffer from processing the traffic.

Right.  Yahoo, though, was flooded mostly by the volume.  I worry about 
high-volume TCP garbage sent to port 80, which you can't filter.
> 
> Steve
> 
> P.S.  Nice photo and quotes in Newsweek!
> 
Thanks.

		--Steve Bellovin

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Feb 2000 08:34:42 +0000

In message <[email-masked]>, "Steven M. Bell

Steve

so in the case that the server resource is overloaded, but not the
link, what you can do is extend the servers scheduling discipline
(e.g. in dealing with existing connexions at a higher priority than
new ones, and applying filters to new ones based on content/application
level metrics (e.g. popularity indices, which is something many 
web servers have got anyhow), to priortise and starve the bad guys...

if the links/routers near you are also being clobbered, than some form
of "loose unicast RPF source quench" mechanism would be a
semi-automated way that server sites could extend this scheduling back
"towards" the bad guys - the idea is to take a mix of modified
versions of the resource control messages such as 
	icmp source quench
	ECN
	RSVP Reject
etc, and use them to install soft state upstream towarasd the bad guy

this state can either block, or just add a weighted RED higher 
drop probability, or eeven move traffic into a lower class in a
diffserv priority, CBQ, WFQ or other...

- but note unlike intserv/rsvp, this state doesnt have to be in all
hops - just the appropriate border/choke point....so it has lots of
nice scaling properties (its only their for a minority of
addresses/flows/ports, its only in a few places, and only when you
need it) - now if someone spoofs a real source address, this
represrents a problem since you can use this mechanism or something
like it to launch an indirect attack using this ....but there are ways
to block that (including making it mandatory to use ipsec to use this
mechanism...)

anyhow, its basically a sort of BGP policy controllable, interne
friendly scalable automated version of phoning up your ISP
and having them back track through all the further ISPs...

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Feb 2000 08:34:42 +0000

Steve

 cheers

   jon