AW: Connection flood: how to protect?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux