Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of spc@conman.org designates
 66.252.224.242 as permitted sender)
Date: Sun, 4 Apr 2010 00:46:53 -0400
From: Sean Conner <spc@conman.org>
To: users@httpd.apache.org
Message-ID: <20100404044653.GA18178@brevard.conman.org>
References: <t2k560f92641004031632sb80677a3g4080712efb952150@mail.gmail.com>
 <hp8mcd$mo8$1@dough.gmane.org>
 <j2t560f92641004032011lafcbb303u7001a7fbbe545c37@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <j2t560f92641004032011lafcbb303u7001a7fbbe545c37@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Subject: Re: [users@httpd] Re: Preventing DoS attacks from single client host

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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org