Snort 2.9.5.6 pkg v3.0.4 Update – Release notes and change log
-
Bill, sorry but before I saw your reply I unchecked the Save configuration option and uninstalled Snort. I re-installed and all is running fine. I have a paid Snort subscription. Thanks!
-
Bill, sorry but before I saw your reply I unchecked the Save configuration option and uninstalled Snort. I re-installed and all is running fine. I have a paid Snort subscription. Thanks!
OK. Glad it worked out for you. Something in that file must have gotten corrupted during the original download and install. As I said, that file is actually part of the downloaded rules tarball from snort.org.
Bill
-
New Features
- The ALERTS tab now features a "Rule Disable" icon in the SID column alongside the "Add to Suppress List" icon. Clicking the "Rule Disable" icon will force-disable the rule and prevent traffic being evaluated against the rule. Note this will result in the rule being completely removed from the enforcing rule set; as opposed to suppressing the alert, which simply prevents future alerts but the rule still inspects traffic.
Nice one! Thank you very much for this.
@bmeeks:- The Snort GUI now provides the ability to manage all rules including the decoder and preprocessor rules on the RULES tab. Users can force-disable (or force-enable) any rules from the decoder.rules, preprocessor.rules and sensitive-data.rules files. Snort now generates a single enforcing rules file (snort.rules) that contains all the rules including the preprocessor rules that were formerly loaded separately from a different sub-directory. A beneficial side-effect to this is that now the sid-msg.map file is complete and contains the preprocessor rules. This is helpful with third-party logging tools such as Barnyard2 that depend on the sig-msg.map file.
Does this mean I can finally get rid of the double decoding attack alert (I thought IIS was banned from industry use by now…)? And does this mean smaller suppress lists? Even less power wasted evaluating useless rules? THANK YOU!!!
On the downside, I have to post an update to the blueprint now :P -
@jflsakfja:
Does this mean I can finally get rid of the double decoding attack alert (I thought IIS was banned from industry use by now…)? And does this mean smaller suppress lists? Even less power wasted evaluating useless rules? THANK YOU!!!
On the downside, I have to post an update to the blueprint now :PYep. The user now has total control of the decoder and preprocessor rules via the RULES tab. Just select them in the drop-down list and disable away as you desire.
I have a plan for the future to continue improvements with rules management including the ability to use PCREs to selectively enable/disable rules. In short, I plan to incorporate the functionality of the enablesid.conf, disablesid.conf and/or modifiysid.conf files afforded by PulledPork and Oinkmaster.
Bill
-
Hi Bill,
Could you take a look at the attached png file?
The Alerts page is showing alerts for the "Disabled Rules". Is this normal?
Would that mean that all of the rules are loaded into memory? Memory is not an issue for me, however, I never noticed that before.
If this is Normal, than I guess atleast I'm seeing the alerts that are not being blocked?
![Alert Page.png](/public/imported_attachments/1/Alert Page.png)
![Alert Page.png_thumb](/public/imported_attachments/1/Alert Page.png_thumb) -
@BBcan17:
Hi Bill,
Could you take a look at the attached png file?
The Alerts page is showing alerts for the "Disabled Rules". Is this normal?
Would that mean that all of the rules are loaded into memory? Memory is not an issue for me, however, I never noticed that before.
If this is Normal, than I guess atleast I'm seeing the alerts that are not being blocked?
You are probably seeing "history". The view on the ALERTS tab is simply the first "nnn" records read from the alerts log. The "nnn" value is the numeric setting on the tab for how many alerts to show. So the alert should have happened in the past, you disabled the rule, but the original entry is still in the alerts log and will be read and shown in the list. To see if my theory is correct, reduce the number of alerts to display to something like 3 or 4 and see if the disabled ones disappear. If not post back.
The new code should be disabling the rule, performing an enforcing rules file rebuild for the interface, and then doing a "live rule reload" for the interface all when you click the X. From that point forward, you should get no new alerts from the disabled rule. But because of the history aspect in the logs as I described above, you might see them listed on the tab (but with the lighter-colored icon to show the rule is disabled). Depending on how many alerts you get per unit time, and the setting of how many alert log entries to display, the alerts from disabled rules should eventually disappear from the tab.
Bill
-
You are probably seeing "history".
So the alert should have happened in the past, you disabled the rule, but the original entry is still in the alerts log and will be read and shown in the list. To see if my theory is correct, reduce the number of alerts to display to something like 3 or 4 and see if the disabled ones disappear. If not post back.
These are fresh events. See attached png files. Those rules have been disabled for a long time now.
![Alert Page.png](/public/imported_attachments/1/Alert Page.png)
![Alert Page.png_thumb](/public/imported_attachments/1/Alert Page.png_thumb)
![Alert Page 2.png](/public/imported_attachments/1/Alert Page 2.png)
![Alert Page 2.png_thumb](/public/imported_attachments/1/Alert Page 2.png_thumb) -
@BBcan17:
You are probably seeing "history".
So the alert should have happened in the past, you disabled the rule, but the original entry is still in the alerts log and will be read and shown in the list. To see if my theory is correct, reduce the number of alerts to display to something like 3 or 4 and see if the disabled ones disappear. If not post back.
These are fresh events. See attached png files. Those rules have been disabled for a long time now.
OK, one more question. Did you try manually restarting Snort after disabling the rule? That should not be required, but maybe something is not working with live reload. Also, did you disable the rule from the new ALERTS tab icon or from the RULES tab? If on the RULES tab, you need to click APPLY after disabling the rule in order for a new rule set to build.
I will test this in a virtual machine again. It was working (or at least I thought it was working… :-[).
Bill
-
Hi Bill,
I didn't add or remove any rules today. Those rules were disabled months ago. :(
-
@BBcan17:
Hi Bill,
I didn't add or remove any rules today. Those rules were disabled months ago. :(
Hmm…OK, one more question. Look in your config.xml file using Diagnostics…Edit File. The path to the file is /conf/config.xml. Scroll down and find all the Snort parameters. The section title will start with <snortglobal>. You will see collections of data for each configured interface. For the interface in question, find the tag element for <rule_sid_off>and look at the values stored there. You should have pairs of numbers separated colons. These are the GID:SID values for the rule. Each GID:SID pair should be delimited by " || " double-pipe symbols. Let me know if anything other than what I described is in there.
It's late where I am, so I will test this in a VM tomorrow and see if I goofed it up someplace.
Bill</rule_sid_off></snortglobal>
-
Hi Bill,
It looks ok to me…
Let me know if you want me to send it to you?
Thanks.
-
Hi,
I updated the snort package today, but when starting snort with the block option I get the following error:
"Feb 20 10:09:13 snort[7254]: FATAL ERROR: pf.conf => Table snort2c don't exists in packet filter: No such file or directory"I searched the net, and found a previous post about the same issue but for an older version, so the resolution is not the same.
Can you please tell me how to make this work again? I highly rely on the auto block option as we see a lot of russian botnets trying to attack or scan our servers.PS I tried reinstalling the package and uninstalling and installing it again. Although with saving options, as I deselected some of the rules
Thanks in advance
K.R.Ruben Vanhoutte
-
Hi,
I updated the snort package today, but when starting snort with the block option I get the following error:
"Feb 20 10:09:13 snort[7254]: FATAL ERROR: pf.conf => Table snort2c don't exists in packet filter: No such file or directory"I searched the net, and found a previous post about the same issue but for an older version, so the resolution is not the same.
Can you please tell me how to make this work again? I highly rely on the auto block option as we see a lot of russian botnets trying to attack or scan our servers.PS I tried reinstalling the package and uninstalling and installing it again. Although with saving options, as I deselected some of the rules
Thanks in advance
K.R.Ruben Vanhoutte
Whoa! That is a strange error message. What version of pfSense are you running? Seems like maybe an old one? The <snort2c>alias table it is complaining about is part of the base pfSense install and is not added or removed by the Snort package. The fact that table is reported as missing seems to indicate maybe you have a very old pfSense version.
If you have version older than 2.0.x, then I strongly recommend updating. If you have a version equal to or newer than 2.0.x, then something very bad has happened to the installation and a complete re-install is likely required to fix it.
Bill</snort2c>
-
Reporting that the rule disable button on the alerts tab works as expected.
Preprocessor rules are also working as expected. It might be me, or the reduced suppression list but the systems feel faster.
Over and out :P
-
@jflsakfja:
Reporting that the rule disable button on the alerts tab works as expected.
Preprocessor rules are also working as expected. It might be me, or the reduced suppression list but the systems feel faster.
Over and out :P
Thanks for the feedback. I was investigating BBcan17's issue posted above where he said a disabled rule was still firing for him, and was so far I am unable to reproduce. Your confirmation the rules disable feature is working for you as intended is helpful.
On the faster front, could be the update to Snort 2.9.5.6 is helping as well. The Snort VRT folks are still making various "under-the-hood" updates now and then.
Bill
-
@BBcan17:
Hi Bill,
It looks ok to me…
Let me know if you want me to send it to you?
Thanks.
BBcan17:
Quick question from something I just noticed in your screenshots. Are you running both Emerging Threats Pro and Emerging Threats Open rules concurrently? It looks like both have generated an alert from your screenshots, and that really should not be possible. The GUI is supposed to lock out one when the other is selected (on the GLOBAL SETTINGS tab). The code is also supposed to remove ET Open rules if you enable ET Pro, and vice versa.
If you are in fact running both rule sets, then you could very well have duplicate SIDs. The GUI code is not set up to handle this as that would be an unexpected occurrence based on locking out ET Open when ET Pro is selected, or locking out ET Pro when ET Open is selected. The disable SID code will basically just find and disable the first occurrence of the SID in the rules array when searching. So it could be disabling the ET Pro SID for one disabled ET Open rule, and then the ET Open SID for another ET Pro one. Does what I'm saying make sense?
Reply back and let me know if you are in fact using both rule sets (and how you managed to enable them if you are). By the way, the Emerging Threats Pro rules contain all of the ET Open rules and then extra "Pro Rules". It's the extra Pro rules that you pay for. My understanding is there is no benefit to running both sets of Emerging Threats rules.
Bill
-
Hi,
I updated the snort package today, but when starting snort with the block option I get the following error:
"Feb 20 10:09:13 snort[7254]: FATAL ERROR: pf.conf => Table snort2c don't exists in packet filter: No such file or directory"I searched the net, and found a previous post about the same issue but for an older version, so the resolution is not the same.
Can you please tell me how to make this work again? I highly rely on the auto block option as we see a lot of russian botnets trying to attack or scan our servers.PS I tried reinstalling the package and uninstalling and installing it again. Although with saving options, as I deselected some of the rules
Thanks in advance
K.R.Ruben Vanhoutte
Whoa! That is a strange error message. What version of pfSense are you running? Seems like maybe an old one? The <snort2c>alias table it is complaining about is part of the base pfSense install and is not added or removed by the Snort package. The fact that table is reported as missing seems to indicate maybe you have a very old pfSense version.
If you have version older than 2.0.x, then I strongly recommend updating. If you have a version equal to or newer than 2.0.x, then something very bad has happened to the installation and a complete re-install is likely required to fix it.
Bill</snort2c>
Hi Bill,
I solved it. apparently the problem was situated in my aliasses. I had an 'URL table' alias with around 4300 IP addresses that needed to be blocked.
I noticed that the block rules for that alias wasn't working and all firewall rules were disabled to the point everything was any-any allowed.
Removing that Alias caused everything to work again. So apparently that single alias with >4000 IP's broke the whole firewall.. -
Hi,
I updated the snort package today, but when starting snort with the block option I get the following error:
"Feb 20 10:09:13 snort[7254]: FATAL ERROR: pf.conf => Table snort2c don't exists in packet filter: No such file or directory"I searched the net, and found a previous post about the same issue but for an older version, so the resolution is not the same.
Can you please tell me how to make this work again? I highly rely on the auto block option as we see a lot of russian botnets trying to attack or scan our servers.PS I tried reinstalling the package and uninstalling and installing it again. Although with saving options, as I deselected some of the rules
Thanks in advance
K.R.Ruben Vanhoutte
Whoa! That is a strange error message. What version of pfSense are you running? Seems like maybe an old one? The <snort2c>alias table it is complaining about is part of the base pfSense install and is not added or removed by the Snort package. The fact that table is reported as missing seems to indicate maybe you have a very old pfSense version.
If you have version older than 2.0.x, then I strongly recommend updating. If you have a version equal to or newer than 2.0.x, then something very bad has happened to the installation and a complete re-install is likely required to fix it.
Bill</snort2c>
Hi Bill,
I solved it. apparently the problem was situated in my aliasses. I had an 'URL table' alias with around 4300 IP addresses that needed to be blocked.
I noticed that the block rules for that alias wasn't working and all firewall rules were disabled to the point everything was any-any allowed.
Removing that Alias caused everything to work again. So apparently that single alias with >4000 IP's broke the whole firewall..Glad you sorted it out. I think I've seen a few others posting in other sub-forums about problems with large numbers of IPs in alias tables on pfSense. You could post the issue in the Firewall section of the Support Forum and see if any of the folks in there can help.
Bill
-
Quick question from something I just noticed in your screenshots. Are you running both Emerging Threats Pro and Emerging Threats Open rules concurrently? It looks like both have generated an alert from your screenshots, and that really should not be possible.
Reply back and let me know if you are in fact using both rule sets (and how you managed to enable them if you are). By the way, the Emerging Threats Pro rules contain all of the ET Open rules and then extra "Pro Rules". It's the extra Pro rules that you pay for. My understanding is there is no benefit to running both sets of Emerging Threats rules.
Bill
Hi Bill, I am using VT Pro and Snort VRT (pd).
I did noticed a few days ago that one of my alias tables (less than 100 ips) duplicated 3 times in the Alias Lists. I had to rename the 2 duplicates and than it allowed me to delete it.
I also am noticing that one of the rules "ET POLICY curl User-Agent Outbound" which was disabled months ago. Keeps blocking traffic. I have tried to add a suppress but it still blocks any traffic. I've tried to remove the block from the table and restart Snort without success.
I do notice that the GUI is a lot quicker to respond than previously.
-
@BBcan17:
I also am noticing that one of the rules "ET POLICY curl User-Agent Outbound" which was disabled months ago. Keeps blocking traffic. I have tried to add a suppress but it still blocks any traffic. I've tried to remove the block from the table and restart Snort without success.
Just tested (curl ifconfig.me) and the rule did not fire up an alert. Are you sure it's disabled/suppressed?
EDIT: On a side note, the pcaps in /var/log/snort/$interface don't appear to be timestamped correctly, or certain captures are not logged. I'm looking for a specific capture to investigate an IMAP unknown response and an IMAP unknown command for a client of mine and cannot find it.
EDIT2: greping the files for the IP shows all the entries in the alert file, but not in other files (snort.log.xxxxxxxxx), so I'm guessing it wasn't logged after all.
-
Hi Bill,
I have uninstalled the Snort package and re-installed and it looks like its back to normal? I will keep you posted.
After it was re-installed, while it was enabling the Interfaces in the back ground, i noticed the first alert was from a "Disabled" Rule. but the balance of the alerts since Snort
was fully enabled on both interfaces are all from "Enabled" Rules only.The "ET POLICY curl User-Agent Outbound" rule is also not being blocked since the re-install as per my last post.
I will have to let it run for a bit to know for sure…. ;)
Thanks.
-
@jflsakfja:
Just tested (curl ifconfig.me) and the rule did not fire up an alert. Are you sure it's disabled/suppressed?
That rule was disabled and the alert was greyed out in the Alerts Tab. I also had it in the suppress.
Re-Install seems to have fixed it.
-
@BBcan17:
Hi Bill,
I have uninstalled the Snort package and re-installed and it looks like its back to normal? I will keep you posted.
After it was re-installed, while it was enabling the Interfaces in the back ground, i noticed the first alert was from a "Disabled" Rule. but the balance of the alerts since Snort
was fully enabled on both interfaces are all from "Enabled" Rules only.The "ET POLICY curl User-Agent Outbound" rule is also not being blocked since the re-install as per my last post.
I will have to let it run for a bit to know for sure…. ;)
Thanks.
OK. Sounds like something got sort of messed up at some point. Glad the reinstall seems to have fixed things for you. I tested disabling rules this morning, and they do in fact get completely removed from the snort.rules file where all the active rules go. You will find this file in the interface directory such as /usr/pbi/snort-amd64/etc/snort/snort_xxxxx_em0/rules (where xxxxx is the UUID for the interface). So if you want to be sure a particular rule is not being used, just grep for it in that file. If not there, then the running Snort interface with the same UUID can't be using it since it reads the rules to enforce from that file.
Bill
-
Where can I find the recognized IMAP commands? been searching for a while and couldn't find them in a file. Need to check a packet capture against the known commands to see what's causing the rule to fire an alert.
-
@jflsakfja:
Where can I find the recognized IMAP commands? been searching for a while and couldn't find them in a file. Need to check a packet capture against the known commands to see what's causing the rule to fire an alert.
Should be listed in the snort.conf file for the interface. Assuming a pfSense 2.1 64-bit build, the path would be:
/usr/pbi/snort-amd64/etc/snort/snort_xxxxx_em0/snort.conf
Modify the path with "i-386" if a 32-bit machine. The "xxxx" is a UUID that is unique to each interface, and the "em0" in my example is the physical interface name. It may be different on your hardware.
For now the SMTP and IMAP commands are not user-editable, and any changes you make manually in the file will be overwritten at the next save of any configuration change or if Snort restarts.
You can, if you want to, disable the IMAP preprocessor completely on the PREPROCESSORS tab, and then go to the INTERFACE tab for the specific interface and type all the IMAP preprocessor configuration info manually into the Advanced Pass-Through box at the bottom of the page.
Bill
-
# IMAP preprocessor # 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?
-
@jflsakfja:
# IMAP preprocessor # 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?
Yeah, that's what is used in the configuration. I tried to mimic what is in the default snort.conf included in the source tarball, but I don't remember specifically if I looked into the IMAP preprocessor in much detail. If you have some suggested content for that or the other preprocessors, put it together and send to me in a PM (or post it here). I will try to incorporate it into a subsequent release. Just remember to stay sort of general in nature remembering that the goal is for Snort to work for the majority of users with the out-of-the-box settings.
Bill
-
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.