TCP SYN attacks

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
> 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

(quoting myself):

  (heck, with 10 secs I sometimes cannot even get all the images

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 (, 30 hops max, 40 byte packets
   1 ( 159 ms 106 ms 10 ms
   2 sl-dc-17-S1/ ( 11 ms 7 ms 15 ms
   3 sl-dc-6-F0/ ( 19 ms 8 ms 8 ms
   4 sl-stk-5-H1/ ( 80 ms 81 ms 79 ms
   5 sl-stk-16-F0/ ( 77 ms 79 ms 81 ms
   6 ( 223 ms 101 ms 162 ms
   7 ( 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?