From route@onyx.infonexus.com  Sat Sep 14 06:16:32 1996
Received: from onyx.infonexus.com (plugHead@onyx.infonexus.com [204.162.164.220]) by suburbia.net (8.7.4/Proff-950810) with SMTP id GAA24480 for <best-of-security@suburbia.net>; Sat, 14 Sep 1996 06:14:28 +1000
From: route@onyx.infonexus.com
Received: (qmail-queue invoked by uid 501); 13 Sep 1996 20:16:35 -0000
Message-ID: <19960913201635.2522.qmail@onyx.infonexus.com>
Subject: Re: BoS: Tool for stopping SYN floods
To: k-hamer@uiuc.edu
Date: Fri, 13 Sep 1996 13:16:35 -0700 (PDT)
Cc: best-of-security@suburbia.net
In-Reply-To: <Pine.SOL.3.91.960913141608.1046A-100000@aries.astro.uiuc.edu> from "Kenneth L. Hamer" at Sep 13, 96 02:18:44 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

| 
| With the routers for most ISP, they should be blocking any non-internal
| addresses from leaving their network and going to the Internet. This will
| stop an attacker if their ISP implements this.  Unfortunately, this does
| not stop an attack from areas on the Internet that do not block that. But
| at least the ISP can feel comfortable to know that an attacker can not
| launch his attack from that ISP. 

	Two ways to circumvent this:

	1) Modify the TCP kernel on the attacking machine to ignore the
	incoming SYN|ACKs.  This will have the same effect as a 'normal'
	TCP SYN flood.
	2) Play one machine off another.  SYN flood a machine internal to
	the gateway router using an IP address unreachable to it (or, as in the
	first scenario), while at the same time SYN flood the desired target 
	outside the router, using the first target's IP address and flooded port
	as the sources...

	Neither of these are ideal.  The first scenario destroys the anonimity
	of the attack.  The second is adds much complexity to an otherwise 
	simple DOS attack.

| Here are two methods of helping eliminate the problem.  Some of the
| exploit code I have seen does not pick a random source port.  It would be
| easy to block the attack with a router denying any packets coming from a
| specific source port. This may not be too effective because of the trivial

	Sequence number.  Blocking SYNs with certian sequence numbers may
	stop unsophisticated attackers also.

| nature of adding code to randomize the source port, sequence number,
| source address, and TTL.  But it might help you temporarily if you notice
| the attacks have any pattern that can be blocked by router rules. 

	True.
| Another way to fix this is to set the kernel maximum number of half open
| connections allowed (SO_MAXCONN) to a higher number than the default value.

	Bad idea.  It is trivial for an attacker to simply send more packets.
	It quickly becomes non-trivial for the target to allocate memory structures
	for all the pending connection requests...

| We have a tool that will look for SYN packets that do not get followed with
| ACK and clean the half open connections by sending a RST packet.  This 

	Another way to detect and eradicate SYN floods:

	Kernel mod or daemon that will:
	-listen for all incoming SYNs
	-keep a list of the x most recent incoming SYNs (x=backlog?)
	-if x amount of connection-requests take more than y amount of time
	to complete and(other heuristics)
		-x SYNs arrived in z time relative to each other.
		-x SYNs have a,b,c features in common (source IP addr,TTL,port,seq#)
		-etc...
	-DROP them, reset the connections, free the associated memory structures.
	
-- 
[ route@infonexus.com ]  Editor, Phrack Magazine / Member, Guild Corporation

	       the greatest trick the devil ever pulled was
		   convincing the world he didn't exist