After deleting “ip.dir” and “ip.pag” from /tmp folder errors are gone and mod_security again works ok.
I believe that this is related to “brute force” rules because this issue is not happening when brute force rules are turned off.
But I can’t disable those rules because of many Joomla and WP brute force attacks.
“error_log” is full of those detections:
[msg “COMODO WAF: Multiple Username Violation: Too Many Usernames Submitted for Authentication.”]
Yes, I know that, I can exclude rules via cPanel module too.
But I don’t want to do that because I need brute force protection (Joomla and WP admin are massively attacked).
What I’m asking is to check those brute force rules to avoid “Failed to write to DBM file “/tmp/ip”: Invalid argument” errors.
When this starts to happening mod_security is not working at all.
I second this. I recently upgraded to client 1.9 and activated Brute Force protection rules. I analyzed the access logs of a specific account that was being brute-forced and this is what I found:
A few minutes later, requests go back to being handled just like they used to:
202.77.109.253 - - [12/Aug/2014:13:47:46 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-”
202.77.109.253 - - [12/Aug/2014:13:47:47 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-”
202.77.109.253 - - [12/Aug/2014:13:47:48 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-”
202.77.109.253 - - [12/Aug/2014:13:47:50 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-”
Upon inspecting the error logs:
[Tue Aug 12 14:03:17.600548 2014] [:error] [pid 189538] [client 202.77.109.253] ModSecurity: collection_store: Failed to write to DBM file “/tmp/ip”: Invalid argument [hostname “HIDDENBYOP”] [uri “/wp-login.php”] [unique_id “U@pW5UPXD3oAAuRin6YAAAA@”]
[Tue Aug 12 14:03:19.339073 2014] [:error] [pid 193338] [client 202.77.109.253] ModSecurity: collection_store: Failed to write to DBM file “/tmp/ip”: Invalid argument [hostname “HIDDENBYOP”] [uri “/wp-login.php”] [unique_id “U@pW50PXD3oAAvM6NlkAAAAr”]
So it looks to me like the actual protection is not working, and there’s something very buggy going on here.
Ideally it would be great if WAF would ban a particular IP in the firewall after X number of failed logins. I am using CSF and assume most other WAF users are too, so a seamless integration would be ideal. Either way, the number one priority should be to get these rules working correctly, as they clearly are not right now.
Despite several exchanges with Comodo support this issue appears to be ongoing and is still not resolved in the latest version. I would advise users not to activate the BruteForce filters as they do not appear to work and instead flood your error logs needlessly.
If anyone’s figured out a working solution, I’d love to hear from you!
I would really like this solved asap. My users are on a server that uses CloudLinux and are placed in LVE that limits their Entry Processes. When their wp-login.php gets hit like this it takes their website down at certain times when they hit 20 concurrent connections. Any ideas as yet to limit brute force.
Depending on the amount of data you need to profiler per resource, you may run into SDBM persistent storage size limits. By default, you have ~800 bytes of usable storage. If you run into this issue, you will see this error message:
Failed to write to DBM file “/tmp/IP”: Invalid argument
If you need more than that, you should download the separate APR and APR-Util packages then edit the “#define PAIRMAX” setting in the /dbm/sdbm/sdbm_private.h file. You should then recompile both Apache and ModSecurity referencing the updated APR/APR-Util packages.
This is why our brute force rules turned off by default.
Yes, if you turn “HTTPDoS”(category “HTTP”) and ‘Bruteforce’ groups off this will solve the problem.
It fails to record ip and therefore ip doesn’t get banned. If you dont want to disable brute force and want block IP Better use CSF to do the same job for you. CSF monitors your /usr/local/apache/logs/error_log and blocks IP based on what you have specified in config file.
Unfortunetaly that don’t work well. For example, you’ve a client with a site that gives 5 false positives, CSF block the client ip, and the client goes running to the phone saying he’s blocked without reason. And it’s always very difficult to explain and calm a client like that.
Did anyone actually find a working solution for brute force on litespeed servers?
It worked like a charm for many months, but when we updated the rules/agents many months ago brute force just stopped and caused customers to get angry because of faulty 403 etc.
It’s working fine on Apache servers, but I cannot see why this should be a problem on Litespeed.