SNORT Alerts and Interfaces
-
Your rule is detecting with traffic flowing either way. So the 192.168.20.0/24 network can be source or destination and the rule will fire. Same for the 192.168.10.0/24 network.
Snort sits outside of the firewall rules, so depending on which interface or interfaces you have Snort running on, it will be seeing this traffic before the firewall rules logic. This is a common misconception among users. Snort sits between the NIC and the firewall rules. It does not sit "behind" the firewall rules. So firewall rules have no bearing on what Snort on a given interface sees. Snort also puts an interface into promiscuous mode.
You did not give any details about which interface or interfaces have Snort configured on them. Do you have a Snort instance on both your LAN and Guest networks, or just the LAN or just the Guest? Is the Guest network a VLAN?
-
@bmeeks
Hello breeks, I have SNORT running on the LAN and the GUEST network interfaces. The GUEST network is a VLAN.So if I understand you, SNORT will see a packet addressed to the LAN device from the GUEST device before a rule (blocking) gets applied to the packet?
My objective is to use SNORT to detect if that packet actually made it through to the LAN. I want to detect if any GUEST devices are communicating with LAN devices.
-
@powerextreme said in SNORT Alerts and Interfaces:
lert on any inter-Lan Traffic 192.168.10.0/24 is LAN 192.168.20.0/24 is GUEST
alert tcp 192.168.10.0/24 any <> 192.168.20.0/24 any (msg:"Unauthorized interLAN traffic"; sid:1000001; rev:1;)
I also have a firewall rule blocking traffic from the Guest network to the LAN network.You should block traffic from your GUEST network to your local LANs with a firewall rule, something like this:-
n_ip_local is an alias containing my local subnets.
-
@powerextreme said in SNORT Alerts and Interfaces:
@bmeeks
Hello breeks, I have SNORT running on the LAN and the GUEST network interfaces. The GUEST network is a VLAN.So if I understand you, SNORT will see a packet addressed to the LAN device from the GUEST device before a rule (blocking) gets applied to the packet?
My objective is to use SNORT to detect if that packet actually made it through to the LAN. I want to detect if any GUEST devices are communicating with LAN devices.
In your case, the firewall rule action will happen AFTER the packets have passed by Snort. Snort is sitting between your physical NIC and the rest of pfSense. So one way of looking at inbound traffic on the LAN is like this --
NIC --> Snort --> Firewall Rules
To be more technically precise, Snort uses
libpcapand works with copies of the packets when running in Legacy Blocking Mode. So packets actually go from the NIC straight to the firewall rules, but a copy of every packet is also sent to Snort (from the NIC and before the firewall rules). So my original statement is true: Snort sees packets before firewall rules are applied when the traffic is inbound on an interface. For outbound traffic from an interface, the firewall rules have already been applied before the packet gets to Snort and the NIC.So outbound traffic on an interface looks like this --
Firewall Rules --> Snort --> NIC
-
I think I understand. But how does that explain the alerts? The alerts happened on the LAN interface. It shows the the source as coming from the GUEST networking to an address in the LAN network.
-
@powerextreme said in SNORT Alerts and Interfaces:
I think I understand. But how does that explain the alerts? The alerts happened on the LAN interface. It shows the the source as coming from the GUEST networking to an address in the LAN network.
You said the Guest network was a VLAN. I am assuming it is a VLAN defined on the LAN (meaning the LAN interface is the parent interface). Because Snort puts the interface(s) it is configured on in promiscuous mode, it will see all traffic on the physical NIC (so LAN and any VLANs where LAN is the parent).
-
@NogBadTheBad
I have a similar rule earlier in the thread. How does your's effectively differ? -
@bmeeks
Oh, that makes sense. So the traffic is seen but that doesn't mean that it actually made it into the LAN network?Since I am running VLAN's on the LAN interface, do I even need to run it on the GUEST VLAN?
-
@powerextreme said in SNORT Alerts and Interfaces:
@bmeeks
Oh, that makes sense. So the traffic is seen but that doesn't mean that it actually made it into the LAN network?Yes, that is correct.
Since I am running VLAN's on the LAN interface, do I even need to run it on the GUEST VLAN?
Probably not, since the LAN instance will see everything on that physical NIC anyway. And any instance of Snort you can not run frees up RAM and CPU for other things.
-
So given this configuration, is there a recommended way for me to get alerts on a packet that actually made it through from the GUEST LAN(VLAN) to the LAN?
It seems like the one's I am getting are false alarms.
-
@powerextreme said in SNORT Alerts and Interfaces:
So given this configuration, is there a recommended way for me to get alerts on a packet that actually made it through from the GUEST LAN(VLAN) to the LAN?
It seems like the one's I am getting are false alarms.
No, the only way would be to truly put the Guest and LAN networks on separate physical NICs.
-
@powerextreme said in SNORT Alerts and Interfaces:
@NogBadTheBad
I have a similar rule earlier in the thread. How does your's effectively differ?You didn't post the whole picture with the pass sections.
Why just not log the blocks to a syslog server, I send my logs to the syslog server on my NAS.
Check out TCP port 7000:-
https://www.speedguide.net/port.php?port=7000
