OWASP mod_security rules not triggering CSF IP block anymore...
CSF has the option to ban an IP address after multiple mod_security triggers:
Enable failure detection of repeated Apache mod_security rule triggers
LF_MODSEC = Default: 5 [0-100]
LF_MODSEC_PERM = Default: 1 [0-604800]
This was working fine across all of our servers when we were using a custom version of the AtomiCorp delayed rules, but we've recently switched to the new OWASP rules provided by cPanel and the CSF detection seems to no longer be working - multiple triggers no longer result in an IP ban.
Anyone else encountered this?
-
We were suffering from the upcp bug but I've since re-enabled the rules. I'm seeing hits in the ModSecurity Tools page, and they are indeed showing up in the error_log Is anyone else successfully using the csf modsecurity trigger with the new owasp rules? 0 -
If the hits are showing in error_log, check your CSF config. LFD actively parses the error_log. It's unlikely this is wrong, but ensure this setting is correct in /etc/csf/csf.conf: MODSEC_LOG = "/usr/local/apache/logs/error_log" Also ensure that LFD is running; for some reason csf -r doesn't restart lfd. If you're in doubt just run "csf -x ; csf -e" to quickly disable and re-enable CSF/LFD. I'm taking a look to see if maybe CSF isn't parsing the apache logs correctly for the OWASP rules... I'll edit this in a minute with what I figure out. EDIT: Ok, so, if I trip rules in my custom rule set (which is also still included) then CSF blocks the IP. But, if I trip rules in the OWASP rule set, it doesn't block the ip in CSF. So, it seems this has to do with CSF's processing of the error log itself. The logs do look a bit different between the two types of hits (custom basic deny rule, and the OWASP XSS rule): (note to mods, I used quote instead of "code" on purpose so that lines wrap) # BASIC DENY RULE: [Mon Feb 09 15:17:46.512448 2015] [:error] [pid 18584] [client $MY.IP.ADD.RESS] ModSecurity: Access denied with code 500 (phase 2). Pattern match "/\\\\.\\\\./" at REQUEST_URI. [file "/usr/local/apache/conf/modsec2.user.conf"> [line "301"> [id "300004"> [rev "2"> [msg "Generic Path Recursion denied"> [severity "CRITICAL"> [hostname "$MYSITE.com"> [uri "/"> [unique_id "VNkV6kMrAkQAAEiYWvkAAAAB"> #OWASP RULE: [Mon Feb 09 15:20:35.891669 2015] [:error] [pid 20940] [client $MY.IP.ADD.RESS] ModSecurity: Access denied with redirection to http://www.$MYSITE.com/ using status 302 (phase 2). detected XSS using libinjection. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-41-APPLICATION-ATTACK-XSS.conf"> [line "23"> [id "973343"> [rev "2"> [msg "XSS Attack Detected via Libinjection"> [data "Matched Data: http://www.$MYSITE.com/blog/wp-admin/ found within ARGS:log: 0 -
LFD is definitely running. We are actually having this same issue on all our servers using the cPanel/OWASP rules. MODSEC_LOG is also set correctly... 0 -
I just edited my above post with an explanation for you. 0 -
Ah great - thanks for investigating. I'll go ahead and make that change and open a ticket with the csf guys... I imagine a lot of people will be having this issue. 0 -
Hi, New CSF 7.62 [url=http://blog.configserver.com/?p=2418]New csf v7.62 | ConfigServer Services Blog 0 -
Looks like they fixed it as soon as you reported it on the forum :) A new version of csf (v7.62) has been released to more generically support ModSecurity "Access denied" triggers: [url=http://blog.configserver.com/]ConfigServer Services Blog | Product releases, updates and general commentary 0 -
The Latest version of CSF 7.62 seems to have fixed the problem. 7.62 - Modified ModSecurity regexes to be more generic 0 -
Geez that was fast. Thanks for all the help guys! 0 -
Thanks, ConfigServer! 0 -
Did this break again? I'm noticing that on my server, LF_MODSEC is set to 8, and particular IPs are having a field day - breaking OWASP rules left and right .. for a few hours at a time. My 'managed support' was only able to suggest that I add LF_APACHE_404 ... to block IPs when they trigger too many 404s. 0
Please sign in to leave a comment.
Comments
12 comments