应对HTTP w00tw00t攻击

我有一台装有apache的服务器，最近安装了mod_security2，因为我受到了很多攻击：

我的apache版本是apache v2.2.3，我使用的是mod_security2.c

这是错误日志中的条目：

[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:)

以下是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 "-" "-" 

我试过像这样配置mod_security2：

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:\)"

mod_security2中的问题是无法使用SecFilterSelective，它给了我错误。相反，我使用这样的规则：

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:\)"

即使这样也不起作用。我不知道该怎么办了。有人有什么建议吗？

更新1

我看到没有人可以使用mod_security解决此问题。到目前为止，使用ip-tables似乎是执行此操作的最佳选择，但我认为文件会变得非常大，因为ip每天会更改服务器次数。

我想出了另外两种解决方案，有人可以对它们的优劣发表评论。

1. 我想到的第一个解决方案是将这些攻击从我的Apache错误日志中排除。这将使我更容易发现其他紧急错误，因为它们很容易发生，而不必吐槽。

2. 我认为第二种方法更好，那就是阻止未以正确方式发送的主机。在此示例中，发送的w00tw00t攻击没有主机名，因此我认为我可以阻止格式不正确的主机。

更新2

经过深入的回答后，我得出以下结论。

1. 为apache定制日志将消耗一些不必要的资源，如果确实存在问题，您可能希望查看完整的日志而不会丢失任何内容。

2. 最好只忽略匹配，而专注于分析错误日志的更好方法。为日志使用过滤器是解决此问题的一种好方法。

关于这个问题的最终想法

如果您至少拥有最新的系统，则上述攻击将不会对您的计算机造成影响，因此基本上没有后顾之忧。

过一会儿很难过滤掉所有虚假的攻击，因为错误日志和访问日志都变得非常大。

防止这种情况以任何方式发生都会浪费您的资源，并且最好不要将资源浪费在不重要的东西上。

我现在使用的解决方案是Linux logwatch。它向我发送日志摘要，并对其进行过滤和分组。这样，您可以轻松地将重要事项与不重要事项区分开。

谢谢大家的帮助，我希望这篇文章对其他人也能有所帮助。

他们从错误日志中发送了HTTP / 1.1请求，而没有请求的Host：部分。根据我的阅读，在移交给mod_security之前，Apache对此请求回复了400（错误请求）错误。因此，看起来您的规则不会被处理。（Apache在要求移交给mod_security之前先进行处理）

尝试一下：

telnet主机名80
GET /blahblahblah.html HTTP / 1.1（输入）
（输入）

您应该得到400错误，并在日志中看到相同的错误。这是一个错误的请求，Apache给出了正确的答案。

正确的请求应如下所示：

GET /blahblahblah.html HTTP / 1.1
主持人：blah.com

解决此问题的方法可能是修补mod_uniqueid，甚至为失败的请求生成唯一的ID，以便apache将请求传递到其请求处理程序。以下URL是有关此变通方法的讨论，并包含可使用的mod_uniqueid补丁：http ://marc.info/?l=mod-security-users&m=123300133603876&w=2

找不到其他解决方案，想知道是否确实需要解决方案。

恕我直言，过滤IP不是一个好主意。为什么不尝试过滤您知道的字符串？

我的意思是：

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

IV也开始在我的日志文件中看到这些类型的消息。防止此类攻击的一种方法是设置fail2ban（http://www.fail2ban.org/）并设置特定的过滤器以在iptables规则中将这些IP地址列入黑名单。

这是一个过滤器的示例，该过滤器将阻止与发出这些消息相关的IP地址

[2011年8月16日星期二02:35:23] [错误] [客户端]文件不存在：/var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t消息监狱-正则表达式和过滤器===监狱

 [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

过滤

 # 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是一种黑客尝试，并使用欺骗IP，因此诸如VisualRoute之类的查询将根据当时被借用的IP报告中国，波兰，丹麦等。因此，设置拒绝IP或可解析的主机名几乎是不可能的，因为它会在一小时内更改。

我亲自编写了一个Python脚本来自动添加IPtables规则。

这是一个略微缩写的版本，没有日志记录和其他垃圾内容：

#!/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)

我认为mod_security对您不起作用的原因是Apache本身无法解析请求，因为它们不合规格。我不确定您是否在这里遇到问题-apache正在记录网络上正在发生的怪异狗屎，如果不记录，您甚至不会意识到它正在发生。记录请求所需的资源可能很小。我知道有人在填写您的日志令人沮丧，但是如果您禁用日志记录只是为了找到自己真正需要的日志，那将更加令人沮丧。就像有人闯入您的Web服务器一样，您需要日志来显示他们是如何闯入的。

一种解决方案是通过syslog设置ErrorLogging，然后使用rsyslog或syslog-ng专门过滤并丢弃与w00tw00t有关的RFC违规行为。或者，您也可以将它们过滤到单独的日志文件中，这样您的主要ErrorLog便易于阅读。Rsyslog在这方面非常强大和灵活。

因此，在httpd.conf中，您可以这样做：

ErrorLog syslog:user 

然后在rsyslog.conf中，您可能具有：

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

请注意，与直接登录到文件的原始日志记录方式相比，此方法实际上将使用许多资源。如果您的网络服务器很忙，这可能会成为问题。

最好的做法是将所有日志尽快发送到远程日志服务器，这将使您受益匪浅，因为这将使擦除审计记录的工作变得更加困难。

IPTables阻止是一个主意，但您最终可能会遇到非常大的iptables阻止列表，这些列表本身可能会对性能产生影响。IP地址中是否存在模式，还是来自大型分布式僵尸网络？您必须先获得X％的重复项，然后才能从iptables中受益。

您在更新2中说：

仍然存在的问题仍然存在的问题如下。这些攻击来自在您的服务器上搜索某些文件的机器人。此特定的扫描仪搜索文件/w00tw00t.at.ISC.SANS.DFind :)。

现在，您可以忽略它，这是最推荐的。问题仍然是，如果有一天您确实在服务器上拥有此文件，则会遇到麻烦。

从我之前的答复中，我们发现Apache由于格式不正确的HTML 1.1查询而返回了一条错误消息。所有支持HTTP / 1.1的Web服务器都可能在收到此消息时返回错误（我没有仔细检查RFC-也许RFC2616告诉了我们）。

在服务器上有w00tw00t.at.ISC.SANS.DFind：并不神秘地意味着“您遇到了麻烦” ...如果您在DocumentRoot中甚至在文件根目录中创建w00tw00t.at.ISC.SANS.DFind：文件DefaultDocumentRoot没关系...扫描程序正在发送中断的HTTP / 1.1请求，而apache则说“不，这是一个错误的请求……再见”。w00tw00t.at.ISC.SANS.DFind：文件中的数据将不提供。

在这种情况下，不需要使用mod_security，除非您确实想要（没有意义？）...在这种情况下，您可以查看手动对其进行修补（在其他答案中链接）。

您可能要看的另一件事是mod_security中的RBL功能。也许有一些在线RBL提供了IP（或其他已知的恶意IP）。但是，这意味着mod_security为每个请求执行DNS查找。

如何向modsecurity添加规则？像这样：

   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'"

我看到上面已经涵盖了大多数解决方案，但是我想指出的是，并非所有没有主机名攻击的客户端发送的HTTP / 1.1请求都直接针对您的服务器。有多种尝试对服务器之前的网络系统进行指纹识别和/或利用的尝试，即使用：

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

瞄准Linksys路由器等。因此有时它有助于扩大您的关注范围，并在所有系统之间以相等的份额分配防御工作，例如：实施路由器规则，实施防火墙规则（希望您的网络有一个），实施服务器防火墙/ IP表规则和相关服务，例如mod_security，fail2ban等。

这个怎么样 ？

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:

对我来说很好。

如果您将hiawathaWeb服务器用作网络reverse proxy扫描，这些扫描将自动作为垃圾和被client禁止的对象丢弃。它还可以过滤XSS和CSRF利用。