[c-nsp] syn flood - port 80

Roger grunky at rockriver.net
Sun Aug 1 20:53:19 EDT 2004


Roger wrote:

> I'm wondering how one would slow down a syn flood attack on hosts @ 
> port 80?
>
> I'm running a 7206vxr at the border and would like to slow a syn flood 
> attack w/o clobbering my customers web servers...
>
> Traffic policing would be bad as to high of a percentage of syn 
> packets are junk, traffic shaping would help BUT all my customers web 
> servers would respond slower....
>

I should clarify things a bit...

The event I'm talking about is a distributed DoS attack.  The souces are 
from multiple ips(a few hundred) the strange thing is the destination 
ip..  The infected hosts are scanning my entire network range - in my 
case the entire /19.  Some hosts are live and active others ips are 
routed to Null as they aren't used...

Implementing CAR, IMHO, is out of the question.  In a syn flood CAR will 
drop packets once a bandwidth thresh hold is reached.  From their 
customer's http servers will appear to be down.  Since most traffic is 
junk the chances of legit http requests going through is low.

GTS would be better, BUT slow legit connections down to a crawl.  Also I 
have no real gauge to say how much bandwidth to allow for syn 
connections under normal conditions.

Making a "mega" acl w/ all the infected hosts seams kinda silly and long 
acls can just slow down all legit traffic, by bogging the cpu down and 
drawing lots of memory.

Out of desparation I'm thinking of doing this.. I'll be the first to say 
this is a BAD idea, suggestions welcome..

1 - Scan my internal network for legit http servers and make a list..

2- make a acl that will --
Explicitly allow syn packets to these legit web servers
Deny all syn packets going to destine port 80

3- manage said traffic flow from there..

This is a quick and dirty solution I've come up with.  The acl listing 
legit http servers will be not to lenghy BUT customers putting up new 
web servers will be screwed...  They could call up and we'd allow syn 
packets to their ip but this is no suitable long term solution.

Any alternatives welcome.


More information about the cisco-nsp mailing list