[Case CPANEL-13602] ModSecurity Logs Are Getting Huge With Logging Off
For the past month or so, I have watched as the amount of remaining disk space on the server has quickly decreased. I tracked it down to huge ModSecurity log files in /home/username/logs of the format:
modsec2_username_Jun_2017.gz
There were three files in each account, one for April, May, and June. Most of them were hundreds of megabytes in size, and some on the busier sites were over a gigabyte. I found this post, but the OP never responded, so it wasn't clear what the resolution is. Yesterday, as a test, I set the Audit Log Level to "Do not log any transactions" and deleted the log files to reclaim the space. The ModSecurity Tools Hits list is not populated once I turn off the Audit Log. This morning, the log files are back, created at 0514, and are already megabytes in size. Here is the output of the files requested in the above post: cat /usr/local/cpanel/etc/logrotate.d/modsecurity_logs /usr/local/apache/logs/modsec_audit.log { rotate 15 size=300M missingok compress postrotate /usr/local/cpanel/scripts/restartsrv_httpd 2> /dev/null > /dev/null || true endscript }
and: cat /usr/local/cpanel/version 11.64.0.29
I am running the Comodo WAF vendor (not the plugin) and modruid2. How can I prevent the ModSecurity logs from filling up my disk space?
There were three files in each account, one for April, May, and June. Most of them were hundreds of megabytes in size, and some on the busier sites were over a gigabyte. I found this post, but the OP never responded, so it wasn't clear what the resolution is. Yesterday, as a test, I set the Audit Log Level to "Do not log any transactions" and deleted the log files to reclaim the space. The ModSecurity Tools Hits list is not populated once I turn off the Audit Log. This morning, the log files are back, created at 0514, and are already megabytes in size. Here is the output of the files requested in the above post: cat /usr/local/cpanel/etc/logrotate.d/modsecurity_logs /usr/local/apache/logs/modsec_audit.log { rotate 15 size=300M missingok compress postrotate /usr/local/cpanel/scripts/restartsrv_httpd 2> /dev/null > /dev/null || true endscript }
and: cat /usr/local/cpanel/version 11.64.0.29
I am running the Comodo WAF vendor (not the plugin) and modruid2. How can I prevent the ModSecurity logs from filling up my disk space?
-
Hello, Internal case CPANEL-13602 is open to address an issue where the previous month's ModSecurity logs are not removed from the account's "/home/$username/logs" directory on systems with Mod_Ruid2 enabled. This happens despite enabling the "Remove the previous month's archived logs from the user's home directory at the end of each month unless configured by the user" option in "WHM >> Tweak Settings". I'll monitor this case and update this thread with the outcome. In the meantime, the workaround is to manually remove the logs. Thank you. 0 -
Do you have an Update for this problem? ( 7 years later? ) 0 -
Hello, There's no time frame to offer on the publication of a resolution at this time, but I do see some new activity on this case as of last week. I'll continue to monitor the case and update this thread with more information as it becomes available. Thank you. 0 -
Hello, There's no time frame to offer on the publication of a resolution at this time, but I do see some new activity on this case as of last week. I'll continue to monitor the case and update this thread with more information as it becomes available. Thank you.
Is it really necessary for it to take 1 year to resolve a bug when it is this critical?0 -
Hello, I brought this case up internally to note the continued reports of it leading to server's running out of disk space. I'll update this thread as soon as more information is available. Thank you. 0 -
I resolved this by not using ModRUID2, which I was only using for the symlink ownership protection, and went with the free KernelCare Symlink Ownership protection patchset. 0 -
Hello, To update, case CPANEL-13602 is planned for inclusion with cPanel & WHM version 76. Thank you. 0
Please sign in to leave a comment.
Comments
7 comments