I just uploaded a new version of Modsec2sguil. I’ve been working on it the last weeks to get it updated to Sguil 0.7. The scripts are changed all over the place. This is because in the 0.7 framework, my scripts would no longer be a replacement for Barnyard only talking to the sensor_agent on the localhost, instead now it would become a full agent talking to the Sguil server directly.
This brings some challenges. First the connection can be going over the internet, or another untrusted network, so the agent needs ssl support. Second, since the connection may be unreliable we need to be able to detect and deal with lost connections. Next to this I wanted to be able to run without superuser privileges.
The new version of modsec2sguil supports it all, and more:
- Converted into a real agent for Sguil 0.7 (no more barnyard replacement)
- Agent can drop privileges
- Agent can daemonize
- Pinging the server is supported
- The agent reconnects to the server if the connection is lost
- Agent supports SSL for the connection to the server
- A sguil-compatible configuration file is now used
- A debug mode was added
So if you run Sguil 0.7-CVS and ModSecurity, go check it out at http://www.inliniac.net/modsec2sguil/
Last but not least, the agent contains a SguilAgent.pm Perl library. I hope it enables developers to easily create Perl agents for Sguil. If you need help with that, please let me know!
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 »