Adventures with ModSecurity

I saw a reference to ModSecurity while reading the following article on Slashdot: Writing Hardened Web Applications?. It is an Apache web server firewall module that is designed to look for and reject malicious access attempts. What follows are the trials and tribulations of installing it on debian.

Note: The web server is restarted after each configuration change below.

  1. Find the package and install it in debian: libapache-mod-security
  2. Have the web server not restart because of the following error: “(EAI 2)Name or service not known: mod_unique_id: unable to find IPv4 address”
  3. Figure out that an entry needed to be added to /etc/hosts for the servers IPv4 address and hostname.
  4. Configure ModSecurity using the example config files in /usr/share/doc/mod-security-common/examples/rules/.
  5. Get the following error: “Unable to retrieve collection (name “global”, key “global”). Use SecDataDir to define data directory first.”
  6. Set SecDataDir in modsecurity_crs_10_config.conf using the example from the reference manual. Repeat previous error do to directory permissions.
  7. Set SecDataDir to /tmp. Finally start up without complaining.
  8. While looking through one of the security rules, find a bug and retrieve the latest rule set from owasp.org.
  9. Configure the new rule set in modsecurity_crs_10_config.conf by following the instructions in INSTALL and setting SecRuleEngine DetectionOnly to prevent rejections during testing.
  10. Get the following error in modsecurity_crs_20_protocol_violations.conf: “Unknown variable REQBODY_ERROR”
  11. Comment out the 2 lines in modsecurity_crs_20_protocol_violations.conf that reference REQBODY_ERROR.
  12. Test using the following URL: “http://yourwebsite.com/test.vbs” and get a detection message in the web server error log.
  13. See the following error message from regular website traffic: “Rule execution error – PCRE limits exceeded (-8)”
  14. Determine that the following 2 lines needed to be added to modsecurity_crs_10_config.conf: “SecPcreMatchLimit 150000” “SecPcreMatchLimitRecursion 150000”
  15. See the following error message from regular website traffic: “SQL injection attempts …”
  16. Determine that it was rejecting legitimate requests that happened to have “div” in the URL or “2or” in the session cookie.
  17. Disable the SQL injection rule by removing the links in activated_rules/ with “rm *sql_injection*”

After running in test mode for a couple of days, set SecRuleEngine On

Test with the following url and make sure the request is rejected: “http://yourwebsite.com/?a=ftp://127.1.1.1”

References

Update: 8 Jan 2012

I wrote my own custom rule to catch hack attempts via certain php page names such as phpmyadmin.

Then I implemented log-guardian to monitor the web server error log files for hack attempts and write a message to authfail so that it will smoke the ip address (drop it in iptables) after 4 hack attempts.

One thought on “Adventures with ModSecurity”

  1. Just had my first round of setting up modsecurity on debian squeeze and it was quite different from what im used to (Arch and Gentoo).

    Had massive problems with false positives generated from the backend of WordPress Admin which kills some functionality. And discovered that creating a global exclude file and excluding /admin.php will resolve the issue. Excluding certain rules will not, since you will find yourself excluding the majority of the core rules :p. Not super happy about excluding /admin.php however it is non accessible if u are not logged in and authenticated.

Leave a Reply

Your email address will not be published. Required fields are marked *