Suricata Logs Mgmt Not Working?
I was having some issues with my SG-3100 a while back, and after some troubleshooting, I found out that the log files in /var/logs/suricata/<interface> had never been managed automatically. As I had recently updated, I thought maybe the update would fix the issue, so I stopped suricata, deleted the logs, and started it again to find my issues resolved. I assume they were memory issues due to suricata accessing very large log files. I just now noticed that http.log was 7 MB in spite of having the Logs Mgmt tab settings at 1 MB and 7 days. The log file also had more than 7 days worth of history in it. This is on 2.4.5-RELEASE-p1 (arm). Am I doing something wrong, or is this a bug?
bmeeks last edited by bmeeks
There is a potential issue where, once a log is rotated, the running Suricata process does not honor the rotation and keeps writing to the original log. This should be fixed in the next update. That update is already available in the pfSense-2.5 DEVEL snapshot branch. It should show up in the RELEASE branch soon (as Suricata-5.0.3 for amd64 hardware and Suricata-4.1.8 for arm hardware).
One workaround for now would be to disable logging for things that you may not actually care about. This will be a user-specific thing and depends on your particular situation. For most home users, there is no benefit to logging a lot of the stuff Suricata can log. If you don't look at it on a regular basis, is it really worth logging?
Suricata is a diffult product to manage in terms of logging. Each logging subsystem does not offer the same options within the binary for controlling the logs.