>SYN floods are boring. It doesn't do anything but block the listening
>socket. I'm sure the lamers will have fun with it, but as an attack, it's
>only good for a temporary Denial-of-Service. Most of us have already,
>or are trying to get the server listening queues increased, and the
>timeouts decreased enough to make this negligable anyway. This is a
>*good* argument for having the source code to the Web Server (eg. Apache),
>as you don't have to wait for the vendor to decide that the parm to the
>listen call should be in a config file somewhere.
first, my apologies if i have misunderstood your statements.
flooding the "accept" queue for the socket is *not* the problem.
it is one problem that SYN flooding demonstates. read stevens vol 3
chapter 14 sections on SYN_RCVD bug.
one structure member is used to hold two different timers.
a ~75 second connection establishment timer and the ~2 hour keepalive
timer. one can create a number of half-open sockets (in SYN_RCVD state)
on a server. each socket will remain open until either the keepalive
timer expires or the retry count is exceeded (~11 minutes).
enough SYN flooding can use all of the servers resources by
creating these half-open sockets. this depletes memory and other resources.
the 'accept' queue may remain virtually empty (0 or 1 waiting) thoughout
the code is in tcp_input.c
* Segment received on connection.
* Reset idle time and keep-alive timer.
tp->t_idle = 0;
tp->t_timer[TCPT_KEEP] = tcp_keepidle;
the assignment to tp->t_timer must be qualified by the state of
the socket|connection. as in "if (tp->t_state == TCPS_ESTABLISHED) "
the exact conditional must be checked against stevens vol1 and the RFC's.
Jonathan M. Bresler 202-452-2831 breslerj @
MS-169 Federal Reserve Board of Governors Washington DC 20551
Speaking for myself. Others speak for the Federal Reserve Board of Governors