Dealing with HTTP w00tw00t attacks

I have a server with apache and I recently installed mod_security2 because I get attacked a lot by this:

My apache version is apache v2.2.3 and I use mod_security2.c

This were the entries from the error log:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Here are the errors from the access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"

I tried configuring mod_security2 like this:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

The thing in mod_security2 is that SecFilterSelective can not be used, it gives me errors. Instead I use a rule like this:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Even this does not work. I don't know what to do anymore. Anyone have any advice?

Update 1

I see that nobody can solve this problem using mod_security. So far using ip-tables seems like the best option to do this but I think the file will become extremely large because the ip changes serveral times a day.

I came up with 2 other solutions, can someone comment on them on being good or not.

The first solution that comes to my mind is excluding these attacks from my apache error logs. This will make is easier for me to spot other urgent errors as they occur and don't have to spit trough a long log.
The second option is better i think, and that is blocking hosts that are not sent in the correct way. In this example the w00tw00t attack is send without hostname, so i think i can block the hosts that are not in the correct form.

Update 2

After going trough the answers I came to the following conclusions.

To have custom logging for apache will consume some unnecessary recourses, and if there really is a problem you probably will want to look at the full log without anything missing.
It is better to just ignore the hits and concentrate on a better way of analyzing your error logs. Using filters for your logs a good approach for this.

Final thoughts on the subject

The attack mentioned above will not reach your machine if you at least have an up to date system so there are basically no worries.

It can be hard to filter out all the bogus attacks from the real ones after a while, because both the error logs and access logs get extremely large.

Preventing this from happening in any way will cost you resources and it is a good practice not to waste your resources on unimportant stuff.

The solution i use now is Linux logwatch. It sends me summaries of the logs and they are filtered and grouped. This way you can easily separate the important from the unimportant.

Thank you all for the help, and I hope this post can be helpful to someone else too.

Solution 1:

From your error log they are sending a HTTP/1.1 request without the Host: portion of the request. From what I read, Apache replies with a 400 (bad request) error to this request, before handing over to mod_security. So, it doesn't look like your rules will be processed. (Apache dealing with it before requiring to hand over to mod_security)

Try yourself:

telnet hostname 80
GET /blahblahblah.html HTTP/1.1  (enter)
(enter)

You should get the 400 error and see the same error in your logs. This is a bad request and apache is giving the correct answer.

Proper request should look like:

GET /blahblahblah.html HTTP/1.1
Host: blah.com

A work around for this issue could be to patch mod_uniqueid, to generate a unique ID even for a failed request, in order that apache passes the request on to its request handlers. The following URL is a discussion about this work around, and includes a patch for mod_uniqueid you could use: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Couldn't find any other solutions for it and wonder if a solution is actually required.

Solution 2:

Filtering IPs is not a good idea, imho. Why don't try filtering the string you know?

I mean:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP