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?
-
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.
-
@ngnym I think I have this problem too. I am currently at 92% disk usage, and most of my storage is tied up in suricata logs. I have the 500 KB default for alerts.log for example, and my WAN alerts.log is at 780M and my LAN is at 387M. I had to disable the service. I am unsure if i should delete the logs myself or wait for the update to re-enable the service, and let that clean it up.
-
@bmeeks I am not sure that is the case, for my problem, as all of my logs are .log, and none of them have what I would expect a log rotation filename extension to look like.
suricata_igb119463: total 2565604 -rw-r--r-- 1 root wheel 780M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 942M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 783M Aug 23 00:41 tls.log suricata_ngeth036678: total 2016516 -rw-r--r-- 1 root wheel 387M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 943M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 638M Aug 23 00:41 tls.logI guess unless it doesnt create the empty file without at least one log message, than that would make alot of sense.
-
@septer012 said in Suricata Logs Mgmt Not Working?:
@bmeeks I am not sure that is the case, for my problem, as all of my logs are .log, and none of them have what I would expect a log rotation filename extension to look like.
suricata_igb119463: total 2565604 -rw-r--r-- 1 root wheel 780M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 942M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 783M Aug 23 00:41 tls.log suricata_ngeth036678: total 2016516 -rw-r--r-- 1 root wheel 387M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 943M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 638M Aug 23 00:41 tls.logI guess unless it doesnt create the empty file without at least one log message, than that would make alot of sense.
What kind of hardware are you running Suricata on (Intel/AMD or ARM)? And what is the version of the Suricata package that you have installed?
