We moved from paid Atomic Rules to Comodo WAF rules and all works well. Just one thing we cannot get working is that wp-login.php and administrator/index.php for Joomla and Wordpress websites get hit a lot as per below. Clients are in CloudLinux LVE so only affects the one customer but still it happens to random ones each day.

Already posted on Comodo Forums aswell as webhostingtalk.com but still waiting on response. I get quicker response here

I put this in /usr/local/apache/conf/modsec2.user.conf before last line (Include /usr/local/apache/conf/modsec2.whitelist.conf) but no effect.
Any ideea please? In last 2 days we are under continuu attack with /wp-login.php

There will be a conflict if you enable both cPHulk and the LFD component of CSF. cPHulk and LFD do the same thing and enabling them both at the same time will eventually cause a conflict.

Click to expand...

What conflict are you talking about? They work fundamentally differently, and while it's not necessary to have both, they don't really conflict. I've never seen an issue where having both cPHulk and CSF/LFD running caused any actual problems, this being over 4-5 years on literally thousands of servers. cPHulk will lock out usernames, where as LFD/CSF actually will block IPs in the servers firewall (iptables). Typically I recommend CSF over cphulk, since CSF won't lock you out of root on your own server during a brute force (and yes, I know about the IP whitelist).

Does anyone know how to correctly modify these rules to 1) block after 5 unsuccessful attempts instead of 10 2) make it a PERM block not a temporary 5 minute block

Click to expand...

For the first part:

SecRule ip:bf_counter "@gt 10"

Change that to @gt 5 (or whatever number)

For the 2nd part (block time), this is what sets the 5 minutes:

expirevar:ip.bf_block=300

You could raise the number (300s = 5 mins), or probably omit that to just not expire it. However, what I do is just use LF_MODSEC in csf. If they keep trying during that 5 minute window, CSF will block their IP in iptables for you which is better anyway.

This may interfere with some normal uses of xmlrpc but I have not had any complaints. If a customer wants to POST legitimate data to xmlrpc.php they just need to specify something (anything) as a referer in their HTTP headers.

This may interfere with some normal uses of xmlrpc but I have not had any complaints. If a customer wants to POST legitimate data to xmlrpc.php they just need to specify something (anything) as a referer in their HTTP headers.

The first rule will work OK. The reason I used the REQUEST_URI instead of LocationMatch for it is in case someone needs the rule whitelisted it is easier. A locationmatch whitelist won't work right if the rule itself is already in a locationmatch section. Your first rule, and the one you quoted that I posted, will do exactly the same thing.

The second one will work, but for the wrong reasons. xmlrpc does not 302 for successful requests like wp-login does. Basically what that 2nd rule would end up doing is simply rate limiting the number of calls that can be made to xmlrpc that result in normal 200 OK returns. If any IP hits an xmlrpc file more than 10 times in 3 minutes it will be blocked from xmlrpc files, regardless of any other attributes of the request. The RESPONSE_STATUS "^302" line is probably not needed at all. Honestly, it's probably not a bad rule to try out.

I've attempted adding these to the file:
/usr/local/apache/conf/modsec2.user.conf however I am not seeing any effect. I have some earlier logs from mod_security from earlier this morning, however there is an ongoing bruteforce attack going, and adding this rule has had no effect. I have restarted the webserver (running Litespeed). I have confirmed the there is a huge number of login attempts on the same site from the same IP address.

The rules show up (although not as one but several) in the ModSecurity Tools rules list. I use CSF and cpHulk is disabled.