Comodo WAF ModSecurity ruleset leading to large secdatadir cache files

weblinks

• May 19, 2019 20:12

CLOUDLINUX 7.6 [] v78.0.23 Hi, I am getting this alert Time: Mon May 20 04:00:08 2019 +0500 ModSecurity persistent IP database (/var/cpanel/secdatadir/ip.pag) size is 51.73GB This requires further investigation otherwise it will start to affect server performance. but when I am checking after an hour of this email the file size showing there is 1857786880 = 1771 MB 2 days ago, I follow the steps mentioned there to ModSecurity SDBM Utility - EasyApache 4 - cPanel Documentation to purge expired entries / purge the cache file pls suggest..

• 

  cPanelMichael

  • May 20, 2019 21:10

  Hello @weblinks, Can you open a

  0
• 

  internetbug256

  • May 24, 2019 21:21

  Hello @weblinks, Can you open a

  0
• 

  cPanelMichael

  • May 29, 2019 18:05

  Hello @internetbug256, I couldn't find a support ticket opened by the original poster. Could you

  0
• 

  dusanf

  • June 04, 2019 13:03

  Hi all, I`ve noted that /var/cpanel/secdatadir/default_SESSION.pag file sometimes grows too big. Does anyone know what is being logged in this file? I noted that when modsecurity is off, this file doesn't grow but cant determine what gets logged there. At first I thought its related to joomla only but it seems I was wrong about it.

  0
• 

  cPanelMichael

  • June 04, 2019 17:33

  Hello Everyone, A. We've seen recent reports of the third-party Comodo WAF ModSecurity ruleset leading to excessive entries in the /var/cpanel/secdatadir/default_SESSION.pag file. We are tracking this as part of internal case UPS-134. I'll follow this case and update this thread with more information as it becomes available. In the meantime, the temporary workaround is to manually prune /var/cpanel/secdatadir/default_SESSION.pag using the following steps: 1. Execute the following command to install the if it's not already installed on the system: yum install ea-modsec-sdbm-util
  2. Execute the following command to prune default_SESSION.pag: modsec-sdbm-util -s /var/cpanel/secdatadir/default_SESSION.pag
  B. Additionally, case CPANEL-27451 is open to consider adding automatic rotation/pruning support for /var/cpanel/secdatadir/default_SESSION.pag. I'll monitor this case and update this thread with more information on it's status as it becomes available. Thank you.

  0
• 

  dusanf

  • June 04, 2019 20:44

  @

  0
• 

  cPanelMichael

  • June 05, 2019 17:38

  Do you have info on rules that are using default_SESSION.pag so we can disable them?

  
  Can you confirm if you are using the third-party Comodo WAF ModSecurity ruleset, or do you mean the rule types in general? Thank you.

  0
• 

  dusanf

  • June 05, 2019 20:36

  @cPanelMichael I can confirm that use Comodo WAF using cPanel plugin provided by Comodo, yes. I tried running modsec-sdbm-util -s /var/cpanel/secdatadir/default_SESSION.pag on 4 servers but it didnt reduce the size of pag file.

  0
• 

  cPanelMichael

  • June 05, 2019 21:23

  I can confirm that use Comodo WAF using cPanel plugin provided by Comodo, yes.

  
  Hello @dusanf, Comodo yes not yet published a workaround for the issue with their rules. As a workaround, you can manually purge the /var/cpanel/secdatadir/default_SESSION.pag cache file per the commands listed under You can also run the following commands in a shell to purge the cache file on the link below: ModSecurity SDBM Utility - EasyApache 4 - cPanel Documentation Replace "ip.pag" with "default_SESSION.pag" in the example provided on the link above. Thank you.

  0
• 

  dusanf

  • June 08, 2019 21:10

  @cPanelMichael It works with manual way, I hope we get an update from comodo soon :)

  0
• 

  markhard

  • June 10, 2019 18:15

  in my server the one that grows to 52GB is nobody-ip.pag, running the SDBM utility resulted: $ modsec-sdbm-util -s nobody-ip.pag Opening file: nobody-ip.pag Database ready to be used. [-] 550 records so far. Total of 556 elements processed. 0 elements removed. Expired elements: 22, inconsistent items: 0 Fragmentation rate: 3.96% of the database is/was dirty data.
  however the size didn't reduced, and the website hosted in the server remains slow to open. only after deleting the file did it help speed up web server response. however the file size built up back to 52GB pretty soon which causes the slowness of web response. in other thread:

  0
• 

  cPanelMichael

  • June 10, 2019 18:35

  Hello Everyone, We've reached out to Comodo to report the issue with their ruleset, however we have not yet received a response. I'll continue to monitor internal case UPS-134 and report any updates to this thread. A more permanent workaround is to disable the Comodo WAF ModSecurity ruleset in lieu of an alternative such as OWASP: Thank you.

  0
• 

  markhard

  • June 15, 2019 08:05

  Hi Michael, i tried to use OWASP ModSecurity Core Rule Set V3.0 instead of Comodo's rule, however i see a lot of false positives in that rule set causing a lot of my clients got blocked. the link you gave pointed to a request ticket which already 4 months old and has no update. disabling mod_security is not an option for me. so is there a way to keep using apache24-mod_security2-2.9.2-11.11.7.cpanel.x86_64? cpanel update keeps updating it to version 2.9.3 which have this issue. i did try to add mod_security in yum.conf exclude file but it's ignored by cpanel update

  0
• 

  dusanf

  • June 17, 2019 10:35

  @cPanelMichael Is there any update on this? Now I can see nobody-ip.pag is 5GB.

  0
• 

  cPanelMichael

  • June 18, 2019 18:22

  i tried to use OWASP ModSecurity Core Rule Set V3.0 instead of Comodo's rule, however i see a lot of false positives in that rule set causing a lot of my clients got blocked. the link you gave pointed to a request ticket which already 4 months old and has no update. disabling mod_security is not an option for me. so is there a way to keep using apache24-mod_security2-2.9.2-11.11.7.cpanel.x86_64? cpanel update keeps updating it to version 2.9.3 which have this issue. i did try to add mod_security in yum.conf exclude file but it's ignored by cpanel update

  
  Hello @markhard, Could you open aOWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation Thank you.

  0
• 

  cPanelMichael

  • June 20, 2019 18:35

  Hello Everyone, We received an update from Comodo regarding this topic noting the issue should be fixed as of the most recent rule updates on 05-22-2019 and 05-31-2019 seen on the link below:

  0
• 

  dusanf

  • June 29, 2019 13:24

  1.210 fixes a lot of issues and returns bruteforce protection, highly recommend to upgrade to it :)

  0
• 

  sumi21kav

  • July 06, 2019 06:25

  1.211 version, still experiencing the same issue. Nobody-ip.pag is getting too big too fast Any permanent solution ?

  0
• 

  cPanelMichael

  • July 08, 2019 17:25

  .211 version, still experiencing the same issue. Nobody-ip.pag is getting too big too fast

  
  Could you open a

  0
• 

  aegis

  • August 01, 2019 22:27

  I've also had this though with CWAF ruleset 1.215 and I'm using ModSecurity ea-apache24-mod_security2-2.9.3-2.el6.cloudlinux.x86_64 I had a 52G nobody-ip.pag on one server and 29G on another and httpd processes were running at 100% or more. Possibly also causing huge IO utilisation issues also. I've pruned the database using the following commands... [CODE=bash]/usr/sbin/modsec-sdbm-util -D /var/cpanel/secdatadir -v -n /var/cpanel/secdatadir/nobody-ip.pag &&\ rm /var/cpanel/secdatadir/nobody-ip.pag &&\ rm /var/cpanel/secdatadir/nobody-ip.dir &&\ mv /var/cpanel/secdatadir/new_db.pag /var/cpanel/secdatadir/nobody-ip.pag &&\ mv /var/cpanel/secdatadir/new_db.dir /var/cpanel/secdatadir/nobody-ip.dir
  And then restarted httpd and server load has come down to normal. Since CWAF seems to use a different database file, perhaps this needs to be added to a maintenance script @cPanelMichael ?

  0

Please sign in to leave a comment.