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: <script"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "9"] [tag "Host: www.$MYSITE.com"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] [tag "https://libinjection.client9.com/"] [hostname "$MYSITE.com"] [uri "/blog/wp-login.php"] [unique_id "VNkWk0MrAkQAAFHMaMAAAAAH"]
It appears to be CSF mishandling it. Let's look at their regex.pm for ModSecurity:
Code:
#mod_security v2 (apache)
if (($config{LF_MODSEC}) and ($globlogs{MODSEC_LOG}{$lgfile}) and ($line =~ /^\[\S+\s+\S+\s+\S+\s+\S+\s+\S+\] \[(\w*:)?error\] (\[pid \d+(:tid \d+)?\] )?\[client (\S+)\] (\w+: )?ModSecurity:(( \[[^]]+\])*)? Access denied with (code|connection)/)) { ***SNIP***
So the issue here is the regex that LFD is using only covers log lines containing "Access denied with code" or "Access denied with connection." It would need to be (code|connection|redirection) to work with rules that redirect the attacker like the OWASP rules.
You should report this as a bug to configserver. In the mean time if you go into the file /usr/local/csf/bin/regex.pm you can make the edit to change (code|connection) to (code|connection|redirection) and it will work. I just tested this and it works great after restarting CSF/LFD.
