Snort 2.9.6.0 pkg v3.0.7 Update – Release Notes
-
An update for the Snort package has been posted. This update fixes three bugs and adds two new minor features. The underlying binary is unchanged and remains at 2.9.6.0. The GUI package version is now 3.0.7.
Bug Fixes
-
When creating a new Suppress List on the SUPPRESS LIST tab, the new list cannot be saved.
-
It is possible to add the same file to a blacklist or whitelist file list multiple times.
-
When a sensor_name is specified, Barnyard2 tries to login to DB as root user
New Features
-
The Snort package now includes a text history tag that is recorded along with all writes to the system configuration file via the write_config() system function call. This text tag provides a brief description of the saved configuration change for audit purposes
-
Added "disable_signature_reference_table" parameter to Barnyard2 tab in the GUI. This can speed up the process now that the sid-msg.map v2 format is used. It can also help work around an error with duplicate entries of references when running multiple Snort and Barnyard2 processes writing to the same MySQL database. If you have been experiencing runtime failures from Barnyard2 due to duplicate keys, try checking this checkbox on the BARNYARD2 tab for all of your Snort interfaces except one. Leave only one interface updating the signature reference table (and that should be the one on the interface running the most rules and hence seeing the most "references").
Bill
-
-
Hi bmeeks, sorry if it's the wrong place to paste it, but I'm getting this error while trying to start snort after an uninstall/install and full package reconfigure.
Apr 28 10:13:36 snort[16673]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_45266_vmx3f0/rules/snort.rules(4148) Unknown rule option: 'stream_size'. Apr 28 10:13:36 php: /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 45266 -D -q -l /var/log/snort/snort_vmx3f045266 --pid-path /var/run --nolock-pidfile -G 45266 -c /usr/pbi/snort-amd64/etc/snort/snort_45266_vmx3f0/snort.conf -i vmx3f0' returned exit code '1', the output was ''
-
Hi Marcello,
I think you have an enabled rule that requires one of the pre-processors to be enabled.
Looks like the Stream pre-processor needs to be enabled.
Or disable the rule the rule that is stopping snort from starting.
-
Sure. After checking Auto Rule Disable service started.
It's a clean snort installation with few steps to get starting. I'll find rule/preprocessor that is not configured.
I have this file created with no content /var/log/snort/WAN_disabled_preproc_rules.log
After unselecting Auto Rule Disable save again(whitout any rule or preprocessor change) I could stop and start service.
Not sure what happened but it's working now.
-
Sure. After checking Auto Rule Disable service started.
It's a clean snort installation with few steps to get starting. I'll find rule/preprocessor that is not configured.
I have this file created with no content /var/log/snort/WAN_disabled_preproc_rules.log
After unselecting Auto Rule Disable save again(whitout any rule or preprocessor change) I could stop and start service.
Not sure what happened but it's working now.
It's strange that file is empty. It should have contained the particular preprocessor and rule(s) that caused the error.
Glad it's working OK now.
Bill
-
Sure. After checking Auto Rule Disable service started.
It's a clean snort installation with few steps to get starting. I'll find rule/preprocessor that is not configured.
I have this file created with no content /var/log/snort/WAN_disabled_preproc_rules.log
After unselecting Auto Rule Disable save again(whitout any rule or preprocessor change) I could stop and start service.
Not sure what happened but it's working now.
I need to check that the initial Rules Package download is working correctly when installing or reinstalling the package. Might be an issue lurking in there that only pops up during the installation process.
Bill
-
Still getting sig-ref errors with the update.
Apr 29 18:12:00 barnyard2[11981]: database: Closing connection to database "snorby" Apr 29 18:11:59 barnyard2[11981]: Barnyard2 exiting Apr 29 18:11:59 barnyard2[11981]: FATAL ERROR: database mysql_error: Duplicate entry '7142-1' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('2627','7142','1');] Apr 29 18:11:43 barnyard2[11981]: Writing PID "11981" to file "/var/run/barnyard2_igb151284.pid" Apr 29 18:11:43 barnyard2[11981]: PID path stat checked out ok, PID path set to /var/run
Tried to startup WAN and LAN. One interface will run but not the other; same as before. I wiped the DB and tried again with same result.
Edit; I uninstalled and reinstalled Snort. For at least the last 10 mins the DB is running; it threw a few errors but it still shows as enabled on status and logs haven't shown a connection close yet. Logs below for reference if they mean anything:
Apr 29 19:19:20 barnyard2[36286]: Waiting for new data Apr 29 19:19:01 barnyard2[36286]: WARNING database [Database()]: Called with Event[0x1a43f00] Event Type [7] (P)acket [0x0], information has not been outputed. Apr 29 19:17:31 barnyard2[36286]: Opened spool file '/var/log/snort/snort_igb151284/snort_51284_igb1.u2.1398737569' Apr 29 19:17:31 barnyard2[36286]: WARNING: Ignoring corrupt/truncated waldofile '/var/log/snort/snort_igb151284/barnyard2/51284_igb1.waldo' Apr 29 19:17:31 barnyard2[36286]: Barnyard2 initialization completed successfully (pid=36286)
Going to try adding another interface ( for DMZ ) and guess see what happens.
Edit2; It looks like things are fine now. I don't know what / why the reinstall was required to get it up and running. Do you have a specific set idea for the sig-ref tables? IE: I've left the WAN sig-ref tables on, and used the checkbox for the other interfaces and it's still working. Is that a bad idea to your knowledge or does it not matter? It makes sense that as long as only one interface is using the sig-ref they shouldn't have collisions or what-not.
-
Still getting sig-ref errors with the update.
Apr 29 18:12:00 barnyard2[11981]: database: Closing connection to database "snorby" Apr 29 18:11:59 barnyard2[11981]: Barnyard2 exiting Apr 29 18:11:59 barnyard2[11981]: FATAL ERROR: database mysql_error: Duplicate entry '7142-1' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('2627','7142','1');] Apr 29 18:11:43 barnyard2[11981]: Writing PID "11981" to file "/var/run/barnyard2_igb151284.pid" Apr 29 18:11:43 barnyard2[11981]: PID path stat checked out ok, PID path set to /var/run
Tried to startup WAN and LAN. One interface will run but not the other; same as before. I wiped the DB and tried again with same result.
Edit; I uninstalled and reinstalled Snort. For at least the last 10 mins the DB is running; it threw a few errors but it still shows as enabled on status and logs haven't shown a connection close yet. Logs below for reference if they mean anything:
Apr 29 19:19:20 barnyard2[36286]: Waiting for new data Apr 29 19:19:01 barnyard2[36286]: WARNING database [Database()]: Called with Event[0x1a43f00] Event Type [7] (P)acket [0x0], information has not been outputed. Apr 29 19:17:31 barnyard2[36286]: Opened spool file '/var/log/snort/snort_igb151284/snort_51284_igb1.u2.1398737569' Apr 29 19:17:31 barnyard2[36286]: WARNING: Ignoring corrupt/truncated waldofile '/var/log/snort/snort_igb151284/barnyard2/51284_igb1.waldo' Apr 29 19:17:31 barnyard2[36286]: Barnyard2 initialization completed successfully (pid=36286)
Going to try adding another interface ( for DMZ ) and guess see what happens.
Edit2; It looks like things are fine now. I don't know what / why the reinstall was required to get it up and running. Do you have a specific set idea for the sig-ref tables? IE: I've left the WAN sig-ref tables on, and used the checkbox for the other interfaces and it's still working. Is that a bad idea to your knowledge or does it not matter? It makes sense that as long as only one interface is using the sig-ref they shouldn't have collisions or what-not.
Shouldn't matter which interface you let update the sig-ref table. This problem with multiple processes using the same DB is a Barnyard2 issue and not just with Snort. Hopefully the Barnyard2 developers make some changes in the future. Simply stated, they are not accounting for the possibility of two Barnyard processes attempting to update the table at the same time. And this updating of the sig-ref table is new in Barnyard2 1.3 as far as I can tell. That's why this problem never surfaced before.
Bill
-
First of all, thank you very much for this snort package. Very handy.
Second, I would just like bring up 2 small/minor issues:
1-small typo in "Are you sure you want to remove all blocked hosts? Click OK to continue or CANCLE to quit.". It is obviously CANCEL instead of CANCLE.
2-everytime I add Snort Alerts to the Dashboard it actually gets added twice. I mean, Snort Alerts panel shows up twice. Then when I remove it only once, actually both panels disappear.Other than that, this package is a life savior.
Many thanks -
First of all, thank you very much for this snort package. Very handy.
Second, I would just like bring up 2 small/minor issues:
1-small typo in "Are you sure you want to remove all blocked hosts? Click OK to continue or CANCLE to quit.". It is obviously CANCEL instead of CANCLE.
2-everytime I add Snort Alerts to the Dashboard it actually gets added twice. I mean, Snort Alerts panel shows up twice. Then when I remove it only once, actually both panels disappear.Other than that, this package is a life savior.
Many thanksThanks for both bug reports. I will fix the typo. I hate those in software, and especially in software I created… :-[
As for the Dashboard Widget bug, I did see that in early pre-release testing and thought I had fixed it. Here is how you can patch it up. It will require editing a line in the [i]/conf/config.xml file using the Diagnostics…Edit File pfSense menu option.
1. Make a backup of the system configuration using Diagnostics…Backup/Restore so you have a copy in case the edit below goes wrong.
2. Use Diagnostics…Edit File and browse to and open the file /conf/config.xml.
3. Scroll down in that file and find the following section (this is an example from my firewall, yours will be similar but some details may differ):
<widgets><sequence>system_information-container:col1:show,captive_portal_status-container:col1:close,carp_status-container:col1:close,gateways-container:col1:close,gmirror_status-container:col1:close,installed_packages-container:col1:close,interface_statistics-container:col1:close,interfaces-container:col1:show,ipsec-container:col2:close,load_balancer_status-container:col2:close,log-container:col2:show,openvpn-container:col2:close,picture-container:col2:close,rss-container:col2:close,services_status-container:col2:show,traffic_graphs-container:col2:none,wake_on_lan-container:col2:none,dyn_dns_status-container:col2:none,smart_status-container:col2:none,thermal_sensors-container:col2:none,snort_alerts-container:col2:show</sequence> <servicestatusfilter>routed</servicestatusfilter> <widget_snort_display_lines>9</widget_snort_display_lines></widgets>
In the field, find all instances of the text "snort_alerts-container:col2:show". Don't worry if the "col2:show" part is different. It may show "col1" or say "closed". Carefully delete all of these except one. In your case, I expect you will find two entries. Delete one of them and save the change.
That should fix your problem.
Bill
-
I hae begun to get this error with the latest release on 2.0.3
"(POP) No memory available for decoding. Memcap exceeded"
I dont know why it has begun popping up and blocking peoples pop mail from external vendors. Never did it before and I havent changed anything.
-
I hae begun to get this error with the latest release on 2.0.3
"(POP) No memory available for decoding. Memcap exceeded"
I dont know why it has begun popping up and blocking peoples pop mail from external vendors. Never did it before and I havent changed anything.
Take a look at this link
http://manual.snort.org/node111.htmlApart from enabling the Pre Processor (Enable POP Normalizer), I dont see any settings in the GUI to edit the "memcap". Maybe the snort conf file needs to be edited from a shell?
memcap <int>This option determines (in bytes) the maximum amount of memory the POP preprocessor will use for decoding base64 encoded/quoted-printable/non-encoded MIME attachments/data or Unix-to-Unix encoded attachments. This value can be set from 3276 bytes to 100MB.
This option along with the maximum of the decoding depths will determine the POP sessions that will be decoded at any given instant. The default value for this option is 838860.
Note: It is suggested to set this value such that the max pop session calculated as follows is atleast 1.
max pop session = memcap /(2 * max of (b64_decode_depth, uu_decode_depth, qp_decode_depth or bitenc_decode_depth))
For example, if b64_decode_depth is 0 (indicates unlimited decoding) and qp_decode_depth is 100, then
max pop session = memcap/2*65535 (max value for b64_decode_depth)
In case of multiple configs, the memcap of the non-default configs will be overwritten by the default config's value. Hence user needs to define it in the default config with the new keyword disabled (used to disable POP preprocessor in a config).
When the memcap for decoding (memcap) is exceeded the POP preprocessor alert with sid 3 is generated (when enabled).</int>
-
Thanks mate!
I need to disable the pop normalizer to get rid of it. It seems the def. config gets overwritten on package updates and unless beeing able to edit it in the GUI, I just leave it alone since it takes quite some time on 52 boxes every time…. :(
-
Thanks mate!
I need to disable the pop normalizer to get rid of it. It seems the def. config gets overwritten on package updates and unless beeing able to edit it in the GUI, I just leave it alone since it takes quite some time on 52 boxes every time…. :(
Yep, any hand edits to the snort.conf file are overwritten on the next save or stop/start of Snort. I can add this parameter to the GUI and will look at doing so with the next update.
Bill
-
Exactly. :) Its a good idea so you wont have any trouble with any memcap triggering blocks of mail with no real scary scenarios…