在阅读本文前，先简单了解下什么是ModSecurity，ModSecurity是一个入侵探测与阻止的引擎.它主要是用于Web应用程序所以也可以叫做Web应用程序防火墙，相信不少商业WAF的签名开发同学也参考了ModSecurity的规则吧。

背景：

上周Wordpress网站遭受了大规模的暴力破解攻击，攻击者首先扫描互联网上的Wordpress网站，然后利用Web服务器组建的僵尸网络不断尝试用户名和密码试图登录管理界面。攻击者使用了超过9万台Web服务器来进行暴力破解。本文借用此例，来介绍下如何利用ModSecurity防御Wordpress的暴力破解。

常规的缓解暴力破解方法如下：

1：更改admin默认账户名称，或直接删除admin，添加一个新的管理员帐户。

2：使用 3：使用限制登录 4：使用.htpasswd对访问特定页面实现用户名和密码验证。

这些都有现成的方法去实现了，这里就介绍一下用 V2.7.3来保护Wordpress，防止暴力破解。

1：Wordpress的登录过程分析

下图为Wordpress的登录页面：

用户登录之后，发送请求到WP-loing.php页面，HTTP请求包内容如下：

POST /wordpress/wp-login.php HTTP/1.1 Host: mywordpress.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8 Accept-Language: en-us,en;q=0.5 DNT: 1 Referer: http://mywordpress.com/wordpress/wp-login.php Content-Type: application/x-www-form-urlencodedVia: 1.1 owaspbwa.localdomain Connection: Keep-Alive Content-Length: 73log=administrator&pwd=pass123&submit=Login+%C2%BB&redirect_to=wp-admin%2F

payload部分包含了用户名和密码，以及登录成功后转向的页面。OK，了解数据包结构之后，我们可以创建规则，防止未经授权的访问。

2：检查Rerfer

正常的用户登录Wordpress，在数据包头部会包含一个Referer字段，但是通过人工编写的程序，很多不会包含Referer字段，直接发送登录请求到wp-login.php页面，所以，我们可以根据此创建一个ModSecurity规则来检查Rerfer字段信息：

SecRule REQUEST_METHOD "@streq POST" "chain,id:'1',phase:2,t:none,block,log,msg:'Warning: Direct Login Missing Referer.'"  SecRule REQUEST_FILENAME "@pm /wp-login.php /wp-admin/" "chain"    SecRule &REQUEST_HEADERS:Referer "@eq 0"

当然通过脚本，很容易实现Rerfer伪造，所以还需要接下来的规则一起配合。

3：限制访问的IP

如果你不想修改默认管理员帐号，可以添加一个规则只允许特定的IP访问管理页面，如下：

SecRule REQUEST_METHOD "@streq POST" "chain,id:'1',phase:2,t:none,block,log,msg:'Warning: Direct Login Missing Referer.'"  SecRule REQUEST_FILENAME "@pm /wp-login.php /wp-admin/" "chain"    SecRule ARGS:log "@streq admin" "chain"      SecRule REMOTE_ADDR "!@ipMatch 72.192.214.223"

在这个例子里，只允许名称为freebuf的管理员帐户通过72.192.214.223的IP地址来访问。

4：跟踪管理员帐户的登录尝试

我们可以通过ModSecurity的规则来block掉恶意IP，以下为登录失败的返回包：

HTTP/1.1 200 OK Date: Fri, 11 May 2012 03:24:53 GMT Server: Apache Expires: Wed, 11 Jan 1984 05:00:00 GMT Last-Modified: Fri, 11 May 2012 03:24:54 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Length: 1697 Connection: close Content-Type: text/html; charset=UTF-8WordPress › Login

可以看到状态码为200，而且返回的数据包中包含了Incorrect password，据此可以创建以下规则：

SecRule REQUEST_FILENAME "@streq /wordpress/wp-login.php" "chain, phase:4,id:999323,t:none,block,msg:'Authentication Failure Violation .',logdata:'Number of Authentication Failures: %{ip.failed_auth_ attempt}'"  SecRule REQUEST_METHOD "@streq POST" "chain"     SecRule ARGS:log "@streq admin" "chain"      SecRule RESPONSE_STATUS "200" "chain"         SecRule RESPONSE_BODY "@contains Error:Incorrect password." "chain,setvar:ip.failed_auth_attempt=+1,expirevar:ip.failed_auth_attempt=60"          SecRule IP:FAILED_AUTH_ATTEMPT "@gt 5"

5：设置验证请求的次数

ModSecurity可以在指定的时间内跟踪请求的数量，设置阀值来进行阻断攻击，在它的规则集里已经个包含了该规则，

如下：

## -- [[ Brute Force Protection ]] ---------------------------------------------------------## If you are using the Brute Force Protection rule set, then uncomment the following# lines and set the following variables:# - Protected URLs: resources to protect (e.g. login pages) - set to your login page# - Burst Time Slice Interval: time interval window to monitor for bursts# - Request Threshold: request # threshold to trigger a burst# - Block Period: temporary block timeout#SecAction \  "id:'900014', \  phase:1, \  t:none, \  setvar:'tx.brute_force_protected_urls=/wp-login.php', \  setvar:'tx.brute_force_burst_time_slice=60', \  setvar:'tx.brute_force_counter_threshold=10', \  setvar:'tx.brute_force_block_timeout=300', \  nolog, \  pass"

注意修改 setvar:’tx.brute_force_protected_urls=/wp-login.php‘,

设置完毕后，激活

 

## Anti-Automation Rule for specific Pages (Brute Force Protection)# This is a rate-limiting rule set and does not directly correlate whether the# authentication attempt was successful or not.### Enforce an existing IP address block and log only 1-time/minute# We don't want to get flooded by alerts during an attack or scan so# we are only triggering an alert once/minute.  You can adjust how often# you want to receive status alerts by changing the expirevar setting below.#SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "chain,phase:1,id:'981036',block,msg:'Brute Force Attack Identified from %{tx.real_ip} (%{tx.brute_force_block_counter} hits since last alert)',setvar:ip.brute_force_block_counter=+1"	SecRule &IP:BRUTE_FORCE_BLOCK_FLAG "@eq 0" "setvar:ip.brute_force_block_flag=1,expirevar:ip.brute_force_block_flag=60,setvar:tx.brute_force_block_counter=%{ip.brute_force_block_counter},setvar:ip.brute_force_block_counter=0"## Block and track # of requests but don't logSecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:1,id:'981037',block,nolog,setvar:ip.brute_force_block_counter=+1"## skipAfter Checks# There are different scenarios where we don't want to do checks -# 1. If the user has not defined any URLs for Brute Force Protection in the 10 config file# 2. If the current URL is not listed as a protected URL# 3. If the current IP address has already been blocked due to high requests# In these cases, we skip doing the request counts.#SecRule &TX:BRUTE_FORCE_PROTECTED_URLS "@eq 0" "phase:5,id:'981038',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"SecRule REQUEST_FILENAME "!@within %{tx.brute_force_protected_urls}" "phase:5,id:'981039',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:5,id:'981040',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"## Brute Force Counter# Count the number of requests to these resoures# SecAction "phase:5,id:'981041',t:none,nolog,pass,setvar:ip.brute_force_counter=+1"## Check Brute Force Counter# If the request count is greater than or equal to 50 within 5 mins,# we then set the burst counter# SecRule IP:BRUTE_FORCE_COUNTER "@gt %{tx.brute_force_counter_threshold}" "phase:5,id:'981042',t:none,nolog,pass,t:none,setvar:ip.brute_force_burst_counter=+1,expirevar:ip.brute_force_burst_counter=%{tx.brute_force_burst_time_slice},setvar:!ip.brute_force_counter"## Check Brute Force Burst Counter and set Block# Check the burst counter - if greater than or equal to 2, then we set the IP# block variable for 5 mins and issue an alert.#SecRule IP:BRUTE_FORCE_BURST_COUNTER "@ge 2" "phase:5,id:'981043',t:none,log,pass,msg:'Potential Brute Force Attack from %{tx.real_ip} - # of Request Bursts: %{ip.brute_force_burst_counter}',setvar:ip.brute_force_block=1,expirevar:ip.brute_force_block=%{tx.brute_force_block_timeout}"SecMarker END_BRUTE_FORCE_PROTECTION_CHECKS

6：使用SecGuardianLog

从 1.9版本后，ModSecurity 支持一个新的指令，SecGuardianLog，设计此指令用于把所有允许数据通过管理日志功能发送到另一个程序。自从 apache部署成典型的多进程方式，信息共享变得困难了，这一想法就是部署一个独立的外部进程使用状态机的方式去观察所有的请求，提供额外的保护。使用方法如下：

语法: SecGuardianLog |/path/to/httpd-guardian示例: SecGuardianLog |/usr/local/apache/bin/httpd-guardian范围: Main版本: 2.0.0

而且SecGuardianLog也可以和 SnortSam协同工作（http://www.snortsam.net）。如果已经配置过 httpd-guardian(具体介绍请查看源代码)你只需要在 apache配置中添加一行就可以部署它：

SecGuardianLog |/path/to/httpd-guardian

规则如下：

# If defined, execute this command when a threshold is reached# block the IP address for one hour.# $PROTECT_EXEC = "/sbin/blacklist block %s 3600";# $PROTECT_EXEC = "/sbin/samtool -block -ip %s -dur 3600 snortsam.example.com";my $PROTECT_EXEC;# For testing only:# $PROTECT_EXEC = "/sbin/blacklist-webclient %s 3600";# Max. speed allowed, in requests per# second, measured over an 1-minute periodmy $THRESHOLD_1MIN = 2; # 120 requests in a minute

跟踪httpd守护进程数量，如果超过了限制，可以执行一些操作，如封锁IP一小时。

了解了一些ModSecurity的防止暴力破解规则之后，同志们可不要对freebuf进行破解，freebuf服务器小心脏经不起折腾，而且到时候IP被封可别找小编解封哦！：）

原文发布时间为：2013-04-18

本文来自云栖社区合作伙伴“Linux中国”