Date: Fri, 13 Sep 1996 12:03:49 -0700 From: Julian Elischer <julian@whistle.com> To: Michael Dillon <michael@memra.com> Cc: server-linux@netscape.org, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution[ALT]? (fwd) Message-ID: <3239B015.167EB0E7@whistle.com> References: <Pine.BSI.3.93.960912233311.11005G-100000@sidhe.memra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Dillon wrote: > > Now here is something that could be used by sites to protect against SYN > flood attacke assuming that they can build a special custom box with > enough RAM to buffer the sockets for 30 seconds or more. How high a rate > can SYN floods come in at? I've heard of 1,000 per sec which implies that > this box needs to hold open 30,000 to 75,000 potential sockets. Is there > any problem within IPv4 (seq #'s?) that would make this inherently > impossible? > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael@memra.com > > ---------- Forwarded message ---------- > Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT) > From: "Roderick Murchison, Jr." <murchiso@vivid.newbridge.com> > To: firewall-1@applicom.co.il > Cc: firewalls@GreatCircle.COM > Subject: Re: SYN floods - possible solution? > > On Thu, 12 Sep 1996, Blast wrote: > > This problem has kept me awake more than coffee. :-) > > Ditto... I just woke up *again* with a kludgy but potential defense... > sorry if this is totally out of whack, but I'm really beat! > > 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. As an optimisation, what about the following.. there is no need to ping the following sites. 1/ A site for which this is the FIRST (or even second) SYN 2/ A site for which we already have a verified connection the weakness in 1/ is that the hackers could use sequentially incrementing source addresses, It might not be neccesary to even switch on this mode if there are < N syn requests per second, or < N Incomplete channels.. > > 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? > > hope this helps, > -r > > Roderick Murchison, Jr. murchiso@vivid.newbridge.com > Newbridge Networks, Inc. office: (703) 708-5930 > Product Manager - VIVID ACS fax: (703) 708-5937 > Herndon, VA 22070-5241 http://www.vivid.newbridge.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3239B015.167EB0E7>