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 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... -----Ursprüngliche Nachricht----- Von: Justin Pasher [mailto:justinp@xxxxxxxxxxxxxxxxxxx] Gesendet: Dienstag, 14. April 2009 19:57 An: users@xxxxxxxxxxxxxxxx Betreff: Re: Connection flood: how to protect? Kanstantin Reznichak wrote: > Hello, > > Thank you for reply. Unfortunately, mod-limitipconn seems to act too late. > After installing and enabling it: > <Location /> > MaxConnPerIP 15 > </Location> > > Netstat shows: > # netstat -atn > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN > tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930 SYN_RECV > tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316 SYN_RECV > tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147 SYN_RECV > tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854 SYN_RECV > ... If I'm reading the netstat results correctly, it looks like the connections are still in the very early stages of initialization (maybe they haven't even reached apache yet). It resembles a synflood attack, I believe, but I could be wrong. If that truly is the case, that sort of thing is handled by the firewall. I personally have not have any problems with mod_limitipconn properly restricting the number of connections from a single IP address. Keep in mind that is it context specific too (i.e. if the directive is defined inside a VirtualHost, it only applies to that VirtualHost). Perhaps it's just not being applied to the context where you think it should be applied. Do the entries show up in your apache log at all? Now that I think about it a little more, are you using your test script to check this? The test script didn't actually send any HTTP commands, did it? If not, then that is probably the problem. I think mod_limitipconn won't actually kick in until you try to make the request. It will then return a 503 error to the browser (indicating the service is unavailable). -- 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