Blocking w00tw00t

[Myatu]

Given a recent topic about it (http://forum.ovh.co.uk/showthread.php?t=4330), here's a little how-to I'm reposting from my blog for dealing with "w00tw00t" scans on webservers. You might see these scans in your logs as:

... "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 ...

Using Iptables

The quickest method of making sure it never reaches your webserver (and thus wasting resources like processor, disk space [log files], etc) is to use iptables, and it can be done with a one-liner like this:

iptables -I INPUT -d xxx.xxx.xxx.xxx -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Simply replace xxx.xxx.xxx.xxx with the IP of your web server. If you want to use this for a range of IPs (ie., you're using failover IPs to host web servers), simply replace the "-d xxx.xxx.xxx.xxx" portion with:

-m iprange --dst-range start.xxx.xxx.xxx-end.xxx.xxx.xxx

where start.xxx.xxx.xxx and end.xxx.xxx.xxx are the first and last IPs of your web servers respectively.

If you wish to have a fancier option, one where it will for example blacklist an IP for a certain period, etc., have a look at SpamCle@ner's website (http://spamcleaner.org/en/misc/w00tw00t.html).

They go deeper into this subject and have provided two scripts near the end of their article. Simply save one of these scripts in a file named, for example, /opt/blockw00t.sh and make it executable with:

chmod +x /opt/blockw00t.sh

You can run it manually with typing "/opt/blockwoot.sh" in the shell or to automatically load it at boot time you can add it to your /etc/rc.localfile, or on Debian/Ubuntu systems add it to your /etc/network/interfaces like so:

auto eth0
inet eth0 static
... [existing configuration that remains unaltered] ...
# Load anti-w00t script:
post-up /opt/blockw00t.sh

Using Fail2Ban

If you are using Fail2Ban (http://www.fail2ban.org), you can create a new definition that scans for the w00tw00t entries in the webserver log files.

The following definition assumes your webserver log entries look like the following (Nginx and Apache 2):

203.127.11.214 - - [15/Jul/2010:15:50:04 +0200] "GET /w00tw00t.at.ISC.SANS.test0:) HTTP/1.1" 400 173 "-" "-"

Create a file /etc/fail2ban/filter.d/webserver-w00tw00t.conf
[Definition]
failregex = ^<HOST> .*"GET \/w00tw00t\.at\.ISC\.SANS\..+\:\).*?"
ignoreregex =

This catches the known variants of the scanner, including "DFind", "test0", "MSlog" and "ntsvc".

*Note: The <HOST> portion is specific to fail2ban and is a shorthand for the regex (?:::f{4,6}:)?(?P<host>\S+), which matches either an IPv4 or IPv6 address. See the fail2ban manual (http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Filters) for more details.

*Tip: If you wish to change the regular expression, I recommend RegExr (http://gskinner.com/RegExr/) to play with various options/search criteria. It's a time saver and free :)

*Tip 2: To test your definition's regular expression, use:
fail2ban-regex logfile /etc/fail2ban/filter.d/webserver-w00tw00t.conf
Where logfile is the actual log file name, such as /var/log/apache2/access.log.

Add this definition to the fail2ban Jail configuration (/etc/fail2ban/jail.conf):
... [existing configuration] ...

[webserver-w00tw00t]
enabled = true
port = http,https
filter = webserver-w00tw00t
# !!! Keep in mind to specify the correct web server log here:
logpath = /var/log/apache2/access.log
maxretry = 1
# Time in seconds, in this case, one day:
bantime = 86400



Now reload the service (ie., "/etc/init.d/fail2ban reload" or "service fail2ban reload").

Edit: Version 0.8.3 (Debian lenny default) seems to have a little hiccup with this. I recommend upgrading to 0.8.4 of fail2ban (Ubuntu default).

[Rilly]

Thanks Myatu!

[Rilly]

Its funny... i installed a webserver on one of my servers that I didn't have a web server running on it.. and within 3 minutes of it being installed, i started having these showing up in the logs.. 3 MINUTES!

I had IPs scanning with w00tw00t before i even had tested the standard HTML that gets dropped in the www folder

[Myatu]

I had IPs scanning with w00tw00t before i even had tested the standard HTML that gets dropped in the www folder

Yeah, they try to hit you when you're off guard... That's all it takes!

[freshwire]

For the amount I get it is actually a lot more wasteful to spend time with the above solutions. Do you guys really get so many of these?

[Rilly]

yeah, my logs were full of these from about 6-7 different IP addresses.. all day all night.

[LawsHosting]

I use Webmin for IPTables manipulation, but when I add this to the /etc/iptables.up.rules file and apply it, it spits its dummy at me
Bad argument `/w00tw00t.at.ISC.SANS.''

[Myatu]

Hmm, the only thing I can think of right now is to make sure the "GET /..." portion is enclosed in (double) quotes

[IainK]

I host a virus at the URL /w00tw00t* so more fool them for scanning me :P

[spid3r1987]

Given a recent topic about it (http://forum.ovh.co.uk/showthread.php?t=4330), here's a little how-to I'm reposting from my blog for dealing with "w00tw00t" scans on webservers. You might see these scans in your logs as:

... "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 ...

Using Iptables

The quickest method of making sure it never reaches your webserver (and thus wasting resources like processor, disk space [log files], etc) is to use iptables, and it can be done with a one-liner like this:

iptables -I INPUT -d xxx.xxx.xxx.xxx -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Simply replace xxx.xxx.xxx.xxx with the IP of your web server. If you want to use this for a range of IPs (ie., you're using failover IPs to host web servers), simply replace the "-d xxx.xxx.xxx.xxx" portion with:

-m iprange --dst-range start.xxx.xxx.xxx-end.xxx.xxx.xxx

where start.xxx.xxx.xxx and end.xxx.xxx.xxx are the first and last IPs of your web servers respectively.

If you wish to have a fancier option, one where it will for example blacklist an IP for a certain period, etc., have a look at SpamCle@ner's website (http://spamcleaner.org/en/misc/w00tw00t.html).

They go deeper into this subject and have provided two scripts near the end of their article. Simply save one of these scripts in a file named, for example, /opt/blockw00t.sh and make it executable with:

chmod +x /opt/blockw00t.sh

You can run it manually with typing "/opt/blockwoot.sh" in the shell or to automatically load it at boot time you can add it to your /etc/rc.localfile, or on Debian/Ubuntu systems add it to your /etc/network/interfaces like so:

auto eth0
inet eth0 static
... [existing configuration that remains unaltered] ...
# Load anti-w00t script:
post-up /opt/blockw00t.sh

Using Fail2Ban

If you are using Fail2Ban (http://www.fail2ban.org), you can create a new definition that scans for the w00tw00t entries in the webserver log files.

The following definition assumes your webserver log entries look like the following (Nginx and Apache 2):

203.127.11.214 - - [15/Jul/2010:15:50:04 +0200] "GET /w00tw00t.at.ISC.SANS.test0:) HTTP/1.1" 400 173 "-" "-"

Create a file /etc/fail2ban/filter.d/webserver-w00tw00t.conf
[Definition]
failregex = ^<HOST> .*"GET \/w00tw00t\.at\.ISC\.SANS\..+\:\).*?"
ignoreregex =

This catches the known variants of the scanner, including "DFind", "test0", "MSlog" and "ntsvc".

*Note: The <HOST> portion is specific to fail2ban and is a shorthand for the regex (?:::f{4,6}:)?(?P<host>\S+), which matches either an IPv4 or IPv6 address. See the fail2ban manual (http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Filters) for more details.

*Tip: If you wish to change the regular expression, I recommend RegExr (http://gskinner.com/RegExr/) to play with various options/search criteria. It's a time saver and free :)

*Tip 2: To test your definition's regular expression, use:
fail2ban-regex logfile /etc/fail2ban/filter.d/webserver-w00tw00t.conf
Where logfile is the actual log file name, such as /var/log/apache2/access.log.

Add this definition to the fail2ban Jail configuration (/etc/fail2ban/jail.conf):
... [existing configuration] ...

[webserver-w00tw00t]
enabled = true
port = http,https
filter = webserver-w00tw00t
# !!! Keep in mind to specify the correct web server log here:
logpath = /var/log/apache2/access.log
maxretry = 1
# Time in seconds, in this case, one day:
bantime = 86400



Now reload the service (ie., "/etc/init.d/fail2ban reload" or "service fail2ban reload").

Edit: Version 0.8.3 (Debian lenny default) seems to have a little hiccup with this. I recommend upgrading to 0.8.4 of fail2ban (Ubuntu default).

hey, iv tried following your instructions to block a range of ip's from w00tw00t
but whenever i enter
iptables -I INPUT -m iprange 178.xxx.xxx.xxx-178.xxx.xxx.xxx -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
and all i get is
"iptables: Unknown error 4294967295"
help?? lol

[Myatu]

all i get is
"iptables: Unknown error 4294967295"
help?? lol

Are you trying this from within a VM, like OpenVZ/Proxmox Container/Virtuozzo? If so, you need to lift some iptable restrictions or do this on the host instead.

Also, the kernel needs to have been compiled with "CONFIG_NETFILTER_XT_MATCH_STRING=m" (which is standard, unless you run an ancient kernel).

[spid3r1987]

Are you trying this from within a VM, like OpenVZ/Proxmox Container/Virtuozzo? If so, you need to lift some iptable restrictions or do this on the host instead.

Also, the kernel needs to have been compiled with "CONFIG_NETFILTER_XT_MATCH_STRING=m" (which is standard, unless you run an ancient kernel).
from ssh
on centos with parallels plesk panel
logged into ssh using root
followed your guide and get that error
i have 3 failover ip's assigned to my websites...
i have tried doing it per individual IP or in a block xxx.xxx.xxx.18,19,20
etc

[Myatu]

Hmm. I think it is attributed to using the --algo option for string matching, are you using a custom or OVH kernel? It should work just fine with an out-of-the-box CentOS distro.

The one thing I can think of in this case, is to use the "Fail2ban" option instead - it won't be instant filtering, but repetitive abusers will be stopped.

[spid3r1987]

Hmm. I think it is attributed to using the --algo option for string matching, are you using a custom or OVH kernel? It should work just fine with an out-of-the-box CentOS distro.

The one thing I can think of in this case, is to use the "Fail2ban" option instead - it won't be instant filtering, but repetitive abusers will be stopped.
ovh kernal, nt sure how to find which version though...

[Neil]

ovh kernal, nt sure how to find which version though...

uname -a will tell you the version, also in the OVH Manager under the RTM as well in Server Status.

[spid3r1987]

Linux .......ovh.net 2.6.38.2-xxxx-std-ipv6-32 #0 SMP Wed Apr 13 08:23:09 UTC 2011 i686 i686 i386 GNU/Linux