Alerts received on incorrect interface
-
@bmeeks You really should give write-ups on the inner workings of pfSense and the packages. You give really good details on why something works the way it does.
That said, the work around will be to run an instance of Suricata on each VLAN.
Appreciate the response. Appreciate the work involved. -
I think I also see this on a Netgate 7100.
WAN ... lagg0.4090
LAN ... lagg0.4091I have snort on LAN and have the strange behavior that I see blocked IPs, but zero alerts on that interface!
So no way to suppress things right now. and somehow WAN traffic snorted when I only want to process LAN traffic.
hints welcome ;-)
edit: I also see blocking when blocking is disabled on all snort interfaces.
This is on an updated pfSense-23.01, snort installed and configured only 2 days ago (from scratch).edit 2: removed snort and installed suricata. So far this seems to work much better. Although I haven't yet seen a single alert and/or block (alerting only configured now). But no blocks without alerts so far.
-
@sgw said in Alerts received on incorrect interface:
I think I also see this on a Netgate 7100.
WAN ... lagg0.4090
LAN ... lagg0.4091I have snort on LAN and have the strange behavior that I see blocked IPs, but zero alerts on that interface!
So no way to suppress things right now. and somehow WAN traffic snorted when I only want to process LAN traffic.
hints welcome ;-)
edit: I also see blocking when blocking is disabled on all snort interfaces.
This is on an updated pfSense-23.01, snort installed and configured only 2 days ago (from scratch).edit 2: removed snort and installed suricata. So far this seems to work much better. Although I haven't yet seen a single alert and/or block (alerting only configured now). But no blocks without alerts so far.
If you saw blocks with no corresponding alert, then it is highly likely you had another uncontrolled (or zombie) Snort process running on the interface. This can happen sometimes. You wind up with duplicate Snort instances on the same interface, but only one of those instances responds to- and provides updates to- the GUI.
LAGG interfaces are really not well supported. Ditto for Bridge interfaces. The IDS/IPS packages expect plain vanilla interfaces. They also do not always behave as expected with VLANs. All of these: VLANs, LAGGs, and Bridges are actually virtual interfaces created by the FreeBSD operating system. The IDS/IPS code expects "real, physical" interfaces. It can perhaps work with a virtual interface, but results will be spotty.
Some work is underway by others to patch the netmap kernel device so that it better supports LAGG, Bridge, and VLAN interfaces.
-
@bmeeks thanks for the explanation.
Looking at that system it seems to work OK. For sure I don't know what maybe is missing from the shown alerts etcI am in the process of trying to learn the basics and decide if and where to use IDS/IPS. My customers mostly don't have any internal IT staff, so who maintains it, who even looks at the alerts etc?
So I am running it in alerting-only and try to see what happens in their subnets. And I learn things :-) thanks
-
@sgw said in Alerts received on incorrect interface:
My customers mostly don't have any internal IT staff, so who maintains it, who even looks at the alerts etc?
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.
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.
-
@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.
