Has anyone been using the latest OWASP ModSecurity Core Rule Set via WHM? Version 3 was released recently (November 10, 2016) - OWASP ModSecurity Core Rule Set (CRS)
After spending hours tweaking these rulesets, we've found the best ones that cause least false positives are:
modsecurity_crs_10_setup.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-01-COMMON-EXCEPTIONS.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-10-IP-REPUTATION.conf
Enable - Doesn't seem to cause issues
^ Enabling this rule by default seems to block all traffic from Ukraine, Indonesia, Yugoslavia, Lithuania, Egypt, Romania, Bulgaria, Turkey, Russia, Pakistan, Malaysia and China. You need to remove these from /etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_10_setup.conf if you want to modify the countries being blocked! Rule only seems to work if Geolocation Database is defined in ModSecurity™ Configuration, otherwise it is ignored.
Seems like one needs to also register and get an API key for it to scan bad ips - Reference Manual · SpiderLabs/ModSecurity Wiki · GitHub
rules/REQUEST-12-DOS-PROTECTION.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-13-SCANNER-DETECTION.conf
Enable - Doesn't seem to cause issues. Seems to block sites like SEMRush Bot, Seomoz, etc. Might be good to prevent competitor spying, but if your customers use SEO services from those sites, it would be problematic.
rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf
Disable
rules/REQUEST-21-PROTOCOL-ATTACK.conf
Disable
rules/REQUEST-30-APPLICATION-ATTACK-LFI.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-31-APPLICATION-ATTACK-RFI.conf
Disable - Seems to cause issues when a site is calling scripts from another site. For example, if you have websiteA.com calling a PHP script from websiteB and incorporating the results in websiteA.
rules/REQUEST-33-APPLICATION-ATTACK-PHP.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-41-APPLICATION-ATTACK-XSS.conf
Disable - Seems to cause issue with some site builders (KoPage, etc)
rules/REQUEST-42-APPLICATION-ATTACK-SQLI.conf
Disable - Seems to cause a lot of false positive/issues with PHP scripts (SupportPal, etc)
rules/REQUEST-43-APPLICATION-ATTACK-SESSION-FIXATION.conf
Disable
rules/REQUEST-49-BLOCKING-EVALUATION.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-50-DATA-LEAKAGES-IIS.conf
Disable - unless using Microsoft IIS
rules/RESPONSE-50-DATA-LEAKAGES-JAVA.conf
Disable
rules/RESPONSE-50-DATA-LEAKAGES-PHP.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-50-DATA-LEAKAGES.conf
Disable
rules/RESPONSE-51-DATA-LEAKAGES-SQL.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-59-BLOCKING-EVALUATION.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-80-CORRELATION.conf
Enable - Doesn't seem to cause issues
Would really appreciate if others could contribute so we can find the best way to eliminate malware, attacks, etc.
After spending hours tweaking these rulesets, we've found the best ones that cause least false positives are:
modsecurity_crs_10_setup.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-01-COMMON-EXCEPTIONS.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-10-IP-REPUTATION.conf
Enable - Doesn't seem to cause issues
^ Enabling this rule by default seems to block all traffic from Ukraine, Indonesia, Yugoslavia, Lithuania, Egypt, Romania, Bulgaria, Turkey, Russia, Pakistan, Malaysia and China. You need to remove these from /etc/apache2/conf.d/modsec_vendor_configs/OWASP/modsecurity_crs_10_setup.conf if you want to modify the countries being blocked! Rule only seems to work if Geolocation Database is defined in ModSecurity™ Configuration, otherwise it is ignored.
Seems like one needs to also register and get an API key for it to scan bad ips - Reference Manual · SpiderLabs/ModSecurity Wiki · GitHub
rules/REQUEST-12-DOS-PROTECTION.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-13-SCANNER-DETECTION.conf
Enable - Doesn't seem to cause issues. Seems to block sites like SEMRush Bot, Seomoz, etc. Might be good to prevent competitor spying, but if your customers use SEO services from those sites, it would be problematic.
rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf
Disable
rules/REQUEST-21-PROTOCOL-ATTACK.conf
Disable
rules/REQUEST-30-APPLICATION-ATTACK-LFI.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-31-APPLICATION-ATTACK-RFI.conf
Disable - Seems to cause issues when a site is calling scripts from another site. For example, if you have websiteA.com calling a PHP script from websiteB and incorporating the results in websiteA.
rules/REQUEST-33-APPLICATION-ATTACK-PHP.conf
Enable - Doesn't seem to cause issues
rules/REQUEST-41-APPLICATION-ATTACK-XSS.conf
Disable - Seems to cause issue with some site builders (KoPage, etc)
rules/REQUEST-42-APPLICATION-ATTACK-SQLI.conf
Disable - Seems to cause a lot of false positive/issues with PHP scripts (SupportPal, etc)
rules/REQUEST-43-APPLICATION-ATTACK-SESSION-FIXATION.conf
Disable
rules/REQUEST-49-BLOCKING-EVALUATION.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-50-DATA-LEAKAGES-IIS.conf
Disable - unless using Microsoft IIS
rules/RESPONSE-50-DATA-LEAKAGES-JAVA.conf
Disable
rules/RESPONSE-50-DATA-LEAKAGES-PHP.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-50-DATA-LEAKAGES.conf
Disable
rules/RESPONSE-51-DATA-LEAKAGES-SQL.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-59-BLOCKING-EVALUATION.conf
Enable - Doesn't seem to cause issues
rules/RESPONSE-80-CORRELATION.conf
Enable - Doesn't seem to cause issues
Would really appreciate if others could contribute so we can find the best way to eliminate malware, attacks, etc.
Last edited by a moderator:
