Barnyard not starting after Snort rules update
-
With the new version of Snort (Snort 2.9.4.1 pkg v. 2.5.4) Barnyard does not start automaticly after updating.
Strange thing is it worked when only the ET rules were updated. As soon as the Snort rules came back for 2.9.4.1 Barnyard did not start.I can start it manually.
Oh, and no messages appear in the log.
-
With the new version of Snort (Snort 2.9.4.1 pkg v. 2.5.4) Barnyard does not start automaticly after updating.
Strange thing is it worked when only the ET rules were updated. As soon as the Snort rules came back for 2.9.4.1 Barnyard did not start.I can start it manually.
Oh, and no messages appear in the log.
I also run Barnyard2 with my Snort, but it has behaved fine. The only difference is that I have a paid Snort VRt oinkcode and thus have used the 2.9.4.1 rules from the beginning. I did not have the 30-day blackout period. I don't know what could be going on exactly. My first guess is maybe the sid-msg.map and/or gen-msg.map files are not right for the interface. Not sure how they could get out of whack, but it's a long-shot guess…
Are you positive that Barnyard2 has actually stopped? What I mean is that there were times in the past where the GUI status icon on teh Snort Interfaces tab would be incorrect. I thought Ermal fixed that a long time back, though. Have you tried manually listing the running processes from the console prompt to make sure the Barnyard2 process is truly dead?
Bill
-
I can confirm that it happened a few times. Today I have this in my logs:
Apr 9 12:03:27 php: : Snort MD5 Attempts: 1 Apr 9 12:03:27 php: : Snort rules are up to date... Apr 9 12:03:27 php: : There is a new set of Emergingthreats rules posted. Downloading... Apr 9 12:03:31 php: : Emergingthreats rules file update downloaded succsesfully Apr 9 12:03:32 php: : Updating rules configuration for: WAN ... Apr 9 12:03:40 php: : Checking for and disabling any rules dependent upon disabled preprocessors for WAN... Apr 9 12:03:47 php: : Resolving and auto-enabling flowbit required rules for WAN... Apr 9 12:03:56 SnortStartup[56699]: Snort SOFT START For WAN(54477_em0)... Apr 9 12:03:58 barnyard2[24844]: database: Closing connection to database "snort" Apr 9 12:03:58 barnyard2[24844]: =============================================================================== Apr 9 12:03:58 barnyard2[24844]: Record Totals: Apr 9 12:03:58 barnyard2[24844]: Records: 2 Apr 9 12:03:58 barnyard2[24844]: Events: 1 (50.000%) Apr 9 12:03:58 barnyard2[24844]: Packets: 1 (50.000%) Apr 9 12:03:58 barnyard2[24844]: Unknown: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: =============================================================================== Apr 9 12:03:58 barnyard2[24844]: Packet breakdown by protocol (includes rebuilt packets): Apr 9 12:03:58 barnyard2[24844]: ETH: 1 (100.000%) Apr 9 12:03:58 barnyard2[24844]: ETHdisc: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: VLAN: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPV6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IP6 EXT: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IP6opts: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IP6disc: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IP4: 1 (100.000%) Apr 9 12:03:58 barnyard2[24844]: IP4disc: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: TCP 6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: UDP 6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ICMP6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ICMP-IP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: TCP: 1 (100.000%) Apr 9 12:03:58 barnyard2[24844]: UDP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ICMP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: TCPdisc: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: UDPdisc: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ICMPdis: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: FRAG: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: FRAG 6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ARP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: EAPOL: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: ETHLOOP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPX: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPv4/IPv4: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPv4/IPv6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPv6/IPv4: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: IPv6/IPv6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE ETH: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE VLAN: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE IPv4: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE IPv6: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE IP6 E: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE PPTP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE ARP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE IPX: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: GRE LOOP: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: MPLS: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: OTHER: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: DISCARD: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: InvChkSum: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: S5 G 1: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: S5 G 2: 0 (0.000%) Apr 9 12:03:58 barnyard2[24844]: Total: 1 Apr 9 12:03:58 barnyard2[24844]: =============================================================================== Apr 9 12:04:04 snort[22401]: SMTP reload: Changing the file_depth requires a restart. Apr 9 12:04:05 kernel: em0: promiscuous mode disabled Apr 9 12:04:18 php: : Snort has restarted with your new set of rules... Apr 9 12:04:18 php: : The Rules update has finished... Apr 9 12:04:35 kernel: em0: promiscuous mode enabled
As you can see barnyard2 did not restart. It does not happen every time, and I am investigating it.
-
For what it's worth, I saw this today for the first time on my own box. I have Snort running on three interfaces. Barnyard2 failed to restart on two of them, but started on the third after the rule update.
A bit of a mystery to be investigated…
-
I also have three, sometimes one gets started and the other two not.
The one that gets started has fewer categories selected as the one the I can't even start anymore with many selected categories.
Looks like a memory problem? -
I also have three, sometimes one gets started and the other two not.
The one that gets started has fewer categories selected as the one the I can't even start anymore with many selected categories.
Looks like a memory problem?Not necessarily memory. Could be a missing preprocessor dependency. I typically run with all preprocessors enabled except these three: Sensitive-Data, Modbus and DNP-3.
-
I do exactly the same. All preprocessors enabled except the three you mentioned. On all three interfaces.
-
I am seeing this on my production box. Again today, two of the three Barnyard2 processes were not restarted when I checked. Will dig into it and see if I can find what's up. Hopefully it's something simple.
Bill
-
Hmm, I also get only 1 started and 2 not…
Maybe it just stops after the 1st Barnyard is started? -
Well, no problems with Barnyard2 restarts on all interfaces with the last rule updates. Seems random maybe ???
-
Mine didn't start at all this moring, one interface I can't even start manually…
Maybe it's the Waldo file? If I get it correctly, during the updates Snort/Barnyard stops and afterwards, when Snort/Barnyard starts again anything inside the Waldo file is send to the SQL server.
Also getting this error:
database: [SynchronizeEventId()]: Problems executing [SELECT MAX(cid) FROM icmphdr WHERE sid='11';]I am going to empty all Barnyard tables and see what will happen.
Edit: After rebuilding the SQL tables, the biggest Snort interface won't start Barnyard, same database error as before.
-
The database error is of course a Barnyard2 thing. I think that is not uncommon when it sort of crashes (Barnyard, that is). The version of Barnyard2 was bumped to 2.12 back when the Snort binary was bumped to 2.9.4.1 That was back when the 2.5.4 version of the Snort package was released toward the end of March.
Did your Barnyard2 troubles start just this last week, or have they existed since late March? Trying to see if they are related to the Barnyard2 version bump or to the latest round of GUI changes pushed out on April 9.
Bill
-
In fixing another bug in the Rules Update code Saturday afternoon, I stumbled upon a copy-paste error that might be responsible for the sporadic failures of Barnyard2 to restart following an automatic rules update. The error caused a filename to be written incorrectly. Let's see if this helps the Barnyard2 problem.
To pick up this latest update, go the Installed Packages tab and click either the pkg or xml icon to reinstall the Snort GUI components. The package version number was not incremented this time, so it will still show 2.5.5. But if you reinstall the GUI components, you will pick up the corrected code.
Bill
-
Did a "user" update from Snort 2.9.4.1 pkg v. 2.5.4 to v. 2.5.5, (works perfectly!)
After the package installation updated the rules and started the sensors one by one.One sensor still didn't work, the Barnyard MySQL settings were gone(?!).
Filled them in again and no everything is running again!Don't know why and how the settings were missing, but I do know I never changed them and they worked before, at least until the Snort registered rules updated, after that it stopped somehow.
The settings on the other two interfaces are still there.I will let you know what happens after the automatic update and after some events.
Edit: Of course I also checked if all other settings were still there: Yes they were.
-
All events are now listed twice. Happens to each interface.
Cleared all lists, cleared blocked list, still all events are listed twice. -
All events are now listed twice. Happens to each interface.
Cleared all lists, cleared blocked list, still all events are listed twice.Twice in the System Logs or twice in your MySQL database? If the system logs, that's a normal quirk of pfSense. If your database, then I would surmise you have two separate instances of Barnyard2 reading the same unified2 log file. In other words, that would mean two instances of Barnyard2 going against the same Snort interface. I would shutdown all your Snort interfaces, then do a "pgrep" for any running Barnyard2 processes and kill those. Then start everything up again.
By the way, on the Snort Interfaces tab, there is pretty much never a reason to use the start/stop icon next to Barnyard in the table. Starting and stopping Snort using the icon beside the Snort entry in the table will automatically start/stop Barnyard2 as well (if enabled).
Bill
-
Some events were listed twice in both the System log and the MySQL database, but they are valid. Just ignore my previous message.
Yes, I always use only the Snort Start/Stop button.
FYI: Just updated to 2.0.3 and Snort is also installed flawlessly!Think you solved the Barnyard not starting issue. Thanks for all your effort!
If you ever need help testing something let me know. -
Some events were listed twice in both the System log and the MySQL database, but they are valid. Just ignore my previous message.
Yes, I always use only the Snort Start/Stop button.
FYI: Just updated to 2.0.3 and Snort is also installed flawlessly!Think you solved the Barnyard not starting issue. Thanks for all your effort!
If you ever need help testing something let me know.My Barnyard2 restart problem also seems to be solved. At least the last rules update went off fine. I hope that file copy error I found and fixed over the weekend solved the Barnyard2 problem.
Bill