Snort 2.9.6.2 pkg v3.1.2 not logging Alerts
-
OK, groundhog day. Been there done that, but I did it again because this is so fun.
I have now uninstalled Snort for the umpteenth time. This time verifying that it would delete settings on uninstall.
So, I uninstalled snort, checked for zombies, rebooted, checked for zombies, installed snort, checked for zombies, configured and started WAN, checked for processes and indeed the PIDs matched. Created LAN and OPT1 using same settings as WAN, then started each interface. PIDs were matching.
$ ps -ax |grep snort
62118 ?? S 0:00.00 sh -c ps -ax |grep snort 2>&1
62344 ?? S 0:00.00 grep snort
72185 ?? Ss 0:00.03 /usr/pbi/snort-amd64/bin/snort -R 42630 -D -q -l /var
75913 ?? Ss 0:00.01 /usr/local/bin/barnyard2 -r 42630 -f snort_42630_em1.Log file complained of corrupted WALDO. See attached file.
Created LAN and OPT1 using same settings as WAN, then started each interface. PIDs were matching.
Checked for zombies - can't be too careful with all the zombies here in Atlanta.
Forced update for patterns, WAN started on its own, not so for both LAN & OPT1. Waited several minutes and in the mean time checked logs and found references to soft restart for LAN & OPT1.
Started LAN & OPT manually. And…
$ ps -ax |grep snort
43616 ?? Ss 0:00.03 /usr/pbi/snort-amd64/bin/snort -R 42630 -D -q -l /var
48172 ?? Ss 0:00.00 /usr/local/bin/barnyard2 -r 42630 -f snort_42630_em0.
72185 ?? Ss 0:00.16 /usr/pbi/snort-amd64/bin/snort -R 42630 -D -q -l /var
75913 ?? Ss 0:00.02 /usr/local/bin/barnyard2 -r 42630 -f snort_42630_em1.
93276 ?? Ss 0:00.00 /usr/pbi/snort-amd64/bin/snort -R 42630 -D -q -l /var
94472 ?? Ss 0:00.00 /usr/local/bin/barnyard2 -r 42630 -f snort_42630_re0.
98519 ?? S 0:00.00 sh -c ps -ax |grep snort 2>&1
98849 ?? S 0:00.00 grep snortAt this point it seems rather obvious that there is a bug(s). Restart does not seem to be the correct way of handling starting after update. Why use START on WAN and RESTART on LAN & WAN?
WAN works but LAN & OPT1 don't.
Oh, btw, as you might have noticed now both LAN & OPT1 won't start after updates instead of just the OPT1.
So, unless you have anything to offer to the contrary, I will write this off as a buggy implementation and move on.
Thanks for all your time.
BAM
PS: Oh, for the love of ((^$#! Now the friggin interface is not logging alerts!
-
What memory setting are you using? Use "AC-BNFA-NQ" as the pattern matcher. Maybe you are running out of memory and it's causing the other interfaces to crash?
-
I had thought early on that it was memory problem and have been using AC-BNFA-NQ.
BAM
-
Here are a couple of observations:
It appears that I have (possibly) solved the restart problem. It relates to how the 2nd & 3rd interfaces are added. If I click on the top most + button to create the interfaces instead of the one at the end of the WAN line - I see no SOFT RESTART on update but rather a START. More importantly the interfaces continue to run without intervention.
Logging fails if WAN IP rep is enabled. Resumes if it is disabled.
BAM
-
Did you enable IP rep on all interfaces? It should only be enabled on the WAN interface. Unless I am reading your last post incorrectly.
-
Logging was a separate issue from the interfaces failing. But yes I had enabled it on all interfaces.
I have reenabled it on WAN only and for the moment it appears to be working.
Thanks for the tip!
Where did this info come from, experience or is there somewhere you could point to with useful tidbits like this? The help link on the config page comes up empty.
BAM
-
btw did you do a fresh install of your pfSense and restored your config? Might have saved you some time, if not…
-
I did, but I had problems with the process. The MB had some quirks that made it difficult to get it to recognize the thumb drives for the install which took multiple tries before I had success.
Or… too much espresso.
I restored only some of the config and manually recreated the rest.
This was somewhat ok because I couldn't tell what the root problem was before embarking on the reinstall process and I couldn't be sure that it wouldn't preserve the garbage after restoration. So I took a conservative route and restored only the more PIA things.
BAM
-
Here are a couple of observations:
It appears that I have (possibly) solved the restart problem. It relates to how the 2nd & 3rd interfaces are added. If I click on the top most + button to create the interfaces instead of the one at the end of the WAN line - I see no SOFT RESTART on update but rather a START. More importantly the interfaces continue to run without intervention.
Logging fails if WAN IP rep is enabled. Resumes if it is disabled.
BAM
Thanks! This may be the key observation. I need to look further into the new code added to support the + button at the right end of each interface line. That button is supposed to "clone" the interface onto a new available physical interface but then change the UUID and directory paths. Perhaps there is a subtle bug living in that code. It is new with either this 3.1.2 version or it came out with 3.1.1 (don't remember at the moment while I'm typing this).
The + button at the upper right top row creates a totally new interface from scratch (no clone basis). The new + button to the right of each configured interface line is meant to behave like the same buttons in the firewall rules GUI for "…create a new rule based on this one...", except in the case of Snort it creates a new interface based on the current one. Enabled rule categories, preprocessor settings and other stuff are supposed to all get copied over and just the UUID and interface name are changed (also resets HOME_NET, EXTERNAL_NET and PASS LISTS to "default" for the cloned interface).
I tested this before deployment, but may not have tested in enough. Give me a few more days to finish up some Suricata work, and then I will examine this code in detail.
Bill
-
Here are a couple of observations:
It appears that I have (possibly) solved the restart problem. It relates to how the 2nd & 3rd interfaces are added. If I click on the top most + button to create the interfaces instead of the one at the end of the WAN line - I see no SOFT RESTART on update but rather a START. More importantly the interfaces continue to run without intervention.
Logging fails if WAN IP rep is enabled. Resumes if it is disabled.
BAM
UPDATE
Your observation above about the problem being related to exactly which icon on the INTERFACES tab was used to create new interfaces was on target. There is a bug in that code. It forgets to create a new UUID for the cloned interface when you use the + icons beside each interface line (the one whose tooltip will say something similar to "…create a new interface based on this one..."). The same bug exists in the Suricata package as well since those two share a lot of GUI code. I fixed it in Suricata and it will be included in the update currently under review.For Snort, I want to take a week or so and port over some of the new Suricata GUI features, and during that time I will fix this bug as well.
In the meantime, as a workaround, do not use the + icons at the right of each interface line. This means "cloning" an interface should not be used until the next Snort update is released.
Sorry about the bug, but thank you for persisting and finding the key clue. It escaped my VM testing because in my VMs the interfaces (WAN vs. LAN) had different NIC types and thus even when they shared a UUID it still worked. That would not be true in machines with multiple NICs of the same type.
Bill
-
Bill,
Thanks for the hard work.
BAM
-
Bill,
Thanks for the hard work.
BAM
If your configuration is still muddled up and giving you problems, send me a PM and I will work with you offline to get it fixed. Essentially what was happening to you is the Snort PHP code was getting confused by the duplicate UUIDs for different interfaces and wound up trying to "start" the wrong one (one that is already started). That's why one of your interfaces was giving a SOFT RESTART notice. Its UUID matched one of your earlier configured interfaces (most likely the one it was cloned from). Snort uses that UUID to differentiate interface instances.
Bill
