Comments on: Blocking comment spam using ModSecurity and realtime blacklists http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html Everything inline. Mon, 30 Jan 2012 16:49:09 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Victor Julien http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-28662 Victor Julien Mon, 16 May 2011 13:11:01 +0000 http://www.inliniac.net/blog/?p=64#comment-28662 @PPkiula did you check this link? http://blog.spiderlabs.com/2011/03/modsecurity-advanced-topic-of-the-week-malware-link-detection.html It shows how to capture an url and check it against the google safe browsing database. @PPkiula did you check this link? http://blog.spiderlabs.com/2011/03/modsecurity-advanced-topic-of-the-week-malware-link-detection.html

It shows how to capture an url and check it against the google safe browsing database.

]]> By: PPkiula http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-28658 PPkiula Sun, 15 May 2011 08:02:40 +0000 http://www.inliniac.net/blog/?p=64#comment-28658 Hi, First, thanks for sharing this. You don't have the "Notify me when someone responds to my comment" feature on this blog, so could you pls write to my email if you reply. I am looking for a rule set that works on not just REMOTE_ADDR, but looks at the *content* of form submissions. Will the rule above by "Jens" cover the posted content too? Thanks! Hi,

First, thanks for sharing this. You don’t have the “Notify me when someone responds to my comment” feature on this blog, so could you pls write to my email if you reply.

I am looking for a rule set that works on not just REMOTE_ADDR, but looks at the *content* of form submissions. Will the rule above by “Jens” cover the posted content too?

Thanks!

]]> By: Mod Security for Apache – Web Server Smart Firewall http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-18934 Mod Security for Apache – Web Server Smart Firewall Mon, 22 Feb 2010 14:26:44 +0000 http://www.inliniac.net/blog/?p=64#comment-18934 [...] http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blackli... [...] [...] http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blackli... [...]

]]> By: Marc Perkel http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-12315 Marc Perkel Tue, 23 Dec 2008 08:16:57 +0000 http://www.inliniac.net/blog/?p=64#comment-12315 Thanks for the rules. Feel free to use my blacklist at blacklist.junkemailfilter.com. It seems to work rather well. It's my email blacklist but it's mostly spambots. Thanks for the rules. Feel free to use my blacklist at blacklist.junkemailfilter.com. It seems to work rather well. It’s my email blacklist but it’s mostly spambots.

]]> By: Victor Julien http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-11176 Victor Julien Fri, 04 Apr 2008 08:28:38 +0000 http://www.inliniac.net/blog/?p=64#comment-11176 The idea was to exactly match on the filenames, and not on anything else. I think if you replace REQUEST_URI by REQUEST_FILENAME it should still work. REQUEST_URI also includes the QUERY_STRING and thats probably why it didn't work for you... The idea was to exactly match on the filenames, and not on anything else. I think if you replace REQUEST_URI by REQUEST_FILENAME it should still work. REQUEST_URI also includes the QUERY_STRING and thats probably why it didn’t work for you…

]]> By: Samuel http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-11174 Samuel Thu, 03 Apr 2008 23:54:16 +0000 http://www.inliniac.net/blog/?p=64#comment-11174 When you write "^/blog/wp-(comments-post|trackback)\.php$", what is rationale for the final "$"? My rules doesn't match with my URIs if I write this final $. Without it, they work perfectly. Perhaps am I misunderstanding something? When you write “^/blog/wp-(comments-post|trackback)\.php$”, what is rationale for the final “$”? My rules doesn’t match with my URIs if I write this final $. Without it, they work perfectly. Perhaps am I misunderstanding something?

]]> By: Samuel http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-11172 Samuel Wed, 02 Apr 2008 23:19:56 +0000 http://www.inliniac.net/blog/?p=64#comment-11172 Thank you !!!!!! Thank you indeed. The latest updated information about mod_security and blacklists I was finding on other websites dated from 2006 and was completely useless (links to lists that not exist, rules for mod_security 1, etc.). Thank you !!!!!!

Thank you indeed. The latest updated information about mod_security and blacklists I was finding on other websites dated from 2006 and was completely useless (links to lists that not exist, rules for mod_security 1, etc.).

]]> By: Jens http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-11152 Jens Wed, 26 Mar 2008 03:11:57 +0000 http://www.inliniac.net/blog/?p=64#comment-11152 This works for me: SecRule REQUEST_METHOD "^((?:post|head))$" "t:none,t:lowercase,log,chain,deny,msg:'IP address that has abusable vulnerabilities: web.dnsbl.sorbs.net'" SecRule REMOTE_ADDR "@rbl web.dnsbl.sorbs.net" This works for me:

SecRule REQUEST_METHOD “^((?:post|head))$” “t:none,t:lowercase,log,chain,deny,msg:’IP address that has abusable vulnerabilities: web.dnsbl.sorbs.net’”
SecRule REMOTE_ADDR “@rbl web.dnsbl.sorbs.net”

]]> By: VictorJ http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-1695 VictorJ Fri, 23 Feb 2007 12:50:53 +0000 http://www.inliniac.net/blog/?p=64#comment-1695 Thank you for this explanation Ivan. I have changed the rules according to your suggestions and am now waiting for new commentspam attempts to occur. I will update the blog when I know more! Thank you for this explanation Ivan. I have changed the rules according to your suggestions and am now waiting for new commentspam attempts to occur. I will update the blog when I know more!

]]> By: Ivan Ristic http://www.inliniac.net/blog/2007/02/23/blocking-comment-spam-using-modsecurity-and-realtime-blacklists.html/comment-page-1#comment-1694 Ivan Ristic Fri, 23 Feb 2007 09:39:22 +0000 http://www.inliniac.net/blog/?p=64#comment-1694 About your attempt to only lookup IP addresses doing POST requests. The rules are correct. I am guessing you are having trouble because, unless rules are explicitly configured differently, default transformation functions from the context are applied to arguments (REQUEST_METHOD in this case) before the operator is run. By default ModSecurity will perform the following transformations: lowercase, replaceNulls, and compressWhitespace. So it's either those or the ones specified with SecDefaultAction. If my hunch is correct than the first rule is not matching because a lowercase version of REQUEST_METHOD ("post") is being compared to "^POST$". The solution is to add "t:none" to the list of actions of the first rule. This will cancel any transformation functions specified in the context. On a similar note, your rules using REQUEST_URI are easy to evade if spammers send their requests to "/blog//wp-comments-post.php" (notice the two forward slashes). Again, this is because you are using the default transformations and they are not adequate for the job. Adding "t:normalisePath" to the list of actions fixes this problem. I always recommend enabling the debug log at level 9, especially if you are just starting with ModSecurity. For example, this is how you would find out exactly how input data is transformed before the operators are applied. ModSecurity will log variable values after each transformation takes place. About your attempt to only lookup IP addresses doing POST requests. The rules are correct. I am guessing you are having trouble because, unless rules are explicitly configured differently, default transformation functions from the context are applied to arguments (REQUEST_METHOD in this case) before the operator is run. By default ModSecurity will perform the following transformations: lowercase, replaceNulls, and compressWhitespace. So it’s either those or the ones specified with SecDefaultAction. If my hunch is correct than the first rule is not matching because a lowercase version of REQUEST_METHOD (“post”) is being compared to “^POST$”. The solution is to add “t:none” to the list of actions of the first rule. This will cancel any transformation functions specified in the context.

On a similar note, your rules using REQUEST_URI are easy to evade if spammers send their requests to “/blog//wp-comments-post.php” (notice the two forward slashes). Again, this is because you are using the default transformations and they are not adequate for the job. Adding “t:normalisePath” to the list of actions fixes this problem.

I always recommend enabling the debug log at level 9, especially if you are just starting with ModSecurity. For example, this is how you would find out exactly how input data is transformed before the operators are applied. ModSecurity will log variable values after each transformation takes place.

]]>