snort exits and doesnt restart after daily ruleset update
-
OK kinda remember why I had created two distinct interfaces in Snort, one for each VLAN's... and also why I see so many alerts in the logs...
The physical interface (LAN) is the parent of 3 VLAN's:
-VLAN_LAN
-VLAN_SEG
-VLAN_DMZVLAN_DMZ needs to be EXCLUDED from snort (and pfblocker and firewall, etc etc) because it is used for work laptop, etc....
Now having snort run on the parent interface, traffic going to/from DMZ is captured by snort which causes massive issues....
Question: is there a way to run snort on parent interface but EXCLUDE a VLAN?
-
@pftdm007
Create an alias named "Suricata_Trusted" or whatever, with IPs to exclude. In Suricata create a Pass List containing that alias. On the LAN interface set Pass List to that pass last. Restart Suricata on that interface (necessary when changing the alias) -
"DMZ" has subnet 192.168.2.0
I already have an alias to whitelist specific IP's from snort, and it is already included in the interface settings.
I take that the direction traffic travels for the Pass List IP's doesnt matter like for FW rules (source - destination).
If true, then adding the DMZ subnet to the pass list is kinda pointless because isn't snort supposed to whitelist local networks and subnets anyway?
I need to make incoming AND outgoing traffic on DMZ totally transparent from snort. Something like this FW rule:
Thats why I had created snort interfaces for the other VLAN's but NOT for DMZ.......
-
@pftdm007 Yeah my mistake. Adding rules to the suppress list by DMZ IP would take a while to accumulate. Not sure if there's a better way to do it.
Can you put in another NIC and make that DMZ? To separate them?
If they were all on the same interface before then DMZ should have been getting scanned before anyway, per the above discussion...
-
@steveits said in snort exits and doesnt restart after daily ruleset update:
should have been getting scanned before anyway, per the above discussion..
Yeah thats what I expected but if I remember well last year I ended up deciding to split the interface in VLAN's in Snort exactly because snort was grabbing and blocking for DMZ (which is poerfectlty normal).... I even opened up a thread for this and unless I misinterpreted Bill Meeks, creating separate interfaces for the VLAN's was more or less the solution.
I could always reconfigure hardware but that'd mean getting another Unifi AP and hopefully I have some PCIE slots left in that machine.... Short of going down that road, would there be a software way of doing this?
-
@pftdm007 said in snort exits and doesnt restart after daily ruleset update:
@steveits said in snort exits and doesnt restart after daily ruleset update:
should have been getting scanned before anyway, per the above discussion..
Yeah thats what I expected but if I remember well last year I ended up deciding to split the interface in VLAN's in Snort exactly because snort was grabbing and blocking for DMZ (which is poerfectlty normal).... I even opened up a thread for this and unless I misinterpreted Bill Meeks, creating separate interfaces for the VLAN's was more or less the solution.
I could always reconfigure hardware but that'd mean getting another Unifi AP and hopefully I have some PCIE slots left in that machine.... Short of going down that road, would there be a software way of doing this?
I will look into this further and see if its possible to separate the VLANs (at least in Legacy Blocking Mode). I know it won't work well with Inline IPS Mode. I have some PHP loose ends to tidy up in both packages (Snort and Suricata).
As I think the Netgate team is seeing with the recent release of 23.01, the snapshot/development testing population appears to be pretty small. As a result, lots of bugs don't surface until you post the release and then everyone and his brother installs it. Then the "rest of the bugs" start appearing. I'm seeing that in the two IDS/IPS packages. It is just so difficult to mimic every possible environment out there when doing pre-release testing.
-
@bmeeks said in snort exits and doesnt restart after daily ruleset update:
It is just so difficult to mimic every possible environment out there when doing pre-release testing.
No problem, its my pleasure to report these issues to make the packages better for everyone.
-
Hello guys,
its still happening. Two days in a row, I have to manually restart snort in the morning because it doesnt restart after its daily ruleset update.
Could it be only a glitch in the webUI?
-
@pftdm007 said in snort exits and doesnt restart after daily ruleset update:
Hello guys,
its still happening. Two days in a row, I have to manually restart snort in the morning because it doesnt restart after its daily ruleset update.
Could it be only a glitch in the webUI?
It's possible that it is a GUI glitch or intermittent bug. I saw similar behavior exactly once when testing Suricata recently, but was never able to reproduce it. What I saw was a delayed "delete" of the PID file. Snort may be experiencing a similar thing.
My bet is Snort may actually be running when it shows as down. The GUI depends on seeing the PID file in
/var/run/to determine if Snort is running. If that file is not present, it thinks Snort is not running even though it may actually be. Check from a shell prompt to see if Snort is actually running next time, or check now and you may see duplicate Snort instances running on tthe same interface:ps -ax | grep snortYou should see only one Snort process per configured interface.
-
The issue re-occured again but this time I ran the CLI command which gave:
9364 - SNs 0:08.14 /usr/local/bin/snort -R _49826 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.20049826 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 49826 -c /usr/local/etc/snort/snort_49826_em4.200/snort.conf -i em4.200 42037 - S 0:00.00 sh -c ps -ax | grep snort 2>&1 42270 - S 0:00.00 grep snort 81192 - SNs 4:17.87 /usr/local/bin/snort -R _57388 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.10057388 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 57388 -c /usr/local/etc/snort/snort_57388_em4.100/snort.conf -i em4.100I take that snort is indeed running on em4.100 and em4.200 ???
-
@pftdm007 said in snort exits and doesnt restart after daily ruleset update:
The issue re-occured again but this time I ran the CLI command which gave:
9364 - SNs 0:08.14 /usr/local/bin/snort -R _49826 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.20049826 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 49826 -c /usr/local/etc/snort/snort_49826_em4.200/snort.conf -i em4.200 42037 - S 0:00.00 sh -c ps -ax | grep snort 2>&1 42270 - S 0:00.00 grep snort 81192 - SNs 4:17.87 /usr/local/bin/snort -R _57388 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.10057388 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 57388 -c /usr/local/etc/snort/snort_57388_em4.100/snort.conf -i em4.100I take that snort is indeed running on em4.100 and em4.200 ???
Yes, that means Snort is actually running on both interfaces.
I need to deep-dive into the PHP code a bit to check out the behavior. It is possible that with recent changes I inadvertently introduced a bug with querying the running status of the Snort processes with the code on the INTERFACES GUI tab.
I will fire up my virtual machine and do some testing. I see that earlier in the thread you said you are running pfSense 2.6.0, so I will check there first.
