Failed to write to DBM file "/tmp/ip"


From time to time I see many of those errors under Apache “error_log” file:

ModSecurity: collection_store: Failed to write to DBM file “/tmp/ip”: Invalid argument

Some info about this: Modsecurity Handbook - Ivan Ristic - Google Knjige

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.”]

Any chance to fix brute force rules?

You can exclude any rule you need in file /<path_to_cwaf>/cwaf/etc/httpd/global/zzz_exclude_global.conf. Its format:

less /<path_to_cwaf>/cwaf/etc/httpd/global/zzz_exclude_global.conf

category: Global

<LocationMatch .*>
SecRuleRemoveById 214450 214440 214930 214500 214400 214560 214630 214620 214470 214800 214530 214650 214590 214680 214900 214430 214940 214600 214610 214920 214580 214490 214410 214640 214910 214550 214570 214460 214660 214540 214420 214510 214520 214670 230003 230000 230007 230004 230002 230006 230001 214310

Also you can create such file for each domain, name it as and place it into /var/cpanel/cwaf/etc/httpd/domains/


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:

Before activating the Brute Force filter: - - [12/Aug/2014:13:47:46 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [12/Aug/2014:13:47:47 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [12/Aug/2014:13:47:48 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [12/Aug/2014:13:47:50 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-”

After activating it: - - [12/Aug/2014:13:47:52 -0400] “POST /wp-login.php HTTP/1.0” 302 - “-” “-” - - [12/Aug/2014:13:47:55 -0400] “POST /wp-login.php HTTP/1.0” 302 - “-” “-” - - [12/Aug/2014:13:47:59 -0400] “POST /wp-login.php HTTP/1.0” 302 - “-” “-” - - [12/Aug/2014:13:48:00 -0400] “POST /wp-login.php HTTP/1.0” 302 - “-” “-” - - [12/Aug/2014:13:48:02 -0400] “POST /wp-login.php HTTP/1.0” 302 - “-” “-”

A few minutes later, requests go back to being handled just like they used to: - - [12/Aug/2014:13:47:46 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [12/Aug/2014:13:47:47 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [12/Aug/2014:13:47:48 -0400] “POST /wp-login.php HTTP/1.0” 403 4092 “-” “-” - - [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] 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] 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.

Our rules ban ip-addresses, but in your case it doesn’t work because of #Failed to write to DBM file “/tmp/ip”# error.


I have the same problem.
Could you help me to fix it?

I’ve found only this method to fix this trouble: I’ve downloaded the sources apr and apr-utils, build rpm and updated apr and apr-utils, but I’ve get the next in error log:

[Tue Aug 19 05:59:31.000711 2014] [:notice] [pid 7683:tid 140051432286016] ModSecurity: APR compiled version=“1.4.6”; loaded version=“1.5.1”
[Tue Aug 19 05:59:31.000722 2014] [:warn] [pid 7683:tid 140051432286016] ModSecurity: Loaded APR do not match with compiled!

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.

We are seeing this as well and the listed fix is not applicable to a cPanel installation.

We´re seeing this also on all our cpanel servers.


Seems only solution is to recompile Apache and APR-Util.

[url=] SpiderLabs Blog[/url]

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.

More instructions here.

I can’t do that on a cpanel server.

I need other solution. Turn OFF brute force attacks will remove this problem?

I’ve two servers that still have OWASP (old version), and they don’t have this problem (they’re also very high traffic servers)


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.

Thank you oleg

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.

[*]Enable failure detection of repeated Apache mod_security rule triggers LF_MODSEC = Default: 5 [0-100] LF_MODSEC_PERM = Default: 1 [0-604800]

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.

Increase number of failed logins.

Increasing it’s not a solution. the config have already 10 failed logins. Upper than that it’s pointless

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.