The dreadful CLOSE_WAIT

[DervishD <raul@pleyades.net>]

    Hi all :))

    Seems under Linux that, when a connection is in the CLOSE_WAIT
state, the only wait to go to LAST_ACK is the application doing the
'shutdown()' or 'close()'. Doesn't seem to be a timeout for that.

    Well, I think this is dangerous because a bad application (and a
couple of widely used servers have this problem) can exhaust system
network resources (difficult, but possible). For example, a
concurrent FTP server with a race condition that doesn't do the
shutdown when the remote end aborts. Writing such a 'bad app' is very
easy, just do the socket->bind->listen->accept and after accepting
the connection forget the connected socket and keeps on listening. If
the remote end aborts, the server leaves the connection in
CLOSE_WAIT. Sometimes it has a associated timer, when data remains in
the tx queue, it seems that the kernel tries to retransmit all that
data, which makes no sense: in CLOSE_WAIT state the other end is not
there... Surely I'm missing a lot :((

    Since I don't know if a timeout (or another solution) exists to
avoid this I won't give names, but it's pretty easy to do a DoS
attack over a very known FTP server just using 'wget' and your
favourite C-c keys.

    IMHO, Linux (Unix) is about not allowing a bad app to screw the
system, and the CLOSE_WAIT state allows that. I know: you can screw
the system using as root an application that allocates and locks
large chunks of memory, or other 'legal' bad things, the sysadmin
should not allow the use of crappy software, but will do any harm a
CLOSE_WAIT timeout?

    Thanks a lot for your help :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/