Dealing with HTTP w00tw00t attacks

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.

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

Iv also started seeing these types of messages in my log files. One way to prevent these types of attacks is to setup fail2ban( http://www.fail2ban.org/ ) and setup specific filters to black list these ip address in your iptables rules.

Heres a example of a filter that would block the ip address associated with making those messages

[Tue Aug 16 02:35:23 2011] [error] [client ] File does not exist: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec:) === apache w00t w00t messages jail - regex and filter === Jail

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Filter

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

w00tw00t.at.blackhats.romanian.anti-sec is a hacking attempt and uses spoof IP's so lookups such as VisualRoute will report China,Poland,Denmark etc according to the IP being seconded at that time. So setting up a Deny IP or resolvable Host Name is well nigh impossible as it will change within an hour.

I personally wrote a Python script to auto-add IPtables rules.

Here's a slightly abbreviated version without logging and other junk:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

I believe the reason mod_security isn't working for you is that Apache hasn't been able to parse the requests themselves, they are out-of-spec. I'm not sure you have a problem here - apache is logging weird shit that is happening out on the net, if it doesn't log it you won't be aware its even happening. The resources required to log the requests is probably minimal. I understand its frustrating that someone is filling up your logs - but it will be more frustrating if you disable logging only to find you really need it. Like someone broke into your webserver and you need the logs to show how they broke in.

One solution is to setup ErrorLogging through syslog, and then using rsyslog or syslog-ng you could specifically filter and discard these RFC violations regarding w00tw00t. Or alternatively you could filter them into a separate log file simply so your main ErrorLog is easy to read. Rsyslog is incredibly powerful and flexible in this regard.

So in httpd.conf you might do:

ErrorLog syslog:user 

then in rsyslog.conf you might have:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

Be aware, this approach will actually use many times more resources than originally used logging directly to a file. If your webserver is very busy, this could become a problem.

Its best-practice to have all logs sent to a remote logging server as soon as possible anyway and this will benefit you should you ever get broken into as it is much more difficult to erase the audit trail of what was done.

IPTables blocking is an idea, but you may end up with a very large iptables block list which can have performance implications in itself. Is there a pattern in the IP addresses, or is it coming from a large distributed botnet? There will need to be X% of duplicates before you will get a benefit from iptables.

You say in Update 2:

Problem that still remains The problem that still remains is as follows. These attacks are from bots that search for certain files on your server. This particular scanner searches for the file /w00tw00t.at.ISC.SANS.DFind:).

Now you can just ignore it which is most recommended. The problem remains that if you do have this file on your server somehow one day, you are in some trouble.

From my previous reply we gathered that Apache is returning an error messages due to a poorly formed HTML 1.1 query. All webservers supporting HTTP/1.1 should probably return an error when they receive this message (I've not double checked the RFC - perhaps RFC2616 tells us).

Having w00tw00t.at.ISC.SANS.DFind: on your server some where does not mystically mean "you are in some trouble"... If you create the w00tw00t.at.ISC.SANS.DFind: file in your DocumentRoot or even DefaultDocumentRoot it does not matter... the scanner is sending a broken HTTP/1.1 request and apache is saying "no, that's a bad request... good bye". The data in the w00tw00t.at.ISC.SANS.DFind: file will not be served.

Using mod_security for this case is not required unless you really want to (no point?)... in which case, you can look at patching it manually (link in other answer).

Another thing you could possibly look at using is the RBL feature in mod_security. Perhaps there is a RBL online some where that provides w00tw00t IPs (or other known malicious IPs). This would however mean that mod_security does a DNS lookup for every request.

How about adding a rule to modsecurity? Something like this:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

I see that most of the solutions are already covered above however I would like to point out that not all client sent HTTP/1.1 request without hostname attacks are aimed directly on your server. There are many different attempts to fingerprint and/or exploit the network system preceding your server i.e. using:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

to target the Linksys routers etc. So sometimes it helps to widen your focus and divide your defense efforts between all systems with an equal share i.e.: implement router rules, implement firewall rules (hopefully your network has one), implement server firewall/IP table rules and related services i.e. mod_security, fail2ban and so on.

how about this ?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

works fine for me.