It was thus said that the Great Nerius Landys once stated:
> > This is called 'slow loris' attack. That'll give you something to Google for
> > :)
>
> Thank you so much for the help guys.
>
> I did Google "slowloris" and I did indeed find much information. In
> fact, the program I wrote from scratch does the exact attack described
> on the slowloris Wikipedia page.
From my understanding, the "slowloris" attack just means the clients make
a connection, then send a byte or two just under the server's timeout
setting to keep the connection "active", just slow. The real nasty part is
having hundreds of clients (say, from a botnet) make such requests.
> Anyhow, I hunted down a custom Apache module called mod_antiloris.
> This module limits the number of SERVER_BUSY_READ state connections
> from a single IP address. The default limit is 5 (I will turn mine up
> to 10 or more when I get it to work).
This sounds like it will handle such an attack from a single (or a few)
computers making multiple slow requests at the same time---this does nothing
if you are being attacked by a botnet (hundreds or thousands of different
computers all doing a single request).
> If you don't mind looking closely at the source code, go to
> pre_connection(), at the end of that function:
>
> if (ip_count > conf->limit) {
> ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL, "Rejected,
> too many connections in READ state from %s", c->remote_ip);
> return OK;
> } else {
> return DECLINED;
> }
>
>
> Apparently, we're returning what seems to be OK if ip_count is greater
> thyan conf->limit (which in my case is 5). And we return DECLINED
> (whatever that means) otherwise. Hrm. This seems backwards. First
> of all, how does my webserver even _work_ with this logic being
> backwards?
In terms of Apache modules, a module returns OK when it has handled the
request and further processing should end; otherwise, the module sends back
DECLINED to inform Apache that the request is still "live" and should be
routed to other modules as needed.
> If I think about it slightly longer, one possible scenario that would
> explain why the website is still working is as follows. The first 5
> connections from a client come in, and are denied. Somehow they
> linger somewhere and SERVER_BUSY_READ is still counted towards
> ip_count for these 5 denied connections. Then the 6th connection
> comes in, and is logged and accepted.
It could be that ip_count is kept per child process (or worker thread,
depending upon what Apache MPM is selected) and thus, you're seeing more
connections than intended (just a guess on my part---I haven't looked at the
code).
> Do you think just switching the "OK" with "DECLINED" in the source
> code would fix the problem?
Nope.
-spc
---------------------------------------------------------------------
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
|