httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: denial of service attack on web servers (fwd)
Date Sun, 20 Oct 1996 00:21:56 GMT
	This guy is describing a TCP-level denial of service
attack. It really doesn't have all that much to do with http per se, i
think. He's saying that you can connect to a server and when the
remote server closes the connection the client doesn't close the
connection, resulting in lots of FIN_WAIT2 states on the server
side. This is an attack on almost any tcp-based protocol, I think.
	I don't know what the implication of lots of FIN_WAIT2 states
on the server are though.. i'm completely sure its not nearly as bad
as lots of [the state that a TCP conn is in right after the first SYN]
connections, because the table for those is much smaller, I think.  I
don't think it is that bad, but I'm not a big kernel TCP expert. I'm
pretty certain it isn't a webserver-specific problem though.

> I've perhaps missed this guy's point, but he seems to be saying that
> people can cause a denial of service by holding connections open, and that
> it lasts for 240s at the TCP level.
> Apache has a default timeout of 400s, so does this make the slightest bit
> of difference ?
> Note, this was sent to CERT, so a swift response is called for before
> the vicious rumours spread.
> rob
> ----- Forwarded message from John Winans -----
> From: John Winans <>
> Date: Sat, 19 Oct 1996 10:20:03 -0500
> Message-Id: <>
> To:
> Subject: denial of service attack on web servers
> Cc:,,
> I believe that it would not be hard to take advantage of the situation I 
> describe below to create a denial of service attack that can cause problems 
> on a web server.  Depending on the server's implementation of TCP/IP these 
> problems could reach beyond the web server processes themselves.  The result
> at could range from a temporary denial of service to a server system crash.
> --John Winans 
> President
> Ganymede Corporation
> =============================================================================
> This past summer I researched a hanging problem that is talked about in the
> apache 'known bugs' section.  I don't entirely agree with the posted 'lab 
> report' in that it is simply Netscape bug.
> I ran tests from Netscape 2.x on Solaris, W95, and NetBSD making hits to
> Apache 1.1b3 running on plain NetBSD 1.1.  The stuff ruinning on W95 caused a 
> hanging problem.  What I observed was that after a keep-alive connection had 
> timed out, apache closed the socket on the server and it went into the 
> FIN_WAIT2 state and stayed there for a very long time.  FIN_WAIT2 is the 
> state of a TCP connection that is only 1/2 closed.  It can only entered by 
> the side of the connection that performs the active close on a TCP socket... 
> the web server. (See page 241 of "TCP/IP Illustrated Volume 1" by Richard 
> Stevens and run netstat on your web server to watch the socket state 
> transitions.)
> The 'bug' in this specific case is (probably) that a select statement in 
> Netscape (prior to the supposedly fixed version 3.x) that monitors activity 
> on its sockets is not reporting the EOF condition or Netscape is simply not 
> closing the socket at that time.  This results in a situation where Netscape
> (apparantly) thinks it can still use the 1/2 open socket.
> What bothered me was that this apparant "browser bug" was costing me resources 
> on my web server.  While this does appear to be a bug in Netscape and an annoyance to
a user accessing my web server, it is also representative of a greater 
> problem in the way we use the TCP protocol in HTTP.  In fact, I'll even go one 
> further... it is a problem in general with high transaction-rate servers where 
> the server performs the active-close operation on TCP connections (HTTP 
> keep-alive or not.)
> I invested a few hours in this problem and found that this is a taste of a 
> far greater problem.  This problem could be exploited to implement a denial 
> of service attack on a web server.
> Chapter 1 and pages 29 and 30 in "TCP Illustrated Volume 3", by Richard Stevens 
> include a technical discussion as to why this can be a serious problem.
> There is also a general discussion of this situation at:
> At the bottom you will find the following summary:
>   One scalability problem caused by the single request per connection
>   paradigm occurs due to TCP's TIME_WAIT state. When a server closes a
>   TCP, connection, it is required to keep information about that  
>   connection for a period of time, in case a delayed packet turns up and 
>   sabotages a new incarnation of the connection. 
>   The recommended time to keep this information is 240 seconds. Because 
>   of this, a server will leave some resources allocated for every single  
>   connection closed in the past four minutes. On a busy server, this can
>   add up to thousands of control blocks. 
> This summary is based on a web server and clients that are operating PROPERLY.  
> If someone wanted to, they could write a web walker that exploited the use of
> the FIN_WAITx states by opening sockets to web servers and simply never closing 
> them (or more accurately, never sending a FIN.)  When sockets get stuck in 
> FIN_WAITx2 they take far longer to time out than they do when they are in
> TIME_WAIT.  A flood of connections that are left stuck in FIN_WAITx could 
> consume a great deal of kernel memory and result in unexpected operation of the 
> networking subsystem or the kernel itself.
> I suspect that it may be possible to work with to push the internet 
> community into a new generation of safer HTTP protocol(s.)  After all, it is 
> groups like Apache and that delivered the free and useful software that 
> drove much of the web in the first place.  If an improvement to the security 
> and reliability of system operation can be made and demonstrated, the 'net'
> will have to buy into it or risk attacks (and bugs) that cause the types
> of service problems I describe.  
> -- 
> ! John Winans                     Ganymede Corp.                        !
> !                  !
> !                                                                       !
> !"The large print giveth, and the small print taketh away." - Tom Waits !
> ----- End of forwarded message from John Winans -----

Sameer Parekh					Voice:   510-986-8770
C2Net						FAX:     510-986-8777
The Internet Privacy Provider

View raw message