TCP SYN attacks

Dima Volodin dvv at sprint.net
Fri Oct 4 16:16:41 UTC 1996


Avi Freedman writes:
> 
> > Now what is 100,000 entries? With the timeout aggressively set at 10
> > secs (heck, with 10 secs I sometimes cannot even get all the images on
> > home.netscape.com) it's only 1000 SYNs/sec. How many hosts you want to
> > protect with such a firewall?
> > 
> > Dima
> 
> A timeout of 10 seconds is on two packets going back and forth.
> Many have said that the timeout must be much higher.  I just don't
> see it.  A SYN arrives.  A SYN-ACK is sent out.  A 10 second timer 
> starts that is counted down to 0.  An ACK of that SYN-ACK arrives
> back within the 10 seconds and we set up the connection.  If the
> two packets can't each go one way in 10 seconds, the SYN will be
> retransmitted.

(quoting myself):

	(heck, with 10 secs I sometimes cannot even get all the images
	on home.netscape.com)

My kernel values:

	tcp_ip_abort_cinterval 10000
	tcp_ip_notify_cinterval 1000

In Solaris, these values work for both incoming and outgoing connections.
I could have lowered the notify_cinterval even more though.

And I'm not even on a dial-up line:

	traceroute to www30.netscape.com (207.12.240.31), 30 hops max, 40 byte packets
	 1  206.229.244.1 (206.229.244.1)  159 ms  106 ms  10 ms
	 2  sl-dc-17-S1/0-T1.sprintlink.net (144.228.0.225)  11 ms  7 ms  15 ms
	 3  sl-dc-6-F0/0.sprintlink.net (144.228.20.6)  19 ms  8 ms  8 ms
	 4  sl-stk-5-H1/0-T3.sprintlink.net (144.228.10.2)  80 ms  81 ms  79 ms
	 5  sl-stk-16-F0/0.sprintlink.net (144.228.40.16)  77 ms  79 ms  81 ms
	 6  sl-netscape-1-s-T3.sprintlink.net (144.228.146.26)  223 ms  101 ms  162 ms
	 7  207.12.240.31 (207.12.240.31)  147 ms  85 ms  92 ms

> My preferred approach is to not even have to store state on any
> of the embryonic connections.  And to implement the fix on all
> of my hosts.  And customers can implement it in a firewall, if
> they choose (and have boxes which can't be fixed: Win95, NT, Macs, ...).

That's for sure. The only thing that bothers me with this approach -
why we need all those stinking options in TCP SYN packets then?

> Avi

Dima





More information about the NANOG mailing list