If you are having Barnyard2 troubles with the last Snort update – try this
-
Thanks so much Bill!
I have access to several snort systems that I can run attacks against to generate a ton of events to test against. Just say the word and I am happy to help debug, etc.
Greg
-
I think your explanation is right on the mark with what I see. I do have some overlap rules on my 2 sensors (LAN and WAN), and only 1 will run continually, usually the first one I start. Thanks again for your work on this.
-
Bill,
I would like to contribute the following to this error:
Error also happens in the event table –
Apr 23 20:03:56 labkord-lxfw01 barnyard2[47108]: FATAL ERROR: database mysql_error: Duplicate entry '1-11' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 11, 289, '2014-04-23 20:03:55');]
Apr 23 20:03:56 labkord-lxfw01 barnyard2[69591]: FATAL ERROR: database mysql_error: Duplicate entry '1-11' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 11, 289, '2014-04-23 20:03:55');]
Apr 23 20:05:15 labkord-lxfw01 barnyard2[92662]: FATAL ERROR: database mysql_error: Duplicate entry '1-13' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 13, 301, '2014-04-23 20:05:15');]As we all know the sig_reference table too:
Apr 23 09:28:00 labkord-lxfw01 barnyard2[20704]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 09:35:30 labkord-lxfw01 barnyard2[22589]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 10:16:35 labkord-lxfw01 barnyard2[62763]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 10:28:06 labkord-lxfw01 barnyard2[40004]: FATAL ERROR: database mysql_error: Duplicate entry '10274-2' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('6892','10274','2');] -
Bill,
I would like to contribute the following to this error:
Error also happens in the event table –
Apr 23 20:03:56 labkord-lxfw01 barnyard2[47108]: FATAL ERROR: database mysql_error: Duplicate entry '1-11' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 11, 289, '2014-04-23 20:03:55');]
Apr 23 20:03:56 labkord-lxfw01 barnyard2[69591]: FATAL ERROR: database mysql_error: Duplicate entry '1-11' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 11, 289, '2014-04-23 20:03:55');]
Apr 23 20:05:15 labkord-lxfw01 barnyard2[92662]: FATAL ERROR: database mysql_error: Duplicate entry '1-13' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 13, 301, '2014-04-23 20:05:15');]As we all know the sig_reference table too:
Apr 23 09:28:00 labkord-lxfw01 barnyard2[20704]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 09:35:30 labkord-lxfw01 barnyard2[22589]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 10:16:35 labkord-lxfw01 barnyard2[62763]: FATAL ERROR: database mysql_error: Duplicate entry '10274-3' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('12401','10274','3');]
Apr 23 10:28:06 labkord-lxfw01 barnyard2[40004]: FATAL ERROR: database mysql_error: Duplicate entry '10274-2' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('6892','10274','2');]Thanks for the additional information. I'm pretty sure this is a Barnyard2 binary problem as outlined above. The Barnyard2 maintainers are going to have to look at their code IMHO. In the meantime, to help users on pfSense work around the problem, I've submitted some patched code as a Pull Request on Github. It is awaiting approval and merging by the pfSense Core Team guys. It has been posted for a while, and hopefully they can soon get some time to review and approve.
Bill
-
Would be interested to know if there's any update on this. I've followed all the instructions here and yet I'm still having the problem. Thought it was working after I updated snort and pfsense but the problem returned after an hour.
-
bill's patch has been added to snort already… barnyard2 needs to be updated but that is out of scope from the pfsense project.. The creators of barnyard2 would have to fix their code... When I run into the problem, I purge a few tables; start barnyard2 and everything is good again.
-
Would be interested to know if there's any update on this. I've followed all the instructions here and yet I'm still having the problem. Thought it was working after I updated snort and pfsense but the problem returned after an hour.
Go to the BARNYARD tab and down in the MySQL DB section on all your Snort interfaces (except one) and check the box to disable updates to the signature reference table. Leave this box unchecked on only a single Barnyard2 interface (typically the one that registers the most alerts).
The problem is with Barnyard2 itself and concurrent updates to the same DB table from multiple processes. The Barnyard2 guys, in my opinion, broke their code in the version 2.1.3 update a while back. The Snort and Suricata packages on pfSense use this updated version since the FreeBSD ports tree was also updated.
Bill
-
The option is already checked on both interfaces. Is it significant that I'm only getting the duplicate entry error for the 'event' table, and not 'sig_reference?'
-
The option is already checked on both interfaces. Is it significant that I'm only getting the duplicate entry error for the 'event' table, and not 'sig_reference?'
Do you by chance have the same rules running on more than one interface, and are the Snort instances each alerting on the same traffic? In other words, duplicate rules on WAN and LAN and each Snort instance alerts on the same traffic.
The Barnyard2 guys made a few "adjustments" to the MySQL DB code in their last update, and those adjustments seem to have caused a race condition with data inserts and some tables.
I was able to fix this by running the scripts linked earlier in this thread to clean up the tables, and then running only one BY2 interface with the checkbox not checked.
Bill
-
Nope, still happening.
Jun 30 11:00:17 barnyard2[33829]: database: Closing connection to database "snorby"
Jun 30 11:00:17 barnyard2[33829]: Barnyard2 exiting
Jun 30 11:00:17 barnyard2[33829]: FATAL ERROR: database mysql_error: Duplicate entry '5-20' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (5, 20, 18861, '2014-06-30 11:00:15');]
Jun 30 11:00:16 snort[57013]: [1:2003315:3] ET P2P Edonkey Search Reply [Classification: Potential Corporate Privacy Violation] [Priority: 1] {UDP} 77.80.253.67:27001 -> 192.168.1.102:27960
Jun 30 11:00:16 snort[57013]: [1:2003315:3] ET P2P Edonkey Search Reply [Classification: Potential Corporate Privacy Violation] [Priority: 1] {UDP} 77.80.253.67:27001 -> 192.168.1.102:27960This rule is ONLY present on LAN. Ironically it's a false positive detecting a Quake Live connection as Edonkey :P
-
The plot thickens… my snorby instance is still receiving alerts from the LAN interface despite the barnyard2 process for LAN being marked as stopped in the GUI.
-
Im seeing this rear its head again (im using Suricata), even thought I have the box checked for both sensors that are reporting…
-
Im seeing this rear its head again (im using Suricata), even thought I have the box checked for both sensors that are reporting…
Oops.. It's the event table this time as stated above.. just started happening with the last update..
-
gscasny, are you using this on Security Onion?
http://blog.securityonion.net/2014/06/new-barnyard2-nsm-rule-update-and.html
"You may have noticed previously that when barnyard2 started up, it would consume a large amount of CPU (on both the sensor and the server) for a while (more than a minute in some cases) while it updated Snorby's reference table. Multiply this by several barnyard instances per interface and several interfaces per physical sensor and you now have multiple instances fighting each other for scarce CPU resources.
To alleviate this, the barnyard2 folks introduced a new option called disable_signature_reference_table that allows you to disable the reference table update on all sensors, leaving just one barnyard2 instance on the server itself to update Snorby's reference table, avoiding the duplication of effort. I packaged the latest version of barnyard2 (version 2.1.13 Build 333) which contains this option and also updated the NSM scripts to add the new option to all barnyard2.conf files on all sensors. rule-update has been modified such that right after the master downloads new rules from the Internet, it will use barnyard2 to update Snorby's reference table. Finally, since we're now forcing the server to use barnyard2 to update Snorby's reference table, I updated the securityonion-server metapackage to require securityonion-barnyard2 as a dependency."
-
Im running snorby on Security Onion, but Suricata/Barnyard2 on pfsense. I see that behavior on pfsense with Barnyard2 (the intense CPU and long startup times)
-
And the issue I see now is with the event table, not the sig_references table. I have 2 sensors (LAN/WAN) and am not running the same rules on each:
barnyard2[58758]: FATAL ERROR: database mysql_error: Duplicate entry '2-802153' for key 'PRIMARY' SQL=[INSERT INTO event (sid,cid,signature,timestamp) VALUES (2, 802153, 62634, '2014-06-30 15:47:27');]
-
gscasny - I've just solved mine, so here's what was happening in case it's the same issue for you.
Turns out I had some kind of ghost barnyard2 process running in the background. The one that was visible in the PFSense GUI kept failing because this invisible intruder was reading from the same unified2 file and writing the entries to the snorby instance first, so when the visible by2 process tried to do it, the entry was already there. I shut down pfsense, deleted the entry that had caused the fatal error, and started PFSense again, and it's been running for about 2 hours so far without dying. If it fails overnight, I'll put another post in here to say so. -
You could try to
pgrep barnyard or ps aux | grep barnyard
and see how many processes are running. And then "kill (pid) (duplicate one)
-
gscasny - I've just solved mine, so here's what was happening in case it's the same issue for you.
Turns out I had some kind of ghost barnyard2 process running in the background. The one that was visible in the PFSense GUI kept failing because this invisible intruder was reading from the same unified2 file and writing the entries to the snorby instance first, so when the visible by2 process tried to do it, the entry was already there. I shut down pfsense, deleted the entry that had caused the fatal error, and started PFSense again, and it's been running for about 2 hours so far without dying. If it fails overnight, I'll put another post in here to say so.Right on the money.. that was it.. I feel stupid :) I should have checked that.. Thanks so much for putting my brain back on track!! I appreciate it! That's why my snorby logs kept populating when BY2 "died".. it had a ghost :)
Greg
-
You could try to
pgrep barnyard or ps aux | grep barnyard
and see how many processes are running. And then "kill (pid) (duplicate one)
Note to anyone trying this in future - if you're doing it locally, this will be fine, but in a remote ssh, you should probably use "ps auxw" - just using "aux" truncates the output to the screen width and if that means the word "barnyard" wouldn't be displayed, "ps aux" will get nothing.
