Suricata log limits not respected
-
i have the log directory size limit set to 48mg but see the alert file is 732mg
-
What version of pfSense and Suricata are you running?
There were some issues in the past with Suricata not properly releasing the "old" log file and continuing to write to it when a log was rotated. I thought I had fixed that, though.
To reduce the size of the directory, stop Suricata using the GUI tools. Then open a CLI session to the firewall and navigate to
/var/log/suricata/
. Under that path you will find a separate subdirectory for each configured Suricata interface. Find the 732 MB file and either delete it (if you want to recover the space) or rename it with a timestamp of some sort as an extension. Then restart Suricata. That will force Suricata to open a new alerts log file. -
@bmeeks 2.4.5-RELEASE-p1 & 5.0.4_2
-
@gwaitsi said in Suricata log limits not respected:
@bmeeks 2.4.5-RELEASE-p1 & 5.0.4_2
Hmmm...I really was thinking I had finally slain all the elusive logs manangement gremlins. It's hard because the Suricata binary itself does not offer rotation on all logs, so you have to resort to a few tricks.
See if perhaps you have a duplicate Suricata process running by executing this command from a shell prompt on the firewall --
ps -ax | grep suricata
You should see exactly one process per configured Suricata interface. So if you have just one instance of Suricata, then one process. If WAN and LAN, then two processes, etc.
If you see any extra (besides the single line that will show your current
grep
command), then that will be a zombie Suricata process. Kill any zombie processes with this command:kill -9 <pid>
where
<pid>
is the process ID of the zombie process.Report back on what you find. If you don't find any duplicate zombie process, then stop Suricata using the GUI icon, delete or rename the large
alerts.log
file under/var/log/suricata/
and then restart Suricata. -
@bmeeks the log file was rotated, so i was able to simply delete it via ssh
if just checked the status and there are plenty of rotated logs since the original post, so looks to be ok. strange
-
@gwaitsi said in Suricata log limits not respected:
@bmeeks the log file was rotated, so i was able to simply delete it via ssh
if just checked the status and there are plenty of rotated logs since the original post, so looks to be ok. strange
Okay. Glad it seems to be working. That file should not have gotten that large, though. Post back if it acts up again.
-
Hi folks
On pfSense 2.6.0-RELEASE with suricata 6.0.4_1 we can see big alerts.log files for Suricata.
du -sh * | sort -h /var/log/suricata 196K suricata_rules_update.log 1.8G suricata_(censoredif1) 2.8G suricata_(censoredif2) 156G suricata_(censoredif3)
ls -lah /var/log/suricata/suricata_(censoredif3) total 163657800 drwxr-xr-x 2 root wheel 512B Jun 12 19:54 . drwx------ 5 root wheel 512B Jun 12 19:52 .. -rw-r--r-- 1 root wheel 153G Oct 12 09:49 alerts.log -rw-r--r-- 1 root wheel 1.2G Oct 12 09:49 http.log -rw-r--r-- 1 root wheel 891M Oct 12 00:03 suricata.log -rw-r--r-- 1 root wheel 1.2G Oct 12 09:49 tls.log
There is only one Suricata process for every Interface (confirmed by ps -ax | grep suricata).
Log Size and Retention Limits for "alert" is set to 500 KB (default) and seems to be ignored.
I will free up disk space by stopping the service and removing the logs.
But as this happened already a few times on different installations maybe there is an update to this issue? Should we file a bug report? (Although I'm not sure I have enough data to be precise enough.)
Thanks for your help!
Dan -
-
Try updating to the latest pfSense version and the latest Suricata package. pfSense CE is now on version 2.7.0 and the Suricata package is at version 6.0.13. There have been several changes in Suricata since the version you have.
You can't update to the latest Suricata package without first updating pfSenses to 2.7.0.