Suricata issue in PFSense
-
@sstatjm said in Suricata issue in PFSense:
@bmeeks oh ok. I never stop and restart it. Only did a restart only. I just did it thou. So will monitor for a few hours and see
A restart using the GUI icon is sufficient. That actually issues successive "stop" and then "start" commands to the binary running on the interface.
Do your VLANs communicate with each other? If so, it would be expected to see addresses from other VLANs show up in alerts for a given VLAN. So for example, if a host in VLAN A communicates with a host in VLAN B, and that traffic triggers an alert, you would expect to see the VLAN A host address in the alerts for VLAN B and the VLAN B address in the alerts for VLAN A. Are you seeing that type of traffic, or something else?
-
@bmeeks There is nothing hosting on Lan and VLan1, however they both talk to Vlan2. So why would ip addresses for Vlan1 show up in LAN?
-
@sstatjm said in Suricata issue in PFSense:
@bmeeks There is nothing hosting on Lan and VLan1, however they both talk to Vlan2. So why would ip addresses for Vlan1 show up in LAN?
I'm not following your description. Give me the name of the physical parent interface for each VLAN you have, or even better, screenshot the Interface Assignments and VLANs tabs from your pfSense installation.
The phrase "there is nothing hosting on Lan and VLan1" is confusing to me. What do you mean by that?
-
LAN and TREJAH isnt suppose to talk to each other
-
@sstatjm said in Suricata issue in PFSense:
LAN and TREJAH isnt suppose to talk to each other
This is not what I mean. I need to see the actual Assignments tab content along with the VLANs tab content. I am trying to figure out which physical interface or interfaces is hosting which VLANs.
-
@bmeeks WAN & LAN is the physical interface and the others are the VLANs.
-
@sstatjm said in Suricata issue in PFSense:
@bmeeks WAN & LAN is the physical interface and the others are the VLANs.
You are not understanding my request.
Your VLANs run on a physical interface. In FreeBSD, that will be based on the hardware NIC driver. For example, a popular Intel model is
igb
. When you create VLANs, they are created as virtual interfaces on top of some parent interface. The VLAN interfaces will show up asigb0.10
or something where the.10
is the VLAN ID andigb0
is the physical parent interface. If you have 4 NIC ports on a box and all four use theigb
driver, then your four physical interfaces on the firewall will beigb0
,igb1
,igb2
, andigb3
. If you created VLANs on any of those physical interfaces, the VLAN's physical parent would be 'igbX
followed by a period (.
) and the assigned VLAN ID.So I need to know which physical interface is your LAN and what the physical interfaces are for your VLANs.
-
-
@sstatjm said in Suricata issue in PFSense:
Okay, that shows everything is running on the same underlying single physical interface -
ix1
. Your two VLANs are running on virtual interfacesix1.50
andix1.60
.The first thing to check is that the Promiscuous Mode checkbox on the INTERFACE SETTINGS tab is NOT checked on all three interfaces: LAN, iOT, and Trejah. If you make any change to any of these interface settings, restart Suricata on the affected interface.
Promiscuous Mode would be the most likely cause of seeing an IP address on an interface where you do not normally expect it. It's also possible that you have a port misconfiguration in your managed switch. A third possibility is something changed with regards to promiscuous mode upstream in the Suricata binary, but I am not aware of any issues being reported there. Nothing has changed around that code in the PHP GUI in eons (that I can recall).
If this is a sudden change in behavior, then I would first suspect an issue in the Layer 2 infrastructure. Maybe a port was mistakenly misconfigured on the switch, or somebody plugged something into the wrong switch port ???
-
@bmeeks Suricata is restarted. Promiscuous mode is unchecked. Nothing connected incorrectly to switch.
-
@sstatjm said in Suricata issue in PFSense:
@bmeeks Suricata is restarted. Promiscuous mode is unchecked. Nothing connected incorrectly to switch.
If you want to share the alerts in question, me having a look at them might be helpful. I would also need to know the IP subnets you have assigned to each interface: LAN, iOT, and Trejah. I assume those are RFC1918 space, so there would be no security concerns with sharing the IP subnets as those are non-routable on the Internet anyway.
-
All this is on LAN interface with the .60.50 which is VLAN 60 sources showing in there.
-
Curious, so no
192.168.50.x
entries show up on the LAN, or did you just not include them as they may be expected?The most straightforward explanation is that promiscuous mode is enabled even if not explicitly showing as such in the GUI.
From one of your earlier replies I got the impression this behavior just suddenly started happening, and prior to that you never saw
192.168.60.50
addresses in alerts on the LAN. Is that correct?Has anything changed in your environment that might coincide with this change in behavior? Promiscuous Mode can't just turn on by itself with no user action. Have you updated any software or firmware either on pfSense or in the managed switch infrastructure? Might a port VLAN setting have been accidentally altered?
If you can, try rebooting the firewall to be sure there are no duplicate Suricata processes running that may still have promiscuous mode enabled. In rare cases multiple Suricata instances can get started on the same interface, and then all but the most recently launched one stop responding to configuration changes. Running this command can show if any duplicates are running:
ps -ax | grep suricata
You should see one Suricata instance per interface, so four instances for you counting your WAN.
-
@bmeeks I must have missed that for the iOT. I will reboot the pfsense then. I have made no changes recently. Promiscous mode is off. I dont have WAN running suricata
-
@sstatjm reboot is done so will see if it still show up in there again.