Broken update?

Free Modsecurity rules - Comodo Web Application Fi
1

I have multiple servers giving the error:

collection_store: Failed to write to DBM file “/var/cpanel/secdatadir/ip”: Invalid argument

It seems to occur with every access, not just violations and is a recent issue.

Is there an issue with a recent update or something?

I’ve tried disabling the bruteforce rule set in case that was the issue, but no change.

Anyone else experiencing this?

2

Yea, I’m seeing this too.

I thought this might’ve been some custom rules I had been using, but I’ve disabled those and I’m still seeing this.

Did this start with 1.140? I’m just now noticing it, but I won’t say for certain that it started with 1.140.

I may try downgrading to 1.139 and see if that fixes anything.

3

I’m not certain which version it started with, but it was definitely recent.

4

Best, I can tell this did start with 1.140. Downgrading to 1.139 seems to resolve this issue (at least in the limited time I have been watching this).

Checking this further, I believe the issue is in the 12_HTTP_HTTPDoS.conf file

Specifically the added lines:

SecRule REQUEST_FILENAME "@ge 0" \
      "id:217310,chain,msg:'COMODO WAF: Emergency DDoS bot protection test.||%{tx.domain}|%{tx.mode}|2',phase:4,pass,log,t:none,t:length,rev:3,severity:2,tag:'CWAF',tag:'HTTPDoS'"
SecRule &IP:COOKIE_SENT "@eq 0" \
      "chain,setvar:'ip.unique+%{UNIQUE_ID}'"
SecRule STREAM_OUTPUT_BODY "@rsub s/<head>/<head><script>document.cookie=\"jsddosbd=%{ip.unique};max-age=300;path=\/;\";<\/script>" \
      "setvar:'ip.cookie_sent=1',expirevar:'ip.cookie_sent=300',t:none"

SecRule IP:COOKIE_SENT "@eq 1" \
      "id:217311,chain,msg:'Client failed emergency DDoS bot protection test||%{tx.domain}|%{tx.mode}|2',phase:1,deny,log,t:none,rev:3,severity:2,tag:'CWAF',tag:'HTTPDoS'"
SecRule &REQUEST_COOKIES:jsddosbd "!@eq 1"

SecRule IP:COOKIE_SENT "@eq 1" \
      "id:217312,chain,msg:'Client failed emergency DDoS bot protection test||%{tx.domain}|%{tx.mode}|2',phase:1,deny,deny,log,t:none,rev:3,severity:2,tag:'CWAF',tag:'HTTPDoS'"
SecRule REQUEST_COOKIES:jsddosbd "!@streq %{ip.unique}" \
      "t:none"

(Pretty much the last 14 lines of that file)

If you comment out those lines, this seem to stop this error from flooding the error_log.

I do not know what specifically in these rules is causing this issue.

5

We’ve seen the same issue on multiple cpanel servers, the /var/cpanel/secdatadir/ip.pag file grow to 100GB. The server had high CPU/IO usage, and caused some server down. Disabled the http rules seems fix the issue.

This is 2nd time the comodo rule update bring down our servers. We’ve disabled the auto-update.

6

Yes, the rules 217310, 217311 and 217312 do appear to be the culprit.

Disabled those for now.

7

It’s one of unresolved issues with Modsecurity, discussed several times even at this forum. The best way to avoid it is to exclude (not to disable) these rules.
It can be performed with CWAF plugin in Catalog.

8

I’m using Comodo as a ModSecurity vendor in cPanel rather than the plugin. The only option is to “disable” those rules to stop this issue.

Additionally, this particular issue is not the same issue as previously getting it with other bruteforce rules enabled.

With these DDoS rules enabled, you get this error with every access, not ModSecurity violations.

9

Hello guys,

Same problem here.

What´s the best way to disable it? I´m using comodo rules in cpanel vendors.

Best regards
Joao

10

Go to Modsecurity Tools in cPanel, click Rules List, search for 2173 and that will bring up the 3 rules you need to disable (217310, 217311 and 217312), click Disable for each and then scroll down and click save and restart apache.

11

Very thank you.

This solution worked fine for me.

Best
Joao

12

Updated information:

http://permalink.gmane.org/gmane.comp.apache.mod-security.user/5449
https://www.feistyduck.com/library/modsecurity-handbook-free/online/ch03-configuration.html

13

There is no doubt the “Failed to write to DBM file” issue is nothing new with ModSecurity and using the bruteforce rules on a server that is receiving a high rate of brute force attempts will cause the ModSecurity data file to grow and begin generating that error. That is not the point here.

The point here in this thread is that the new rules 217310, 217311 and 217312 specfically is making the ip.pag file grow at an extremely faster rate and made the issue incredibly worse to the point overall server performance is being negatively affected greatly.

14

We are sorry, please update to the new version of the rules: 1.141

See details here:

https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/rules-updates-changelog-t101377.0.html;msg866636#msg866636

15

Thank you, much appreciated!

16

Summary solution
***************

For everyone who updated to 1.140 you need:

  1. Update to the latest version (1.141 at this moment)
  2. Disable 217310, 217311 and 217312 rules using plugin or Command Line Utility (Comodo Help)
# ./cwaf-cli.pl -xa 217310
  1. Restart web server

this will solve problems with CPU extra load issue and flooding in the error_log issue.

17

So you released an update but left the offending rules in?

What’s the point of the update then?

18

That release included rules which should be disabled by default and should be enabled only in special emergency case, but those rules were enabled and I recommend to disable them now.

19
  1. Update to the latest version (1.141 at this moment)
  2. Disable 217310, 217311 and 217312 rules using plugin or Command Line Utility (Comodo Help)
    Code: [Select]

./cwaf-cli.pl -xa 217310

  1. Restart web server

Did all this and we are rotating the ip.pag every few minutes, but the file is still growing large and http is slowing to a hault.

20

1.142 available