处理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 "-" "-" 

我尝试像这样configurationmod_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:\)" 

即使这不起作用。 我不知道该怎么办了。 任何人有任何build议?

更新1

我发现没有人可以使用mod_security解决这个问题。 到目前为止,使用ip-tables似乎是这样做的最佳select,但我认为该文件将变得非常大,因为ip每天更改一次。

我想出了2个其他的解决scheme,有人可以评论他们的好或不好。

  1. 我想到的第一个解决scheme是从我的apache错误日志中排除这些攻击。 这将使我更容易发现其他紧急错误,因为它们发生,并不需要吐槽长logging。

  2. 第二个选项是我认为更好,这是阻止未正确发送的主机。 在这个例子中,w00tw00t攻击没有主机名发送,所以我想我可以阻止不正确forms的主机。

更新2

通过回答后,我得出以下结论。

  1. 为apache定制日志将消耗一些不必要的资源,如果真的有问题,你可能会想看看完整的日志没有任何缺失。

  2. 最好忽略命中,专注于分析错误日志的更好方法。 为你的日志使用filter是一个很好的方法。

关于这个问题的最终想法

如果你至less有一个最新的系统,上面提到的攻击不会到达你的机器,所以基本上没有问题。

过了一段时间才能真正过滤掉所有的虚假攻击,因为错误日志和访问日志都非常大。

以任何方式防止这种情况的发生都会花费你的资源,不要浪费你的资源在不重要的东西上。

我现在使用的解决scheme是Linux logwatch 。 它向我发送日志摘要,并对它们进行过滤和分组。 这样你就可以轻松地把重要的和不重要的分开。

谢谢大家的帮助,我希望这篇文章对别人也有帮助。

    从错误日志中,他们发送的请求中没有Host:部分的HTTP / 1.1请求。 从我读的内容来看,Apache向这个请求回复了一个400(错误的请求)错误,然后交给mod_security。 所以,看起来你的规则不会被处理。 (Apache在处理它之前需要交给mod_security)

    试试自己:

     telnet主机名80
     GET /blahblahblah.html HTTP / 1.1(input)
     (input)
    

    您应该得到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

    无法find任何其他解决scheme,并想知道是否真的需要一个解决scheme。

    过滤IP不是一个好主意,恕我直言。 为什么不尝试过滤你知道的string?

    我的意思是:

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

    Iv也开始在我的日志文件中看到这些types的消息。 防止这类攻击的一种方法是设置fail2ban( http://www.fail2ban.org/ ),并设置特定的filter黑名单,在iptables规则中列出这些ip地址。

    下面是一个filter的例子,它将阻止与这些消息相关的IP地址

    [星期二8月16 02:35:23 2011] [错误] [客户端]文件不存在:/var/www/skraps/w00tw00t.at.blackhats.romanian.anti -sec 🙂 === apache w00t w00t消息监狱 – 正则expression式和filter===监狱

      [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或可parsing主机名几乎是不可能的,因为它会在一个小时内改变。

    我亲自编写了一个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不能parsing请求本身,他们是不合规格的。 我不确定你在这里有什么问题–apachelogging了网上发生的奇怪事情,如果它没有logging,你甚至不会意识到它发生了。 logging请求所需的资源可能很less。 我知道有人填写你的日志令人沮丧,但是如果你禁用日志logging只是为了find你真正需要的日志,那将会更令人沮丧。 就像有人闯入你的networking服务器,你需要日志,以显示他们如何打破。

    一种解决scheme是通过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 

    请注意,这种方法实际上使用的资源比原来直接logging到文件的资源要多很多倍。 如果您的networking服务器非常繁忙,这可能会成为一个问题。

    尽可能快地将所有日志发送到远程日志logging服务器的最佳做法是,如果您有任何疑问,将会使您受益匪浅,因为要清除已完成的审计跟踪要困难得多。

    IPTables阻塞是一个想法,但你可能会得到一个非常大的iptables阻止列表,本身可能会有性能影响。 IP地址中是否有模式,还是来自大型分布式僵尸networking? 在你从iptables中获得好处之前,需要有X%的重复数据。

    你在更新2中说:

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

    现在,你可以忽略这是最推荐的。 问题仍然是,如果有一天你在服务器上有这个文件,那么你遇到了一些麻烦。

    从我之前的回复中,我们收集到了Apache由于形成的HTML 1.1查询不完整而返回错误消息。 所有支持HTTP / 1.1的web服务器在收到这个消息时都应该返回一个错误信息(我没有仔细检查RFC – 也许RFC2616告诉我们)。

    有w00tw00t.at.ISC.SANS.DFind:在你的服务器上有些地方并不神秘地表示“你遇到了麻烦”…如果你在你的DocumentRoot中创build了w00tw00t.at.ISC.SANS.DFind:文件,或者甚至DefaultDocumentRoot没关系…扫描器发送了一个错误的HTTP / 1.1请求,并且apache说“不,这是一个不好的请求…再见”。 w00tw00t.at.ISC.SANS.DFind:文件中的数据将不会被提供。

    在这种情况下使用mod_security并不是必需的,除非你真的想(没有意思?)…在这种情况下,你可以手动修补它(在其他答案中链接)。

    另一件你可能会用到的是mod_security中的RBL特性。 也许有一个在线RBL提供wwtw00t 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'" 

    我发现上面已经介绍了大部分的解决scheme,但是我想指出的是,并非所有的客户端发送的HTTP / 1.1请求没有主机名攻击都直接针对你的服务器。 指纹和/或利用您的服务器之前的networking系统有很多不同的尝试,即使用:

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

    以Linksys路由器为目标等。所以有时它有助于扩大你的注意力,并在所有系统之间划分你的防御工作,即实现路由器规则,实现防火墙规则(希望你的networking有一个),实现服务器防火墙/ 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: 

    对我来说工作得很好。

    如果您使用hiawatha web服务器作为reverse proxy这些扫描会自动丢弃,因为垃圾和client被禁止。 它也过滤XSSCSRF漏洞。