There is about 10 source ips firing onto my server. All of them are dynamic dsl accounts; the only effective way to stop them was to block the all ip ranges of their isp. The problem was solved: 1. Apache connection limits increased dramatically and 2. FINALLY(!!!) configured iptables to recognize and drop excessive connection attempts: http://www.debian-administration.org/articles/187 Many thanks for replies! p.s. (offtopic) my honest wish is: PF (the OpenBSD Packet Filter) supported by Linux kernel :) -----Ursprüngliche Nachricht----- Von: Justin Pasher [mailto:justinp@xxxxxxxxxxxxxxxxxxx] Gesendet: Dienstag, 14. April 2009 21:25 An: users@xxxxxxxxxxxxxxxx Betreff: Re: AW: Connection flood: how to protect? 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|