general/5412: potential denial-of-service with CLOSE_WAIT

[Bill Moseley <mo...@best.com>]

>Number:         5412
>Category:       general
>Synopsis:       potential denial-of-service with CLOSE_WAIT
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Dec  3 06:30:01 PST 1999
>Last-Modified:
>Originator:     moseley@best.com
>Organization:
apache
>Release:        1.3.9
>Environment:
SunOS sunsite 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-Enterprise
>Description:
server-status showed six of 30 children sitting in 'D' status for a long time.  
All were requesting the same URL. All were different IP numbers, 
but all from the same network.

Hostnamelookups are off, but there was an .htaccess with a deny from a 
host name.  I assume that 'D' wasn't actually correct, that rather 'D'
had finished and was waiting on the connection to move to 'W'.
Correct assumption?

netstat showed all the connections in CLOSE_WAIT status.  A traceroute to
each of the IPs failed to connect to the remote host.  (Perhaps dynamic IPs)

Placing a connection in CLOSE_WAIT is a commonly know denial-of-service attack.
I'm not sure if this was our case or not.  

The Apache children were blocked from servicing requests for about 2 hours.
That 2 hours may have been the CLOSE_WAIT TCP timeout.

I can imagine a situation where someone manages to tie up MaxClients all in 
CLOSW_WAIT state and shut down httpd service.

I don't know network programming, but would it be possible for Apache to timeout
those connections and continue working without waiting for the socket?
We have our timeout setting at 180, and that works properly.

Thansks for your time.
>How-To-Repeat:

>Fix:

>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]