ModSecurity 2 has been out for a while now, and although I have played with it some, I never found some time to upgrade my own servers. The upgrading generally went quite smooth, even though ModSecurity 2 changed quite a bit.
First of all there are now 5 phases where you can filter. Actually, one of them only applies to the logging, so you can filter in 4 phases. The phases are headers and body for both request and response traffic. Filtering on specific URIs can be done in phase 1 (request headers), while inspecting a POST payload requires phase 2 (request body).
Next, some shortcuts where removed. In 1.9.4 there was a variable called POST_PAYLOAD, that enabled the user to match against payloads from POST requests easily. Now there is REQUEST_BODY, but since that can be part of non-POST requests as well, you have to use:
SecRule REQUEST_METHOD “POST” chain
SecRule REQUEST_BODY “evil”
instead of:
SecFilterSelective POST_PAYLOAD “evil”
One other change is visible above already. The keyword to create a rule has been changed from SecFilterSelective to SecRule. Many rules can be converted by just replacing the keyword, but certainly not all. A simple find/replace should not be done without a manual review!
I use a number of custom rules to protect certain parts of my server, so I needed to convert my rules. For most of them it was simply enough to replace SecFilterSelective with SecRule. For a few I had to replace the OUTPUT_STATUS variable with the RESPONSE_STATUS variable, as it is called now.
For one rule however, I had quite some problems to get it running correctly. This was the rule in 1.9.4 syntax:
# block wp-login.php
SecFilterSelective REMOTE_ADDR “!10\.1\.1\.1″ chain
SecFilterSelective REQUEST_URI “/wp-login.php” \
log,deny,redirect:http://www.inliniac.net/nologin.html
This rule makes sure only 10.1.1.1 can open the login page, everyone else is redirected to a simple html page containing a ‘Access Denied - Logins disabled’ message. I converted it to the following:
SecRule REMOTE_ADDR “!10\.1\.1\.1″ chain
SecRule REQUEST_URI “/wp-login.php” \
log,deny,redirect:http://www.inliniac.net/nologin.html
Guess what? It didn’t work. I’ve spend quite some time trying all kinds of variations of the rule, and finally I found out what the issue is. In 1.9.4 the rule actions, like deny, redirect etc could be in the final rule of a series of chained rules. With 2.0.4 this doesn’t work correctly. So when I changed the rules to the following, it worked:
# block wp-login.php
SecRule REMOTE_ADDR “!10\.1\.1\.1″ \ “chain,phase:1,log,deny,redirect:http://www.inliniac.net/nologin.html”
SecRule REQUEST_URI “/wp-login\.php$”
I haven’t looked into this further to find out whether this is a bug or a feature.
The last thing that was interesting is the modsec2sguil script. There have been some changes to the alert files. So expect a new version of the script soon!
Update on using realtime blacklists with ModSecurity
Thursday, March 1st, 2007A few days ago I posted a blog article about stopping comment spam with ModSecurity using realtime blacklists (rbl). While the approach was working, I noted having problems with rules when I tried to match on POST methods in HTTP requests.
Luckily, ModSecurity creator Ivan Ristic was quick to point out where the problem is. I’m using the Core Ruleset for ModSecurity, and one thing that ruleset does is use the ‘lowercase’ transformation. This converts all text from arguments to lowercase, so my ^POST$ match would never be able to match. So like Ivan suggested, using ^post$ solved this part.
Next Ivan pointed out a weakness in the rules. My rules looked for /blog/wp-comment-post.php, and would be easily evaded by just using /blog//wp-comment-post.php. He suggested using the ‘normalisePath’ transformation. I did this, but I also slightly changed the rules to not look for the /blog/ part at all (maybe this makes normalisePath useless, but I decided to rather be safe than sorry).
The rules I’m using now look like this:
SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl list.dsbl.org’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl list.dsbl.org”
SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl bl.spamcop.net’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl bl.spamcop.net”
SecRule REQUEST_METHOD “^post$” “log,deny,chain,msg:’LOCAL comment spammer at rbl sbl-xbl.spamhaus.org’”
SecRule REQUEST_URI “wp-(comments-post|trackback)\.php$” “chain,t:normalisePath”
SecRule REMOTE_ADDR “@rbl sbl-xbl.spamhaus.org”
Thanks a lot Ivan Ristic for your comments!
Tags: comment spam, Ivan Ristic, ModSecurity, rbl
Posted in IPS, ModSecurity, Web | No Comments »