Alerts received on incorrect interface
-
@bmeeks said in Alerts received on incorrect interface:
In that circumstance, I would be extremely reluctant to deploy an IDS/IPS in blocking mode. Any IDS/IPS is subject to generate false positives, and if no qualified admin is there to immediately assess the alert and disable or otherwise remediate the resulting block, the users will be very frustrated.
I agree and see that danger.
And there is a warning for simple alerting mode as well. If the firewall is a device without a spinning hard disk (or a very good quality server-grade SSD), the amount of logged data from an IDS/IPS can result in quickly exhausting the write cycles of the disk. Prime example would be a smallish eMMC type disk.
Had that today ;-) suricata filled ~4 GB of storage since yesterday.
Although the information text says that per default it should only use 25(?)% of the free storage it filled up the root filesystem completely.I set a limit of 1 GB now for a start, but sure, that won't give much history to browse through etc. / It's a test anyway, we'll see if we keep it at that site. At least in that place there's a admin on site most of the time.
-
@sgw said in Alerts received on incorrect interface:
I set a limit of 1 GB now for a start, but sure, that won't give much history to browse through etc.
The recommended approach is to export logging data off to a dedicated third-party SIEM platform. There are several open-source varieties to choose from, especially for Suricata when using its EVE JSON logging options.
-
I see.
The set limit didn't work, by the way. Full rootfs again today.
I reduced the limit again and edited some time spans down. Plus: disabled one interface in suricata, looking at the DMZ only now. -
@sgw said in Alerts received on incorrect interface:
I see.
The set limit didn't work, by the way. Full rootfs again today.
I reduced the limit again and edited some time spans down. Plus: disabled one interface in suricata, looking at the DMZ only now.Forcing the Suricata binary to rotate logs is very difficult. There is no built-in ability within the binary's code for rotating logs based on their size. The only log rotation option available in the binary is a time interval one where the log file is rotated on a fixed interval regardless of the file's size. And even that limited option is not available for every type of log file.
The GUI package for Suricata attempts to force size-based log rotation by checking log sizes using a crontab task that runs every 5 minutes. That job checks the current log file and directory sizes against user-set limits. For files that meet the rotation critiera, it rotates them by changing the file name, "touches" a new empty file with the original name, and then sends a SIGHUP signal to the binary. The SIGHUP is supposed to cause the binary to restart logging, but that is not always honored by the binary in my experience. When the SIGHUP is not honored, the binary will continue to write to the old log file and thus can fill up the disk.
I really wish the upstream Suricata team would add a size limit rotation feature to all of the log files.
-
@bmeeks thanks for the explanation. Since yesterday the limit seems to work, just checked.
