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 to
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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
