Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Sep 1996 19:52:59 -0700 (PDT)
From:      "Jonathan M. Bresler" <jmb>
To:        roberto@keltia.freenix.fr (Ollivier Robert)
Cc:        freebsd-security@freebsd.org, BUGTRAQ@NETSPACE.ORG
Subject:   Re: Panix Attack: synflooding and source routing?
Message-ID:  <199609080253.TAA11619@freefall.freebsd.org>
In-Reply-To: <199609071738.TAA10976@keltia.freenix.fr> from "Ollivier Robert" at Sep 7, 96 07:38:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Ollivier Robert wrote:
> 
> According to Brian Tao:
> >     Wouldn't turning off source-routing on your border router
> > alleviate most of this problem?  It won't help if you have someone
> > synflooding a port from within your network, but at least it would
> > prevent outside attacks.  
> 
> The attack doesn't seem to have source routing in it. Source addresses in
> the packets are random that's all.
> 
> > Or is this a "one-way" attack (i.e., a return route to host is not
> > needed)?
> 
> It is.
> 
> SYN-flooding cannot really be prevented as far as I know. The attack lies
> in the fact that TCP/IP stacks must way for a timeout (2MSL) if there is no
> ACK in answer to the SYN,ACK the target sent.
> 
>         attacker  -------- SYN -----------> target
>         SYN_SENT 
>                  <-------- SYN, ACK ------  SYN_RCVD
>                   -------- FIN -----------> 
> 
> As the connection never completes, these half-open are not logged in any
> way. They are also used for port scanning.

	*not* 2MSL, i believe that the attack keeps the tcp control blocks,
	ip control blocks, mbuf, and associated resources tied up for
	nearly 11 minutes  (2MSL is 2 minutes).

	rather than send a FIN, the attacker may be sending another SYN
	packet.  the SYN packet is the last packet the attcker sends into
	that connection.  using raw_ip protocol the attacker can prevent
	the FIN and fake any desired ip addresses

	after a SYN, the server goes into SYN_RCVD state.  in SYN_RCVD,
	the timer "tp->t_timer[TCPT_KEEP]" is used as a *connection-
	establishment* timer.  unfortunately, this structre member 
	"t_timer[TCPT_KEEP]" is also used to store the keepalive timer
	for an *established* connection, hence the index "TCPT_KEEP".

	the FIN causes BSD based kernels to overwrite the connection-
	establishment timer value (75 seconds) with the keepalive
	value of 2 hours.  the 2 hours is reduced to an effective 11
	minutes because of retranmits by the target.  the target retransmits
	its SYN,ACK packet until TCP_MAXRXTSHIFT (12 retransmits) occur.
	the server then drops the connection and releases the resources.

	the bug is discussed in detail in stevens tcp/ip illustrated
	vol 3 p 151 section "SYN_RCVD Bug".

	note: i may be all wrong about this ;)
	the code in tcp_input.c needs to be protected  by a conditional
	"if (TCPS_HAVEESTABLISHED(tp->t_state))"  which is equivalent to
	"if (tp->t_state > TCPS_SYN_RECEIVED)"

	here is a unified diff.  this does not prevent the attack, it does
	lessen the severity.

--- tcp_input.c.old	Sat Sep  7 22:49:11 1996
+++ tcp_input.c	Sat Sep  7 22:49:44 1996
@@ -451,5 +451,6 @@
 	 */
 	tp->t_idle = 0;
-	tp->t_timer[TCPT_KEEP] = tcp_keepidle;
+	if (TCPS_HAVEESTABLISHED(tp->t_state))
+		tp->t_timer[TCPT_KEEP] = tcp_keepidle;
 
 	/*


	can someone please examine this patch and either tell me i am 
	wrong or commit it.  i sent this in >2 weeks ago and never heard
	a peep.   grrr...being wrong is bad enough, being ignored is
	far worse.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609080253.TAA11619>