Great Circle Associates Firewalls
(September 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: SYN Floods - proposal
From: "Fernando da Silveira Montenegro" <silveira @ nutec . com . br>
Organization: Nutec Informsstica
Date: Mon, 16 Sep 1996 19:43:31 -0300
To: firewalls @ greatcircle . com
Comments: Authenticated sender is <silveira @ [200 . 246 . 247 . 2]>
Reply-to: silveira @ nutpagw . nutec . com . br

> It seems to me that most of the focus the last week or so has been
> on using a firewall to prevent this sort of attack. While this would
> be beneficial to many of the members of this list, most of the rest
> of the world would not benefit from this solution.  It also has
> the disadvantage (mentioned above) of hindering (not removing all
> consequences of) the attack at the destination. I'm sure the firewall
> vendors would love to sell more product to combat this attack, but
> the solution makes me uncomfortable for several reasons:
> 

By now we all know that this is a problem in the very fabric of 
TCP/IP and the Internet: it abuses the trust that the protocols 
operate on, as well as implementation issues on virtually every 
server out there.

Through the past few days we have heard different solutions, and we 
as "firewallers" (let's not get to the old "Title" debate, shall we?) 
can provide a helpful hand to the community as a whole by coming up 
with a plan to address this "feature" of IPv4 (we all know IPv6 will 
take eons to deploy...).

My suggestion is to attack the problem from many angles:

1. Suggest implementing proper filtering of outbound packets on the
ISP leafs or the University/Corporate routers. It doesn't solve the
entire problem, since the attacker can BE an ISP (people thought of
this already?) and not all organizations in the world will cooperate,
but it is a start.

2. Urge OS vendors to implement some version of the algorithm being
proposed on this list (proxying the SYNs for a while before
commiting them to kernel) as a security patch. I know it doesn't
solve the entire problem (we can always overload the buffers on the
patch code as well), but it should also diminish the problem. 

I think by doing this we will reduce the problem of copycat attacks,
where the would-be hackers use a small 28.8k link trying to saturate
a T1...

3. Have FW vendors implement this same patch on the firewall itself.
Even if we lose the firewall to SYN hosing, we still save the server.
Furthermore, if we have multiple connections (and multiple
firewalls) for a given server (assuming a popular site here) we can
keep the server up even we fry one firewall.


Unfortunately, there is no magical solution: we have to fight this 
one bit by bit, trying to reduce the possibility of trying the attack 
(filters on source) and at the same time minimize the effect on the 
targets (SYN proxying).

Asbestos suit already on: flame away if you feel like it.

Regards,
Fernando


--
Fernando da Silveira Montenegro   E-mail: silveira @
 nutec .
 com .
 br
Novas Tecnologias                 WWW...: http://novatec.nutecnet.com.br
Nutec Informatica                 Phone.: +55-11-5505-5728   
Sao Paulo, SP - BRAZIL            #include <std_disclaimer.h>

Indexed By Date Previous: Re: Firewall Alpha Digital AXP 3200
From: Brian Walters <psiphi @ voicenet . com>
Next: Internet policy
From: potlicker @ morebbs . com
Indexed By Thread Previous: Configuration checking
From: dnewman @ mcgraw-hill . com
Next: Internet policy
From: potlicker @ morebbs . com

Google
 
Search Internet Search www.greatcircle.com