Re: Linux 2.4.27 SECURITY BUG - TCP Local (probable Remote) Denial of Service

[Willy Tarreau <willy@w.ods.org>]

Hi Peter,

On Sat, Sep 11, 2004 at 11:27:05PM -0700, Peter Zaitsev wrote:
 
> I do not care about TIME_WAIT  connection on client site itself, what
> concerns me is, until connection is not fully closed server side does
> not seems to be informed connection is dead and so  server resources are
> not deallocated.    
> 
> Any ideas ? 

TIME_WAIT status does not eat much resource, since they're in a separate
list. I've already had several *millions* of while stressing some equipment,
and I can assure you that it's really not a problem as long as you increase
your tcp_max_tw_buckets accordingly. There is even no performance impact
(I could still get 40000 hits/s with this number of time-waits). As David
said, the connection has been closed when it enters TIME_WAIT, so it has
been detached from apache.

I think you confuse it with CLOSE_WAIT. This is a very common case on web
servers when the client does not support HTTP keep-alive and does a
shutdown(WRITE) after sending its request. The server receives the FIN, and
passes from ESTABLISHED to CLOSE_WAIT during all the time it sends its data
to the client, then closes the connection, making it TIME_WAIT.

TIME_WAIT state is more annoying on the client side (eg when your apache
is a reverse proxy), because by default you can run out of source ports.
But you can increase the local source port range (ip_local_port_range),
decrease the FIN timeout which also happens to control TIME_WAIT timeout,
and even force tcp_tw_reuse to 1 to let the system reallocate an old
connection which was sitting in TIME_WAIT.

Hoping this helps,
Willy