Individual Entry Archive

Navigation

• Previous Post: AT LAST!
• Next Post: Consolidation for Compact Craftiness and Computeryness

blacklist_to_modsec: Tips, caveats, notes

In the last month and a half since releasing blacklist_to_modsec, I’ve collected a number of tips, caveats, and notes that will be valuable to anyone who uses blacklist_to_modsec, and in general anyone who wants to use mod_security to prevent website spam.

1. Read the mod_security documentation. I would highly recommend reading the full reference manual from start to finish. It will help you get the most out of mod_security, and tell you a lot of things you might not otherwise find out.
2. It pays to be familiar with the Apache documentation - mod_security is an Apache module, and is configured through Apache config files. So if you know how Apache works, you can be more effective at configuring mod_security. Documentation can be found here for Apache 1.x and here for Apache 2.x.
3. Consider blocking ‘pinappleproxy’. This is a proxy that many spammers go through. You can do this with the following mod_security rule: SecFilterSelective “HTTP_Via” “pinappleproxy”. Eventually, spammers will stop using this proxy or figure out how to disguise it, but for now this could be helpful.
4. Use ‘500′ as your response error code when blocking requests with mod_security: SecFilterDefaultAction “deny,log,status:500″. This makes it look like your script is broken, rather than saying that the spammer was denied or blocked. This may not fool everyone, but it might fool some.
5. mod_security will intercept requests even for files that don’t exist. For example, if you have moved or renamed a blog comment script, many spammers will continue trying to attack it. mod_security will parse and intercept all of theese requests, which is totally pointless. Instead, use Apache directives such as to tell mod_security to ignore such scripts:
   <Location /mt/mt-comments.cgi>SecFilterEngine Off</Location>
6. The mod_security location ‘ARGS’ is a synonym for ‘POST_PAYLOAD|QUERY_STRING’ - so using it as part of your blacklist rule format will ensure that both POST and GET forms are checked.
7. Consider upgrading to Apache 2.x if possible. It is far more robust and efficient than Apache 1.x, has a better regex engine and better module support, and tends to work much better with mod_security.
8. Make sure that when you upgrade blacklist_to_modsec, you run it with the ‘-i’ switch to reinitialize your data files. Also make sure that you double check the user-configurable settings in the script, as they may change after an upgrade.

Let me know if you have any other suggestions, tips, or questions.