Snort 2.9.5.6 pkg v3.0.4 Update – Release notes and change log
-
Looks like some preprocessors are broken. ftp for example doesn't allow telnet commands (which as far as I can remember are needed for passive ftp), pop and imap have missing commands…
It's gonna take a while to get it sorted. If I disable the preprocessors and enable them through advanced passthrough will the settings get overwritten? Need to keep it running for a while to sort this out, which means settings must be kept through updates.
-
@jflsakfja:
Looks like some preprocessors are broken. ftp for example doesn't allow telnet commands (which as far as I can remember are needed for passive ftp), pop and imap have missing commands…
It's gonna take a while to get it sorted. If I disable the preprocessors and enable them through advanced passthrough will the settings get overwritten? Need to keep it running for a while to sort this out, which means settings must be kept through updates.
Anything you do in the Advanced Pass-Through box will hold. The contents of that box get written, verbatim, to the snort.conf file down toward the bottom of it. That is the purpose of the form parameter: to allow customizations. The text you type in the box will be stored in the firewall's config.xml file along with all the other Snort parameters.
By the way: I certainly don't consider myself an experienced Snort professional, so any input from more experienced users is always welcome. But just FYI, in looking through the README.imap and README.pop files included with the source code tarball, there is no mention of configurable commands for either of these two preprocessors.
Bill
-
Ah there you are! Found the error in snort's code.
const IMAPToken imap_known_cmds[] = { {"APPEND", 6, CMD_APPEND}, {"AUTHENTICATE", 12, CMD_AUTHENTICATE}, {"CAPABILITY", 10, CMD_CAPABILITY}, {"CHECK", 5, CMD_CHECK}, {"CLOSE", 5, CMD_CLOSE}, {"COMPARATOR", 10, CMD_COMPARATOR}, {"COMPRESS", 8, CMD_COMPRESS}, {"CONVERSIONS", 11, CMD_CONVERSIONS}, {"COPY", 4, CMD_COPY}, {"CREATE", 6, CMD_CREATE}, {"DELETE", 6, CMD_DELETE}, {"DELETEACL", 9, CMD_DELETEACL}, {"DONE", 4, CMD_DONE}, {"EXAMINE", 7, CMD_EXAMINE}, {"EXPUNGE", 7, CMD_EXPUNGE}, {"FETCH", 5, CMD_FETCH}, {"GETACL", 6, CMD_GETACL}, {"GETMETADATA", 11, CMD_GETMETADATA}, {"GETQUOTA", 8, CMD_GETQUOTA}, {"GETQUOTAROOT", 12, CMD_GETQUOTAROOT}, {"IDLE", 4, CMD_IDLE}, {"LIST", 4, CMD_LIST}, {"LISTRIGHTS", 10, CMD_LISTRIGHTS}, {"LOGIN", 5, CMD_LOGIN}, {"LOGOUT", 6, CMD_LOGOUT}, {"LSUB", 4, CMD_LSUB}, {"MYRIGHTS", 8, CMD_MYRIGHTS}, {"NOOP", 4, CMD_NOOP}, {"NOTIFY", 6, CMD_NOTIFY}, {"RENAME", 6, CMD_RENAME}, {"SEARCH", 6, CMD_SEARCH}, {"SELECT", 6, CMD_SELECT}, {"SETACL", 6, CMD_SETACL}, {"SETMETADATA", 11, CMD_SETMETADATA}, {"SETQUOTA", 8, CMD_SETQUOTA}, {"SORT", 4, CMD_SORT}, {"STARTTLS", 8, CMD_STARTTLS}, {"STATUS", 6, CMD_STATUS}, {"STORE", 5, CMD_STORE}, {"SUBSCRIBE", 9, CMD_SUBSCRIBE}, {"THREAD", 6, CMD_THREAD}, {"UID", 3, CMD_UID}, {"UNSELECT", 8, CMD_UNSELECT}, {"UNSUBSCRIBE", 11, CMD_UNSUBSCRIBE}, {"X", 1, CMD_X}, {NULL, 0, 0} }; const IMAPToken imap_resps[] = { {"CAPABILITY", 10, RESP_CAPABILITY}, {"LIST", 4, RESP_LIST}, {"LSUB", 4, RESP_LSUB}, {"STATUS", 6, RESP_STATUS}, {"SEARCH", 6, RESP_SEARCH}, {"FLAGS", 5, RESP_FLAGS}, {"EXISTS", 6, RESP_EXISTS}, {"RECENT", 6, RESP_RECENT}, {"EXPUNGE", 7, RESP_EXPUNGE}, {"FETCH", 5, RESP_FETCH}, {"BAD", 3, RESP_BAD}, {"BYE", 3, RESP_BYE}, {"NO", 2, RESP_NO}, {"OK", 2, RESP_OK}, {"PREAUTH", 7, RESP_PREAUTH}, {"ENVELOPE", 8, RESP_ENVELOPE}, {"UID", 3, RESP_UID}, {NULL, 0, 0} }
Looks like the imap commands are embedded into the preprocessor, and there's no way to add to those commands without recompiling snort. imap_known_cmds { enter_your commands_here } into the passthrough box doesn't work. On a not-so-detailed look reveals that indeed the ID command is what's firing up the alert, and is a valid command according to RFC2971.
That means the only 2 options are:
- contact upstream to implement the changes in the code. Since Cisco aquired snort, actually implementing the change has a 0.000000000000000000000000001% chance of actually getting implemented (this decade). The percentage increases exponentially if you plot for the next couple of decades as well. First results suggest that around the year 3498 it will have almost a 100% of getting implemented.
- implement the change when compiling for pfsense. Not familiar with the way snort is handled (package side) on pfsense, but I'll try and compile a list for the missing commands and post it. If it gets compiled into the code when packaging for pfsense then all is good.
-
@jflsakfja:
Ah there you are! Found the error in snort's code.
const IMAPToken imap_known_cmds[] = { {"APPEND", 6, CMD_APPEND}, {"AUTHENTICATE", 12, CMD_AUTHENTICATE}, {"CAPABILITY", 10, CMD_CAPABILITY}, {"CHECK", 5, CMD_CHECK}, {"CLOSE", 5, CMD_CLOSE}, {"COMPARATOR", 10, CMD_COMPARATOR}, {"COMPRESS", 8, CMD_COMPRESS}, {"CONVERSIONS", 11, CMD_CONVERSIONS}, {"COPY", 4, CMD_COPY}, {"CREATE", 6, CMD_CREATE}, {"DELETE", 6, CMD_DELETE}, {"DELETEACL", 9, CMD_DELETEACL}, {"DONE", 4, CMD_DONE}, {"EXAMINE", 7, CMD_EXAMINE}, {"EXPUNGE", 7, CMD_EXPUNGE}, {"FETCH", 5, CMD_FETCH}, {"GETACL", 6, CMD_GETACL}, {"GETMETADATA", 11, CMD_GETMETADATA}, {"GETQUOTA", 8, CMD_GETQUOTA}, {"GETQUOTAROOT", 12, CMD_GETQUOTAROOT}, {"IDLE", 4, CMD_IDLE}, {"LIST", 4, CMD_LIST}, {"LISTRIGHTS", 10, CMD_LISTRIGHTS}, {"LOGIN", 5, CMD_LOGIN}, {"LOGOUT", 6, CMD_LOGOUT}, {"LSUB", 4, CMD_LSUB}, {"MYRIGHTS", 8, CMD_MYRIGHTS}, {"NOOP", 4, CMD_NOOP}, {"NOTIFY", 6, CMD_NOTIFY}, {"RENAME", 6, CMD_RENAME}, {"SEARCH", 6, CMD_SEARCH}, {"SELECT", 6, CMD_SELECT}, {"SETACL", 6, CMD_SETACL}, {"SETMETADATA", 11, CMD_SETMETADATA}, {"SETQUOTA", 8, CMD_SETQUOTA}, {"SORT", 4, CMD_SORT}, {"STARTTLS", 8, CMD_STARTTLS}, {"STATUS", 6, CMD_STATUS}, {"STORE", 5, CMD_STORE}, {"SUBSCRIBE", 9, CMD_SUBSCRIBE}, {"THREAD", 6, CMD_THREAD}, {"UID", 3, CMD_UID}, {"UNSELECT", 8, CMD_UNSELECT}, {"UNSUBSCRIBE", 11, CMD_UNSUBSCRIBE}, {"X", 1, CMD_X}, {NULL, 0, 0} }; const IMAPToken imap_resps[] = { {"CAPABILITY", 10, RESP_CAPABILITY}, {"LIST", 4, RESP_LIST}, {"LSUB", 4, RESP_LSUB}, {"STATUS", 6, RESP_STATUS}, {"SEARCH", 6, RESP_SEARCH}, {"FLAGS", 5, RESP_FLAGS}, {"EXISTS", 6, RESP_EXISTS}, {"RECENT", 6, RESP_RECENT}, {"EXPUNGE", 7, RESP_EXPUNGE}, {"FETCH", 5, RESP_FETCH}, {"BAD", 3, RESP_BAD}, {"BYE", 3, RESP_BYE}, {"NO", 2, RESP_NO}, {"OK", 2, RESP_OK}, {"PREAUTH", 7, RESP_PREAUTH}, {"ENVELOPE", 8, RESP_ENVELOPE}, {"UID", 3, RESP_UID}, {NULL, 0, 0} }
Looks like the imap commands are embedded into the preprocessor, and there's no way to add to those commands without recompiling snort. imap_known_cmds { enter_your commands_here } into the passthrough box doesn't work. On a not-so-detailed look reveals that indeed the ID command is what's firing up the alert, and is a valid command according to RFC2971.
That means the only 2 options are:
- contact upstream to implement the changes in the code. Since Cisco aquired snort, actually implementing the change has a 0.000000000000000000000000001% chance of actually getting implemented (this decade). The percentage increases exponentially if you plot for the next couple of decades as well. First results suggest that around the year 3498 it will have almost a 100% of getting implemented.
- implement the change when compiling for pfsense. Not familiar with the way snort is handled (package side) on pfsense, but I'll try and compile a list for the missing commands and post it. If it gets compiled into the code when packaging for pfsense then all is good.
You could try posting this to the Snort Mailing List. I believe there is a link to it over at http://www.snort.org. Perhaps they would be willing to add a missing command to the source code. It is possible to add a patch to the pfSense compile, but over time those things can get messy if more and more of them accumulate. Then at some point trying to do a simple update fails because of numerous patches that may fail to apply. So while not totally saying "no", I will say the pfSense guys definitely prefer changes like this to go into the upstream port so there is minimal customization on the pfSense end. Right now only two customizations are done for pfSense: (1) altering the alert log to use CSV for the fields, and (2) incorporating the Spoink output plugin to facilitate blocking.
Bill
-
[quote] preprocessor imap: \ ports { 143 } \ memcap 1310700 \ qp_decode_depth 0 \ b64_decode_depth 0 \ bitenc_decode_depth 0 That's the only things included for imap. so are all the imap commands missing? [/quote] The base Security Onion Snort.conf has these settings only. # IMAP preprocessor. For more information see README.imap preprocessor imap: \ ports { 143 } \ b64_decode_depth 0 \ qp_decode_depth 0 \ bitenc_decode_depth 0 \ uu_decode_depth 0
-
You could try posting this to the Snort Mailing List. I believe there is a link to it over at http://www.snort.org.
BillThe snort support group is at https://groups.google.com/forum/#!forum/mailing.unix.snort
I think that most use only this option –enable-sourcefire at compile time.
-
So I'm having difficulties running Barnyard following this update. Prior version worked okay, now I'm getting this error:
Feb 22 06:02:37 barnyard2[23192]: Barnyard2 exiting Feb 22 06:02:37 barnyard2[23192]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 22 06:02:37 barnyard2[23192]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :119] [sid: 4] [upd_rev: 1] [upd class: 17] [upd pri 3] Feb 22 06:02:37 barnyard2[23192]: ERROR database: Returned signature_id [647] is not equal to updated signature_id [1170] in [dbSignatureInformationUpdate()] Feb 22 06:02:37 barnyard2[23192]: Opened spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584' Feb 22 06:02:37 barnyard2[23192]: Using waldo file '/var/log/snort/snort_em057355/barnyard2/57355_em0.waldo': spool directory = /var/log/snort/snort_em057355 spool filebase = snort_57355_em0.u2 time_stamp = 1392881584 record_idx = 25 Feb 22 06:02:37 barnyard2[23192]: Barnyard2 initialization completed successfully (pid=23192) Feb 22 06:02:37 barnyard2[23192]: --== Initialization Complete ==--
-
So I'm having difficulties running Barnyard following this update. Prior version worked okay, now I'm getting this error:
Feb 22 06:02:37 barnyard2[23192]: Barnyard2 exiting Feb 22 06:02:37 barnyard2[23192]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 22 06:02:37 barnyard2[23192]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :119] [sid: 4] [upd_rev: 1] [upd class: 17] [upd pri 3] Feb 22 06:02:37 barnyard2[23192]: ERROR database: Returned signature_id [647] is not equal to updated signature_id [1170] in [dbSignatureInformationUpdate()] Feb 22 06:02:37 barnyard2[23192]: Opened spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584' Feb 22 06:02:37 barnyard2[23192]: Using waldo file '/var/log/snort/snort_em057355/barnyard2/57355_em0.waldo': spool directory = /var/log/snort/snort_em057355 spool filebase = snort_57355_em0.u2 time_stamp = 1392881584 record_idx = 25 Feb 22 06:02:37 barnyard2[23192]: Barnyard2 initialization completed successfully (pid=23192) Feb 22 06:02:37 barnyard2[23192]: --== Initialization Complete ==--
My barnyard2 install seemed to work OK after the update, but there was this message posted on the Snort VRT blog some time back:
UPGRADE REQUIREMENTS
If you are upgrading to barnyard2 2-1.13 (build 327) or above from a previous version and using output database.
You will need to delete every row in your sig_reference table. (DELETE FROM sig_reference;)
The table will be re-populated at startup, and has no impact on historical data.
I did not mention in the package release notes because I thought it mainly applied if the sid-msg.map file was updated to the new version 2 format. I did not update the sid-msg.map format yet, so I thought the message above did not apply. I could be wrong. Try what is recommended and let me know if it fixes your problem. I will edit the Release Notes to include this barnyard2 information.
Bill
-
Ran the query to purge the table, doesn't appear to actually solve the issue though. The table gets repopulated fine. Here is a more complete log - redacted server info for post.
Feb 22 09:35:38 barnyard2[1293]: Closing spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584'. Read 26 records Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: Total: 13 Feb 22 09:35:38 barnyard2[1293]: S5 G 2: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: S5 G 1: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: InvChkSum: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: DISCARD: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: OTHER: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: MPLS: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE LOOP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPX: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE ARP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE PPTP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IP6 E: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE VLAN: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE ETH: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv6/IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv6/IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv4/IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv4/IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPX: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETHLOOP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: EAPOL: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ARP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: FRAG 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: FRAG: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMPdis: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDPdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: TCPdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDP: 5 (38.462%) Feb 22 09:35:38 barnyard2[1293]: TCP: 8 (61.538%) Feb 22 09:35:38 barnyard2[1293]: ICMP-IP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMP6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDP 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: TCP 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP4disc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP4: 13 (100.000%) Feb 22 09:35:38 barnyard2[1293]: IP6disc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP6opts: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP6 EXT: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPV6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: VLAN: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETHdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETH: 13 (100.000%) Feb 22 09:35:38 barnyard2[1293]: Packet breakdown by protocol (includes rebuilt packets): Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: Suppressed: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: Unknown: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: Packets: 13 (50.000%) Feb 22 09:35:38 barnyard2[1293]: Events: 13 (50.000%) Feb 22 09:35:38 barnyard2[1293]: Records: 26 Feb 22 09:35:38 barnyard2[1293]: Record Totals: Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: database: Closing connection to database "#####" Feb 22 09:35:38 barnyard2[1293]: Barnyard2 exiting Feb 22 09:35:38 barnyard2[1293]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 22 09:35:38 barnyard2[1293]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :119] [sid: 4] [upd_rev: 1] [upd class: 17] [upd pri 3] Feb 22 09:35:38 barnyard2[1293]: ERROR database: Returned signature_id [647] is not equal to updated signature_id [1170] in [dbSignatureInformationUpdate()] Feb 22 09:35:38 barnyard2[1293]: Opened spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584' Feb 22 09:35:38 barnyard2[1293]: Using waldo file '/var/log/snort/snort_em057355/barnyard2/57355_em0.waldo': spool directory = /var/log/snort/snort_em057355 spool filebase = snort_57355_em0.u2 time_stamp = 1392881584 record_idx = 25 Feb 22 09:35:38 barnyard2[1293]: Barnyard2 initialization completed successfully (pid=1293) Feb 22 09:35:38 barnyard2[1293]: --== Initialization Complete ==-- Feb 22 09:35:38 barnyard2[1293]: Feb 22 09:35:38 barnyard2[1293]: database: using the "alert" facility Feb 22 09:35:38 barnyard2[1293]: database: ignore_bpf = no Feb 22 09:35:38 barnyard2[1293]: database: detail level = full Feb 22 09:35:38 barnyard2[1293]: database: data encoding = hex Feb 22 09:35:38 barnyard2[1293]: database: sensor cid = 147057 Feb 22 09:35:38 barnyard2[1293]: database: sensor id = 1 Feb 22 09:35:38 barnyard2[1293]: database: sensor name = #####:em0 Feb 22 09:35:38 barnyard2[1293]: database: database name = ##### Feb 22 09:35:38 barnyard2[1293]: database: user = ##### Feb 22 09:35:38 barnyard2[1293]: database: host = ##### Feb 22 09:35:38 barnyard2[1293]: database: schema version = 107 Feb 22 09:35:38 barnyard2[1293]: database: configured to use mysql Feb 22 09:35:38 barnyard2[1293]: database: compiled support for (mysql) Feb 22 09:35:08 barnyard2[1293]: Writing PID "1293" to file "/var/run/barnyard2_em057355.pid" Feb 22 09:35:08 barnyard2[1293]: PID path stat checked out ok, PID path set to /var/run Feb 22 09:35:08 barnyard2[1293]: Daemon initialized, signaled parent pid: 1280 Feb 22 09:35:08 barnyard2[1280]: Daemon parent exiting Feb 22 09:35:08 barnyard2[1280]: Initializing daemon mode Feb 22 09:35:08 barnyard2[1280]: INFO database: Defaulting Reconnect sleep time to 5 second Feb 22 09:35:08 barnyard2[1280]: INFO database: Defaulting Reconnect/Transaction Error limit to 10 Feb 22 09:35:08 barnyard2[1280]: Log directory = /var/log/snort/snort_em057355 Feb 22 09:35:08 barnyard2[1280]: Barnyard2 spooler: Event cache size set to [2048] Feb 22 09:35:06 barnyard2[1280]: ---------------------------- +[ Signature Suppress list ]+ Feb 22 09:35:06 barnyard2[1280]: +[No entry in Signature Suppress List]+ Feb 22 09:35:06 barnyard2[1280]: +[ Signature Suppress list ]+ ---------------------------- Feb 22 09:35:06 barnyard2[1280]: Found pid path directive (/var/run) Feb 22 09:35:06 barnyard2[1280]: Parsing config file "/usr/pbi/snort-amd64/etc/snort/snort_57355_em0/barnyard2.conf" Feb 22 09:35:06 barnyard2[1280]: Initializing Output Plugins! Feb 22 09:35:06 barnyard2[1280]: Initializing Input Plugins! Feb 22 09:35:06 barnyard2[1280]: --== Initializing Barnyard2 ==-- Feb 22 09:35:06 barnyard2[1280]: Feb 22 09:35:06 barnyard2[1280]: Running in Continuous mode Feb 22 09:35:06 barnyard2[1280]: Found pid path directive (/var/run) Feb 22 09:35:06 php: /snort/snort_interfaces.php: [Snort] Barnyard2 START for Internet(em0)... Feb 22 09:35:06 php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Internet)...
-
Ran the query to purge the table, doesn't appear to actually solve the issue though. The table gets repopulated fine. Here is a more complete log - redacted server info for post.
Feb 22 09:35:38 barnyard2[1293]: Closing spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584'. Read 26 records Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: Total: 13 Feb 22 09:35:38 barnyard2[1293]: S5 G 2: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: S5 G 1: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: InvChkSum: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: DISCARD: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: OTHER: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: MPLS: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE LOOP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPX: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE ARP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE PPTP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IP6 E: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE VLAN: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE ETH: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: GRE: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv6/IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv6/IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv4/IPv6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPv4/IPv4: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPX: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETHLOOP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: EAPOL: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ARP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: FRAG 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: FRAG: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMPdis: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDPdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: TCPdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDP: 5 (38.462%) Feb 22 09:35:38 barnyard2[1293]: TCP: 8 (61.538%) Feb 22 09:35:38 barnyard2[1293]: ICMP-IP: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ICMP6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: UDP 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: TCP 6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP4disc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP4: 13 (100.000%) Feb 22 09:35:38 barnyard2[1293]: IP6disc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP6opts: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IP6 EXT: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: IPV6: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: VLAN: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETHdisc: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: ETH: 13 (100.000%) Feb 22 09:35:38 barnyard2[1293]: Packet breakdown by protocol (includes rebuilt packets): Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: Suppressed: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: Unknown: 0 (0.000%) Feb 22 09:35:38 barnyard2[1293]: Packets: 13 (50.000%) Feb 22 09:35:38 barnyard2[1293]: Events: 13 (50.000%) Feb 22 09:35:38 barnyard2[1293]: Records: 26 Feb 22 09:35:38 barnyard2[1293]: Record Totals: Feb 22 09:35:38 barnyard2[1293]: =============================================================================== Feb 22 09:35:38 barnyard2[1293]: database: Closing connection to database "#####" Feb 22 09:35:38 barnyard2[1293]: Barnyard2 exiting Feb 22 09:35:38 barnyard2[1293]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 22 09:35:38 barnyard2[1293]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :119] [sid: 4] [upd_rev: 1] [upd class: 17] [upd pri 3] Feb 22 09:35:38 barnyard2[1293]: ERROR database: Returned signature_id [647] is not equal to updated signature_id [1170] in [dbSignatureInformationUpdate()] Feb 22 09:35:38 barnyard2[1293]: Opened spool file '/var/log/snort/snort_em057355/snort_57355_em0.u2.1392881584' Feb 22 09:35:38 barnyard2[1293]: Using waldo file '/var/log/snort/snort_em057355/barnyard2/57355_em0.waldo': spool directory = /var/log/snort/snort_em057355 spool filebase = snort_57355_em0.u2 time_stamp = 1392881584 record_idx = 25 Feb 22 09:35:38 barnyard2[1293]: Barnyard2 initialization completed successfully (pid=1293) Feb 22 09:35:38 barnyard2[1293]: --== Initialization Complete ==-- Feb 22 09:35:38 barnyard2[1293]: Feb 22 09:35:38 barnyard2[1293]: database: using the "alert" facility Feb 22 09:35:38 barnyard2[1293]: database: ignore_bpf = no Feb 22 09:35:38 barnyard2[1293]: database: detail level = full Feb 22 09:35:38 barnyard2[1293]: database: data encoding = hex Feb 22 09:35:38 barnyard2[1293]: database: sensor cid = 147057 Feb 22 09:35:38 barnyard2[1293]: database: sensor id = 1 Feb 22 09:35:38 barnyard2[1293]: database: sensor name = #####:em0 Feb 22 09:35:38 barnyard2[1293]: database: database name = ##### Feb 22 09:35:38 barnyard2[1293]: database: user = ##### Feb 22 09:35:38 barnyard2[1293]: database: host = ##### Feb 22 09:35:38 barnyard2[1293]: database: schema version = 107 Feb 22 09:35:38 barnyard2[1293]: database: configured to use mysql Feb 22 09:35:38 barnyard2[1293]: database: compiled support for (mysql) Feb 22 09:35:08 barnyard2[1293]: Writing PID "1293" to file "/var/run/barnyard2_em057355.pid" Feb 22 09:35:08 barnyard2[1293]: PID path stat checked out ok, PID path set to /var/run Feb 22 09:35:08 barnyard2[1293]: Daemon initialized, signaled parent pid: 1280 Feb 22 09:35:08 barnyard2[1280]: Daemon parent exiting Feb 22 09:35:08 barnyard2[1280]: Initializing daemon mode Feb 22 09:35:08 barnyard2[1280]: INFO database: Defaulting Reconnect sleep time to 5 second Feb 22 09:35:08 barnyard2[1280]: INFO database: Defaulting Reconnect/Transaction Error limit to 10 Feb 22 09:35:08 barnyard2[1280]: Log directory = /var/log/snort/snort_em057355 Feb 22 09:35:08 barnyard2[1280]: Barnyard2 spooler: Event cache size set to [2048] Feb 22 09:35:06 barnyard2[1280]: ---------------------------- +[ Signature Suppress list ]+ Feb 22 09:35:06 barnyard2[1280]: +[No entry in Signature Suppress List]+ Feb 22 09:35:06 barnyard2[1280]: +[ Signature Suppress list ]+ ---------------------------- Feb 22 09:35:06 barnyard2[1280]: Found pid path directive (/var/run) Feb 22 09:35:06 barnyard2[1280]: Parsing config file "/usr/pbi/snort-amd64/etc/snort/snort_57355_em0/barnyard2.conf" Feb 22 09:35:06 barnyard2[1280]: Initializing Output Plugins! Feb 22 09:35:06 barnyard2[1280]: Initializing Input Plugins! Feb 22 09:35:06 barnyard2[1280]: --== Initializing Barnyard2 ==-- Feb 22 09:35:06 barnyard2[1280]: Feb 22 09:35:06 barnyard2[1280]: Running in Continuous mode Feb 22 09:35:06 barnyard2[1280]: Found pid path directive (/var/run) Feb 22 09:35:06 php: /snort/snort_interfaces.php: [Snort] Barnyard2 START for Internet(em0)... Feb 22 09:35:06 php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Internet)...
These two lines are the key, but I don't really understand what the error message means yet:
Feb 22 09:35:38 barnyard2[1293]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :119] [sid: 4] [upd_rev: 1] [upd class: 17] [upd pri 3] Feb 22 09:35:38 barnyard2[1293]: ERROR database: Returned signature_id [647] is not equal to updated signature_id [1170] in [dbSignatureInformationUpdate()]
Let me do a little research. That particular alert is from one of the preprocessor rules.
Bill
-
Well, not sure what you might've turned up in your research. I decided that I wanted it working so sacrificed the old database and rebuilt it from scratch using Snorby's update command. Originally I was using ET and Community rules, now just using VRT registered rules. I'll edit / post again if the problem resumes.
-
Well, not sure what you might've turned up in your research. I decided that I wanted it working so sacrificed the old database and rebuilt it from scratch using Snorby's update command. Originally I was using ET and Community rules, now just using VRT registered rules. I'll edit / post again if the problem resumes.
Nothing turned up yet, but admittedly I've had only a few minutes to research this. Been busy with the Suricata BETA package the last few days. I run Barnyard2 on three interfaces on my home firewall, but admittedly the firewall sees low traffic and not a variety of alerts. I run a lot of the ET block lists (ET RBN, ET CINS, etc.) on the WAN side and get a decent number of alerts there. I have not yet seen a Barnyard2 problem. I will try and devote some time to research this a bit more over the next couple of days. In the meantime, if you get any more data, please share it here.
Thanks,
Bill -
Looks like my barnyard2 has started crashing also:
Feb 27 08:31:30 barnyard2[91121]: Barnyard2 exiting Feb 27 08:31:30 barnyard2[91121]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 27 08:31:30 barnyard2[91121]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :122] [sid: 6] [upd_rev: 1] [upd class: 3] [upd pri 2] Feb 27 08:31:30 barnyard2[91121]: ERROR database: Returned signature_id [478] is not equal to updated signature_id [700] in [dbSignatureInformationUpdate()]
I'm using ET Free and Snort paid rules.
-
Looks like my barnyard2 has started crashing also:
Feb 27 08:31:30 barnyard2[91121]: Barnyard2 exiting Feb 27 08:31:30 barnyard2[91121]: FATAL ERROR: [dbProcessSignatureInformation()]: Failed, stoping processing Feb 27 08:31:30 barnyard2[91121]: [dbProcessSignatureInformation()] Line[1556], call to dbSignatureInformationUpdate failed for : [gid :122] [sid: 6] [upd_rev: 1] [upd class: 3] [upd pri 2] Feb 27 08:31:30 barnyard2[91121]: ERROR database: Returned signature_id [478] is not equal to updated signature_id [700] in [dbSignatureInformationUpdate()]
I'm using ET Free and Snort paid rules.
Thanks for the report. I will dig into this tomorrow (Friday). I suspect it has something to do with the new preprocessor and decoder rules getting included in the sid-msg.map. That's the most likely cause since that is all that really changed other than bumping Barnyard up to 2.13 from 2.12. I'm not seeing it yet in my installation, but you are at least the second person reporting the same issue on the forum.
What backend system are you writing to with Barnyard? Is it Snorby or something else? I use Snorby on Ubuntu.
Bill
-
I have Snorby running on Debian.
-
-
Well, not sure what you might've turned up in your research. I decided that I wanted it working so sacrificed the old database and rebuilt it from scratch using Snorby's update command. Originally I was using ET and Community rules, now just using VRT registered rules. I'll edit / post again if the problem resumes.
I found information on this in a Google Groups discussion with one of the Barnyard2 folks. The root cause seems to be not using the new optional sid-msg.map v2 format. Use of that format is supposed to be "optional", but apparently it can sometimes lead to issues if the old v1 format is used. Here is the link to the Google Groups thread:
https://groups.google.com/forum/#!topic/barnyard2-users/IIoyClc7XTc
Here is another good post with the same information, but maybe easier to read.
http://sourceforge.net/p/snort/mailman/message/31925851/
There is a solution posted in each link for a workaround. Unfortunately it involves a fair amount of SQL. There is a script posted in each thread, though. In the next version of the Snort package, I will migrate the sid-msg.map file to the new v2 format and hopefully that will prevent this in the future.
Sorry you had the issue,
Bill
-
Hi,
I was able to get barnyard2 running again with the sql queries provided in the 2 links. :)
-
Hi,
I was able to get barnyard2 running again with the sql queries provided in the 2 links. :)
Great! As I said up above, in the next Snort update I will migrate to the new v2 format of the sid-msg.map file. This is a "look up" file Barnyard uses to obtain supporting descriptive information about the alert signatures. Beginning with this version of Barnyard2, a new format with some added columns of information is supported.
Bill
-
Bill,
Since I have upgraded to this snort version, my firewall has experienced two kernel panics (pulled from log) and rebooted itself. Prior to going from previous version number to this one ( I do keep updated as much as I can) the firewall has never once panicked on me or rebooted. Nothing else has been touched. No other packages updated or core components updated. I am on the most recent build of pfsense. Would this package cause this for some strange reason or are the two not related and its just more of of a coincidence?
The first time was the next day after i updated earlier in the week. Then it did it again at 3:45 am this morning..
I can list out full packages and hardware if you need it.. I am just scratching my head at this one..Also when i idid the upgrade, i did a full remove, kept settings though and then installed most recent package and the settings were restored.. I am going to do a full remove again and re-install …
I dont see anything else in the log that i can tell that would tell me what caused this. I did upload both crash dumps to the pfsense. I deleted the first one but kept the second one on my hard drive. Not sure if it would be any help if it is related to the updated snort...
Also upon the reboot i get this error / alert. Never seen it before.
There were error(s) loading the rules: pfctl: DIOCADDRULE: Device busy - The line in question reads [0]:
Just thought I would ask and see if it could be this package now or something un-related..