httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Pasher <>
Subject Re: AW: [users@httpd] Connection flood: how to protect?
Date Tue, 14 Apr 2009 19:24:43 GMT
Kanstantin Reznichak wrote:
> The script from my first post send the single "GET / HTTP 1.1" line,
> followed by <CR><LF>. The request is incomplete so mod_limitipconn seems
> wait until client complete the request headers block (by sending
> <CR><LF><CR><LF>) in order to reject the request: RFC-conform
behaviour, but
> absolutely useless in this case. That produces alot of "ESTABLISHED"
> connections (btw, much more than allowed by mod_limitipconn 10). Such kind
> of attack can be tracked by error_log:
> [Tue Apr 14 20:43:36 2009] [error] [client x.x.x.x] request failed: error
> reading the headers

That seems to confirm my suspicion. mod_limitipconn won't kick in until 
the request is actually made, which means that it won't work for "bots" 
that don't actually complete the connection. However, are you actually 
experiencing a problem with more than a handful of people doing this, or 
it more academic? Except in the case where someone specifically codes 
something to do this (like your script), a normal connection will be 
completed correctly, and mod_limitipconn will kick in. If someone is 
truly abusing this by opening connections and not completing the 
request, it sounds like an issue better handled by the firewall (i.e. 
just block them). On my servers, I have very little tolerance for people 
that try to abuse things, such as spamming forms or trying to find SQL 
injection spots. If I see that happening, I block them. You may 
occasionally block a dynamic IP that another poor soul acquires later 
on, but I'd rather block a few innocent people than have someone hack 
into a web site through a security hole.

> The script can also be turned into "synflood" one: just comment-out the line
> that sends a "GET" to the server. That causes alot of "SYN_RECV"-like
> connections and no records in Apache logs. 
> Both variants cause the server to be unavailable. The first one is
> definitely an Apache issue. However, I'm not really sure whether that's a
> bug or not...

I wouldn't really classify it as a bug, although it's still annoying to 
deal with. It's kind of the nature of TCP connections. Anytime you try 
to establish a connection to a TCP service, the remote end receives the 
request, sends a reply, and waits for an answer. If an answer is not 
received within a certain time frame (i.e. the timeout setting defined 
by that service or daemon), the connection drops. Otherwise, it will 
have to continue to wait for a response. This is critical for situations 
where the connection is either very slow or is flaky and drops out 
frequently. The "Timeout" directive in Apache is what determines how 
long Apache will wait.

Justin Pasher

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message