[3455] in bugtraq
Re: Excellent host SYN-attack fix for BSD hosts
daemon@ATHENA.MIT.EDU (Jeff Weisberg)
Mon Oct 14 14:44:47 1996
Date: Mon, 14 Oct 1996 13:43:57 -0400
Reply-To: Jeff Weisberg <jaw@Op.Net>
From: Jeff Weisberg <jaw@Op.Net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Casper Dik <casper@HOLLAND.SUN.COM> notes:
| "Charles M. Hannum" <mycroft@mit.edu> writes:
| >Avi Freedman <freedman@netaxs.com> writes:
| >> No state is kept locally; when a SYN is received, an ISS is generated that
| >> contains a few bits for reference into a table of MSS values; window size
| >> and any initial data is discarded; and the rest of the ISS is the MD5 output
| >> of a 32-byte secret and all of the interesting header info.
|
| It also breaks "naked SYN" filtering which is commonly employed as a way
| to let established connections through without much effort and filter only
| those TCP packets that have a SYN.
| (Stuff like Cisco's establised keyword)
this would require either:
guessing the systems secret (128 bits)
very unlikely
inverting md5
I won't say it is impossible, but it is hard
sending lots and lots of packets until we get a connection
the odds are no better/worse than any other attack
based on guessing at seq. numbers
guessing at a rate of 100 packets/sec it will require,
on average, 3 days. few 2600 readers have this patience.
| If you want to use "SYN cookies", as this approach is commonly called,
| you should only start to employ them when the connection queue is full.
actually, this was my original intention, and the beginnings of which
are present in the code (dont_queue_mode)
--jeff
