snort exits and doesnt restart after daily ruleset update

pftdm007

@SteveITS You may have seen my reply for my other thread of VPS connectivity issue: I dont understand why shutting down Snort on VLAN's and activating the same ruleset on the parent physical iface apparently made Snort block more IP's.....

Before when I was running snort on the VLAN ifaces, I saw a handful of IP's being blocked under each of the VLAN ifaces... But now that I run snort on the parent physical iface, just ion 2 days there's already well over 50 blocked IP's and the alert tabs are busy as heck...

for the rcord, the snort iface was cloned from my former "VLAN_LAN" iface so the ruleset and settings should be essentially the same. I visually confirmed it was the case... Just asking to better understand but at this moment I consider my setup to be even better than before and working well.

SteveITS

@pftdm007 The alerts log will show what IP is blocked. Possibly it's new devices, meaning the LAN PCs? If you didn't want those scanned you could add them to a pass list.

With two instances running on essentially the same interface (two VLANs) I'm not sure how that would handle the logging, so maybe something wasn't being logged properly? Bill may have insight there.

pftdm007

@steveits The IP's in the alerts tab are from anywhere in the world, not my LAN clients. This is as expected, I was simply asking because of the sheer volume I see now that I have reconfigured the snort interfaces differently....

pftdm007

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_DMZ

VLAN_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?

SteveITS

@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)

pftdm007

@steveits

"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.......

SteveITS

@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...

pftdm007

@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?

bmeeks

@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.

pftdm007

@bmeeks

@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.

pftdm007

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?

bmeeks

@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 snort

You should see only one Snort process per configured interface.

pftdm007

@bmeeks

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.100

I take that snort is indeed running on em4.100 and em4.200 ???

bmeeks

@pftdm007 said in snort exits and doesnt restart after daily ruleset update:

@bmeeks

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.100

I 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.