FreeBSD SYN attack info

From xomox@boris.eden.com Fri Sep 20 15:34:03 1996
From: Matt Bush <xomox@boris.eden.com>
To: nanog@MERIT.EDU
Subject: Re: SYN flood messages flooding my mailbox

> 
> In message <199609161637.MAA20184@netaxs.com>, Avi Freedman writes:
> > 
> > > implementation.  This is a denial of service exposure that has gone
> > > unaddressed in host implementations until recently.  BSD now uses a
> > > hash table on the TCP PCBs (protocol control blocks in the kernel) and
> > > with change of removal of the check can support close to 64K-2000 PCBs
> > 
> > Hmm.  Interesting.  I was told that NetBSD did not...
> > Which version of BSD should I look at?  A hash table on a static array of
> > PCBs is a much better solution than letting a linked list get to 2000
> > entries...
> 
> Oops.  That's in a BSDI patch (PATCH K210-019) but I'm not sure about
> FreeBSD or NetBSD distributions since I don't have one handy.
> 
I'm not sure about prior releases, but FreeBSD 2.1.0 and above do hash
PCB's, with a default hash size of 128.  The constant name is TCBHASHSIZE
in netinet/tcp_subr.c.  To raise it, just add

options         "TCBHASHSIZE=2048"	# More capable TCB hash

  ... and if you feel the need, add

options         "UDBHASHSIZE=1024"	# More capable UDB hash

to your kern config file.

> Curtis
> 
> ps- (My 6 year old has a FreeBSD system, but its 2.0.5.  Got to get
> him to upgrade. :)
> 
Version 2.1.5-Release is now available.  ;-)

  Cheers,

   -Matt

From jmb@freefall.freebsd.org Sat Sep 21 21:09:33 1996
From: "Jonathan M. Bresler" <jmb@freefall.freebsd.org>;
To: nanog@merit.edu
Subject: SYN attack. how does it *really* work

Michael Dillon wrote:
> 
> If it only takes 8 SYN packets to lock up a socket for 75 seconds then
> effective SYN flood attacks certainly *CAN* be launched from a dialup
> connection. And if the definition of an effective attack allows for
> intermittently shutting down a socket then effective attacks certainly
> *CAN be launched from places like Uruguay, Brazil, Indonesia and so forth.

	not 8, only 2 SYN packets into the same connection are needed
		(connection is a single src addr, src port, dest addr
		 dest port 4-tuple)
	not 75 seconds, ~11 minutes.

	the essence of the bug is:

	one timer t_timer[TCPT_KEEP] used for 2 purposes
		--to hold the 75 second half-open timer
		--to hold the 2 hour keepalive timer
	the first SYN packet sets the timer to 75 seconds
	the second trips the bug and resets the timer to 2 hours

	so where does the 11 minutes come from?

	the server (target) send SYN-ACK packets, and retransmits
	the SYN-ACK until it either gets a response or gives up
	when TCP_MAXRXTSHIFT is exceeded.  the latter take ~11 minutes.

	the fix is to qualify the settting of hte timer ala:

	if (TCPS_HAVEESTABLISHED(tp->t_state))
		tp->t_timer[TCPT_KEEP] = tcp_keepidle;

	and to set the timer a each location where the TCP/IP state
	machine transitions to TCPS_ESTABLISHED.

	each half-open socket consumes 264 bytes of memory (assuming
	perfect allocation ;)

	all BSD derived TCP/IP implementations are/may be susceptible
	to this bug.  that includes AIX, SVR4, and SunOS.

	stevens TCP/IP illustrated vol 3 p191 explains this much beter
	than i can
jmb
--
Jonathan M. Bresler           FreeBSD Postmaster             jmb@FreeBSD.ORG
FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/
PGP 2.6.2 Fingerprint:      31 57 41 56 06 C1 40 13  C5 1C E3 E5 DC 62 0E FB