Great Circle Associates Firewalls
(September 1996)
 

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

Subject: Re: SYN floods - possible solution?
From: "Paul D. Robertson" <proberts @ clark . net>
Date: Fri, 13 Sep 1996 02:32:45 -0400 (EDT)
To: "Roderick Murchison, Jr." <murchiso @ vivid . newbridge . com>
Cc: firewall-1 @ applicom . co . il, firewalls @ GreatCircle . COM
In-reply-to: <Pine . SOL . 3 . 95 . 960913012131 . 10525A-100000 @ tartarus>

On Fri, 13 Sep 1996, Roderick Murchison, Jr. wrote:

> Ok.  say you have a firewall between your network and you Internet
> connection.  If that firewall could detect and *detain* a segment with the
> SYN option set, then see if the set source IP answers an ICMP echo
> request, we could effectively determine whether or not the SYN could be
> dropped at the firewall and not sent through to spam our hosts.  If the
> source responds, release the SYN and let it pass through to the intended
> host.  If it does not, trash the SYN and log the failure.

You run into the same problem, sooner or later you fill the hold buffer
while checking, then legitimate connections are lost.  Beef the IP stack
buffers, shorten timers, and increase listen queues, and you're at about
the same place.  Dynamically dropping timers is a good thing, IMO, as it
allows slow connections when not under attack.  

Meanwhile, the NSPs sniffing for this, and going after the flagrant
offenders would help, since the general attack profile is probably
800-2000 packets from different source addresses within a range of several
seconds.  Sniffing at the NSP leaf routers could possibly detect this
pre-interface.  A small PC with a couple of v.35 interfaces and some code
could perhaps detect this quite easily.  Then it'd just be getting the
NSPs to put them on an interface for a week at at time not as good as
inbound filter rules, but perahps not as invasive either.

Basically, it's detectable, and stoppable on the leaf routers, if the
larger NSPs would get together and agree to do one or the other, perhaps
it would give us enough breathing room.  Maybe make it part of peering
agreements.   

Meanwhile, perhaps the firewall vendors would consider having customers
enable specific lists of outbound networks by default where applicable,
can't hurt.


> 
> Some moderate tracking and aging methods could be employed to
> intelligently quick drop sources we know are recently offline, and lessen
> the amount of echo requests we send out. 
> 
> Could this be a potential defense?  If so, what products would be best
> suited to implement this?
> 

Not in my world, I don't allow ICMP in general.

Paul
---------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts @
 clark .
 net      which may have no basis whatsoever in fact."
                                                                     PSB#9280



Follow-Ups:
References:
Indexed By Date Previous: Re: SYN floods - possible solution?(update)
From: "Roderick Murchison, Jr." <murchiso @ vivid . newbridge . com>
Next: Re: SYN floods - possible solution?
From: "Daniel J Blander - Sr. Systems Engineer for ACS" <Daniel . Blander @ ACSacs . Com>
Indexed By Thread Previous: Re: SYN floods - possible solution?
From: "Roderick Murchison, Jr." <murchiso @ vivid . newbridge . com>
Next: Re: SYN floods - possible solution?
From: scs @ lokkur . dexter . mi . us (Steve Simmons)

Google
 
Search Internet Search www.greatcircle.com