[Page 1, 2 Next]

Topic: Request: Already compiled mod_antiloris.so

[1]

Topic: Request: Already compiled mod_antiloris.so

[flatcircle]

Hello,

Can someone post the mod_antiloris.so which is compatible with Apache on a Windows box?

I tried the version from http://www.webhostingtalk.com/showthread.php?t=878634 (look for the zip file)

But I also get a message that mod_antiloris.so file is not a valid Win32 application.

More info about this serious exploit: http://ha.ckers.org/slowloris/


Thanks a lot.
Regards.

[James Blond]

The .so extension is right. But that file from the link you posted is compiled on linux for linux. So you can't use it.

[flatcircle]

Was afraid so.

Can the same sourcecode be used to compile this module for Windows? (Sorry if this is a noob question.)

Seems like this mod_antiloris module is a very good defence against Slowloris.

A pity that there's no Apache/Win module around. (which is quite surprising due to the fact that this is a very big exploit....

[glsmith]

<SoapBox>
Due to the fact it is only a DOS and nothing more it is not the end of the world. It's not viral nor does it have characteristics of a worm like old Code Red, so I would not go as far as calling it a serious exploit. In fact, it is a quite brilliant and simple attack that eats up the available connections and holds them open. There are other open and closed source web servers that can suffer the same.

Typical simplified session
connection -> open
headers/data -> send/receive
connection -> close

The DOS attact
connection -> open
repeat untill server eventually quits responding

So in this sense, if the DOSer (I refuse to call it an exploit) sends an open connection every second, and Apache can handle 100 connection at any one time, it's going to be DOSed in 100 seconds.

The way Apache is configured by default is partially to blame because by default it will hold a connection open for 300 seconds (5 minutes). In the above simplified example. that leaves 200 seconds before the first connection finally times out and is free to answer anyone again.

I think this setting is a hold over from the first version of Apache and in this day and age it is rather ridiculous! I mean, we're not on 200 baud cradle modems anymore! If a client cannot finish a request in a reasonable amount of time does it really deserve special treatment or should Apache just give up much sooner and say "Sorry Charley, your too darn slow?"

Shorter timeouts are a big key to the puzzle and a pretty decent mitigation in themselves without the need of any module. A timeout of 30 seconds will help.

This module is nothing special, meaning there is nothing in it *nix only and I can get it to compile with some ever so slight modification. It was defiantly written by someone who uses GCC. It also loads with no problem.

To me this modules as I look at it is very similar to mod_limitipconn in the fact that it limits the allowed number of connections from any single IP source to 5. Knowing the results of mod_limitipconn as well as mod_evasive when you pass their limits, Apache will start sending 403s back when the source IP goes over that number, but then will it if the connection attempt never goes passed "Hello?"

Another problem I see with these type of modules is they have to build a table of IPs and connection counts for every single IP. In a true DDOS, that table is going to be huge, a couple hundred thousand IPs worth. On a not so resourceful server it could, in theory, consume all available memory at which point it is not just going to be Apache that is lost, but everything on the server. Smtp, pop3, ftp, ability to login to server locally etc.
</SoapBox>

<RealBIGSoapBox>
Apache 2.x really needs the ability to ignore a connection request, as it could back in 1.3.x. In 1.3.x, a Deny from xxx.xxx.xxx.xxx will simply not respond at all to that IP while in 2.x it sends back a 403. This in itself allows a DOS much more easily than could be done in 1.3.x as 1.3.x simply refused to answer and your browser/DOSer would eventually timeout. In a sense, that alone would slow down most DOSers itself.
</RealBIGSoapBox>

<SoapBox>
Now, fortunately, from what I've read this DOSer is not a hammerer, meaning it is not horribly aggressive ergo "Slow"loris. If this DOSer was ever put on a botnet however and turned against you, you are going to still get DOSed pure and simple, with or without a module. A couple hundred thousand 403s every second as I suspect this module is going to do is going to DOS your connection and/or Apache most likely anyway. It will foil a single attacker, but just a low timeout most likely would as well.
</SoapBox>

For the reasons stated above I personally do not think this module is worth the effort and had it taken more than 5 minutes to get built I would have given up. I'm not saying it actually works, it built, it loads and shows up in the SERVER_SOFTWARE environment var. That's as far as I messed with it. I want to try and trip it with a browser to see how it acts before I hand it out. I must admit it is a simple creature, you load or you do not, no configuration beyond that.

In the meantime, any comments on or corrections to my comments above I would like to hear.

[flatcircle]

Thank your for your information.

I've looked up some information about the Slowloris issue but for me it's not clear if the mod_limitpconn module 'neutralises' Slowloris requests.

Some say that Slowloris will do the request before the modules mod_limitconn (or mod_security) come into play. It seemed to me that mod_antiloris was capable to handle Slowloris requests.

You're absolutely right that when your website will be the target of a massive DOS attack, your server will go probably down. However, I want to secure my server against the 'scriptkiddies' (no 'real' hackers) who will occasionally try to bring down your webserver. We're hosting some webservers at our University and as you probably know those kidz are testing our servers a lot Just want to be prepared when a kid launches Slowloris on our sites.

Looks like lowering the Timeout is not 100% waterproof. (see: http://threatpost.com/blogs/mitigating-slowloris-http-dos-attack)

[glsmith]

Well, for one single reason mostly in my comments above, and your statement as well, I'm going to eat crow and retract my last statement.

It is no doubt that on a DSL connections, even with a low timeout we probably will get DOSed by it. I honestly think I was being attacked about two weeks after it came out. Every time I went to my server it would not respond. Lowering the timeout seemed to fix the problem. It's leaves no trace so who really knows.

I did not get a chance to hammer on this module as I have something I am working on that for me is more of a priority. Maybe you can launch slowloris on yourself and let us all know how it goes.

As promised;

This one built with Visual Studio 2008 (VC9) for Apache 2.2 distributions like the one here;

http://www.apachehaus.com

[flatcircle]

Thanks a lot.

I will do some further testing to see if this module is capable handling Slowloris 'attacks'.

I'll post the results when I'm done.
To be continued....

[glsmith]

21 hours after loading it...

If nothing else, it's pretty good against aggressive download managers .. the ones that lie and say they are MSIE 5.0 Windows 98 tho they're using IE8 on Win7 following this persons trip through the website.

ip-203-80-62-71.horizonpacific.com - - [27/Aug/2009:03:00:54 -0700] "GET /favicon.ico HTTP/1.1" 200 1430 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1;

It's throws a 503 error

[Thu Aug 27 03:01:51 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:52 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:53 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71
[Thu Aug 27 03:01:53 2009] [warn] Rejected, too many connections in READ state from 203.80.62.71

I thought this may have been mod_limitipconn since I use it too but the error msg is from mod_antiloris

[flatcircle]

mod_antiloris contains code from mod_limitipconn but mod_limitipconn wil only come into play when the headers are received => too late => this means mod_limitipconn will not defend your site aginst Slowloris.

Mod_antiloris works when the connection is setup and will (default) limit the number of threads to 5 from each IP. This limit will only occur for threads which are in the 'read' state.

Didn't have to time yet to test out all the modules which claim to protect against Slowloris. First thing tomorrow...I'll report back asap.

Regards.

[flatcircle]

mod_dosevasive

In the suggested default configuration it'll block any IP that makes more than 2 requests for the same page
in 1 second or less, plus any IP that makes more than 50 requests to the site in 1 second or less. When that
happens that IP becomes blocked for 10 seconds.

=> no protection

[warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting



mod_limitipconn

This is an Apache 2.2 C module whose purpose is to limit the maximum
number of simultaneous connections per IP address.

=> no protection

[warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting



mod_antiloris

mod_antiloris contains code from mod_limitipconn but mod_limitipconn wil only come into play when the headers are received => too late => this means mod_limitipconn will not defend your site aginst Slowloris.

Mod_antiloris works when the connection is setup and will (default) limit the number of threads to 5 from each IP. This limit will only occur for threads which are in the 'read' state.


=> Works great! Firing a couple of Slowloris attacks from different machines and my server is still up & running.

[warn] Rejected, too many connections in READ state from xx.xx.xx.xx


Like I said, this will not prevent your site going down when it's the target of a real massive DOS-attack. However, this mod_antiloris works great to prevent your server from scriptkiddies trying to annoy you


Remember that you can override the default value of 5 by using 'IPReadLimit' in your config.


I tried the 2 modules (built with Visual Studio 2008 and the one built with VC6). Both are working for my server.
I'm using the Apache binary from www.apache.org, so I guess the VC6-compiled version will be best?


Regards.

[glsmith]

Thanks for following up. I understand the other modules ... just didn't know much about this one.

For an ASF release yes, I think the VC6 one should be more stable.

[flatcircle]

No prob.
Thank you for helping me with the compiling of the module!

Regards.

[demostenes]

[glsmith]

The module has been moved to the download page at
http://www.apachehaus.com

[demostenes]

I have tested the module with Apache win32 VC9 2.12 and it's OK
This mod block only the IP of SlowLoris attack and show a blank page (Header 200 OK) only for this IP.
From other IP the web continues to working normally.
Work fine!
Thanks!

[glsmith]

Thank you for the results of your testing

Gregg

[flatcircle]

Hello

Seems like there are some other modules around which can mitigate Slowloris attacks.

mod-pacify-slowloris
http://code.google.com/p/mod-pacify-slowloris/source/browse/#svn/trunk


mod_noloris
http://svn.eu.apache.org/viewvc/httpd/httpd/trunk/modules/experimental/mod_noloris.c

Anybody around who did some testing? (or has a compiled Windows version available?)

Regards.

[glsmith]

I can get mod_noloris to compile, only problem is it will only compile against and work under Apache 2.3/2.4 (currently 2.3.3-alpha).

The other one uses the dreaded unistd.h (read unix) which there are work arounds for, but none that I tried have worked. Giving up on it.

[flatcircle]

Thanks for checking this out!

(I guess I really should do some research on compiling those thingies myself and not bother you with this

[glsmith]

I don't know .. I see it as challenge anymore.

I must admit that having mod_antiloris for Windoze over at the Haus has driven site visitation up. So you did a good deed when you kicked the soapboxes out from under me earlier this year! In that respect, Thank you!

Gregg