Snort 2.9.6.2 pkg v3.1.2 not logging Alerts
-
Ok, now after actually killing barnyard, stopping snort and then starting snort like you said (/usr/local/etc/rc.d/snort.sh), I do get this:
$ ps -ax |grep snort
17420 ?? Ss 0:00.08 /usr/pbi/snort-amd64/bin/snort -R 53598 -D -q -l /var
30028 ?? Ss 0:00.10 /usr/pbi/snort-amd64/bin/snort -R 52403 -D -q -l /var
45098 ?? S 0:00.00 sh -c ps -ax |grep snort 2>&1
45574 ?? S 0:00.00 grep snortBut on the status page OPT1 is not running, nor is barnyard on any of the interfaces.
Clicking on the OPT1 Snort icon to start the interface results in a correct start and also for the previously stopped barnyard2 service for OPT1 only.
After manually starting barnyard on the other twoi interfaces:
$ ps -ax |grep snort
17420 ?? Ss 0:00.12 /usr/pbi/snort-amd64/bin/snort -R 53598 -D -q -l /var
30028 ?? Ss 0:00.18 /usr/pbi/snort-amd64/bin/snort -R 52403 -D -q -l /var
44352 ?? Ss 0:00.00 /usr/local/bin/barnyard2 -r 52403 -f snort_52403_em1.
66818 ?? S 0:00.00 sh -c ps -ax |grep snort 2>&1
67147 ?? S 0:00.00 grep snort
92410 ?? Ss 0:00.00 /usr/local/bin/barnyard2 -r 53598 -f snort_53598_em0.
95130 ?? Ss 0:00.01 /usr/pbi/snort-amd64/bin/snort -R 53598 -D -q -l /var
98270 ?? Ss 0:00.01 /usr/local/bin/barnyard2 -r 53598 -f snort_53598_re0.BAM
-
This is puzzling. I'm trying to think of possible causes. Here is what you should generally see, a pair of matching Snort and Barnyard2 processes for each enabled interface:
9811 ?? Ss 4:27.56 /usr/local/bin/barnyard2 -r 59991 -f snort_59991_em0. 15888 ?? SNs 2:19.38 /usr/pbi/snort-amd64/bin/snort -R 59991 -D -q -l /var 20434 ?? SNs 0:05.51 /usr/pbi/snort-amd64/bin/snort -R 5104 -D -q -l /var/ 23865 ?? SNs 5:57.22 /usr/local/bin/barnyard2 -r 5104 -f snort_5104_em2.u2 29040 ?? SNs 6:41.15 /usr/local/bin/barnyard2 -r 61640 -f snort_61640_em1. 29640 ?? SNs 6:23.39 /usr/pbi/snort-amd64/bin/snort -R 61640 -D -q -l /varNotice above the following number pairs: 59991, 5104 and 61640. Those are the UUIDs that Snort generates to uniquely identify each interface. So in the example above from my firewall, you see three pairs of identical UUIDs showing I have Snort and Barnyard2 running on three interfaces. So something like the above is what you expect to see (although obviously your UUID numbers may differ).
Go into the GUI for Snort and click the "e" edit icon beside any interface. On the page that opens, just scroll to the bottom and click SAVE. That will generate a new snort.sh script for all interfaces. This will make sure that file is good.
One other thing just popped in my mind – is this a NanoBSD install or a full install? Also, did you by chance alter the NIC cards in the box or otherwise edit the interfaces? Just wondering because your first messages about a missing directory indicate a fundamental configuration change somewhere. Remember what I said the UUIDs were for: uniquely identifying Snort interfaces. What happened to the interface with UUID 45093? When you did the "partial restore" you mentioned, it's possible that brought in some old interface data such that now the Snort configuration is inconsistent with reality on your box.
I know you might now want to hear this, but your best chance for a fix is to remove Snort and its current configuration completely. You do this by going to GLOBAL SETTINGS and unchecking the box to "save settings when removing Snort". This will wipe the current Snort config when you delete the package on the System…Packages...Installed Packages menu. You could run through the screens and jot down any particular settings you want back in the event you deviated from the defaults. If you do indeed have a muddled config for Snort, then each time you remove and reinstall the package it will be picking up that same muddled config unless you uncheck that box and start from scratch.
Bill
-
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
