Snort update coming soon – please read about an important change!
-
Snort package version was bumped because of the recent OpenSSL vulnerability by rbgarga.
Can you be more specific about differences between 3.0.5 and 3.0.6? I updated my secondary machine to 3.0.5 yesterday, now went to update the main machine and discovered yet another update… Now I wonder if I should hold off updating the main machine for 24h more.
-
It's exactly the same package, except the OpenSSL version bundled in the pbi is updated to one that has a fix to the heartbleed vulnerability. You will likely have to remove snort and install it again to get the updated pbi as the pbi version is exactly the same.
-
On the main Snort services page it says 3.0.5 after upgrading, yet the package installer confirms 3.0.6. I will assume that's just a typo, which brings me to a quick question for the group. Does anyone know a good method to check services version numbers easily? via command prompt, etc.?
Thank you in advance.
-
On the main Snort services page it says 3.0.5 after upgrading, yet the package installer confirms 3.0.6. I will assume that's just a typo, which brings me to a quick question for the group. Does anyone know a good method to check services version numbers easily? via command prompt, etc.?
Thank you in advance.
This happens literally every time someone other than Ermal or bmeeks touches the package. They always forget to change the version number within the Snort package files too.
-
It's exactly the same package, except the OpenSSL version bundled in the pbi is updated to one that has a fix to the heartbleed vulnerability. You will likely have to remove snort and install it again to get the updated pbi as the pbi version is exactly the same.
Did an upgrade, saw 3.0.5, uninstalled Snort , installed and still says
Services: Snort 2.9.6.0 pkg v3.0.5 in snort/snort_interfaces.php.
2.9.6.0 pkg v3.0.6 in Installed packagesI'm Running 2.0.3
-
Read my reply just before your last post.
There's an issue with the IP reputation files when using ramdisk for /tmp and /var. The file gets nuked on reboot and Snort wont start again until a rules download has been made to redownload the file.
snort[45934]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_330_em0/snort.conf(398) => Unable to open address file /var/db/snort/iprep/emerging-compromised-ips.txt, Error: No such file or directory -
I upgraded one of my boxes to 2.1.2
I was on 2.0.3 previously. I also didn't upgrade to the newest snort and suricata versions on this box.
All of the pfSense functionality was restored properly. However Suricatas interfaces are completely missing.
Snort came online by itself without any issues. Once I enabled the IP Rep Processor, it shutdown the Snort WAN interface and this error in the logs-
snort[66223]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_43799_rl0//usr/pbi/snort-amd64/etc/snort/snort_43799_rl0/rules/snort.rules(0) Unable to open rules file
"/usr/pbi/snort-amd64/etc/snort/snort_43799_rl0//usr/pbi/snort-amd64/etc/snort/snort_43799_rl0/rules/snort.rules": No such file or directory.I restarted the Snort WAN interface and it came back up without issue.
Snort picked up this IP and blocked it. It is also in the pfBlocker lists, so Snort must be at the top of the foodchain in pf.
snort[94646]: [136:1:1] (spp_reputation) packets blacklisted [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 116.10.191.165:6000 -> x.x.x.x.x.x.x
Using the Snort VRT and ET Pro rulesets.
EDIT: pfBlocker also listed it in the Firewall Logs
Apr 10 18:02:18 WAN USER_RULE pfBlocker ET (@77) 116.10.191.165:6000 TCP:S
-
Snort runs the interface in promiscuous mode, which means that it will see all traffic passing through it. Also Snort on pfSense works with a copy of all the traffic coming to the interface, so it will also see traffic that was actually blocked by pf (firewall rules). Snort on pfSense doesn't work in an inline mode.
-
It's exactly the same package, except the OpenSSL version bundled in the pbi is updated to one that has a fix to the heartbleed vulnerability. You will likely have to remove snort and install it again to get the updated pbi as the pbi version is exactly the same.
Did an upgrade, saw 3.0.5, uninstalled Snort , installed and still says
Services: Snort 2.9.6.0 pkg v3.0.5 in snort/snort_interfaces.php.
2.9.6.0 pkg v3.0.6 in Installed packagesI'm Running 2.0.3
I figured that was the case, but I am curious if there is a method that I am not thinking of in regards to checking service versions numbers… for example, I would like to verify today's OpenVPN version update number... I am sure it's easy... just not thinking of it. Thank you for checking on your end as well. :)
-
I updated one of my pfSense systems to snort pkg v 3.0.6 last night. Logging in this morning, I saw this in Status: Dashboard:
Last config change Fri Apr 11 0:30:23 EEST 2014I definitely did not make any config changes at that time, nor was anybody logged in if system logs are to be believed. But this coincides with the time of Snort rules update. Coincidence? My other systems which are still on Snort pkg 3.0.4 (but same version of pfSense and other packages) don't seem to behave like this. One other thing that is different is that on this system Snort is configured to block offenders, while my other systems have this option turned off.
In the afternoon I checked Status: Dashboard again, and Last config change is now:
Fri Apr 11 12:31:01 EEST 2014Opened
https://redmine.pfsense.org/issues/3600(rejected)Looking at Diagnostics: Configuration History shows the following:
4/11/14 12:31:01 9.8 (system): made unknown change
4/11/14 00:30:23 9.8 (system): made unknown change -
Sounds like a log event from Snort's update check? Are you running the update check every 12 hours with a 30 minute offset?
-
Sounds like a log event from Snort's update check? Are you running the update check every 12 hours with a 30 minute offset?
Yes, I am. To clarify, I run 5 pfSense systems, 4 of them have Snort package v3.0.4, one has v3.0.6. Updating settings are the same on all 5 systems - start time 00:30, interval 12 hours. Only the system with Snort package 3.0.6 changed its 'Last config change' timestamp today at 00:30 and 12:30.
As I don't have much experience with running Snort on pfSense, I may be confused here. Maybe this behaviour - considering automatic Snort rules update a 'config change' - is actually expected and the previous behaviour of 3.0.4 not updating the 'Last config change' timestamp was a regression in pkg 3.0.4? I myself have been thinking that 'Last config change' should show when someone manually changed the configuration.
-
It 's a change with the 3.0.5 package version, which has the new Snort binary also. It can now reload Snort config on the fly instead of restarting Snort completely when you change the rules settings etc.
-
It 's a change with the 3.0.5 package version, which has the new Snort binary also. It can now reload Snort config on the fly instead of restarting Snort completely when you change the rules settings etc.
Bill would have to correct me but with this new snort package, a new binary ver was used. Which I think uses a different rule set (probably why ET Web Client has an issue).
I wish the core team contacted Bill before approving the changes since he normally starts a new tread with each release since he started to maintain the package. Right now we're using the head-ups thread he started but I haven't seen Bill online for a week.
running on 2.1.2 i386
]/root(2): snort --v ,,_ -*> Snort! <*- o" )~ Version 2.9.6.0 GRE (Build 47) FreeBSD '''' By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team Copyright (C) 2014 Cisco and/or its affiliates. All rights reserved. Copyright (C) 1998-2013 Sourcefire, Inc., et al. Using libpcap version 1.5.2 Using PCRE version: 8.34 2013-12-15 Using ZLIB version: 1.2.3 -
I cannot add manually suppress list.
(2.1.2-RELEASE (amd64), Snort2.9.6.0 pkg v3.0.6)
-
I cannot add manually suppress list.
(2.1.2-RELEASE (amd64), Snort2.9.6.0 pkg v3.0.6)
Can you be more specific on how you are trying to suppress an alert? or adding a suppress list?
To add a list. SNORT:Suppress click on the '+' to add a new suppress list. Make one for each interface.
SNORT:Snort Interfaces: <edit each="" interface="">, scroll down to "Choose a suppression or filtering file if desired" Click the down arrow to the correct suppress list.
From the Alerts page (Source or Destination) clicking on the '+' icon will add to the suppress list.</edit>
-
Hi guys:
I am back from my holiday and will look into the posted issues later this weekend. Need tonight (Saturday in U.S. Eastern Time Zone) to recover from the vacation. At first glance, the "pcre compile" error would seem to point to a problem with the ET OPEN rule itself since all other rules seem OK and just one rule goes bonkers.
This is a new Snort binary and thus will download the Snort rule set matched to it (2.9.6.0 for now). The ET OPEN rule set is not version dependent. Any Snort version greater than 2.9.0 is OK.
The GUI package version is hard-coded in a variable in the snort.inc file. It is for display purposes only in the title. I can post a quick fix for that.
Bill
-
Welcome back Bill!!
-
So, having issues with Snort again. Been running rather well up until the 2.1.2 update. Now it's back to not working at all.
At first the issue was the same as before, that being the signature errors I mentioned in a previous thread. So I used truncate, that helped but didn't fix, so I did what I did last time to correct it and wiped the DB clean again. Now the communication begins again, everything looks clean, I reboot for a sanity check and….
Apr 13 01:13:56 barnyard2[84684]: Barnyard2 exiting Apr 13 01:13:56 barnyard2[84684]: database mysql_error: Access denied for user 'root'@'domain.com' (using password: YES) Apr 13 01:13:56 barnyard2[84684]: Writing PID "84684" to file "/var/run/barnyard2_em055759.pid" Apr 13 01:13:56 barnyard2[84684]: PID path stat checked out ok, PID path set to /var/run Apr 13 01:13:56 barnyard2[84684]: Daemon initialized, signaled parent pid: 84444 Apr 13 01:13:56 barnyard2[84444]: Daemon parent exiting Apr 13 01:13:56 barnyard2[84444]: Initializing daemon modeThis happens.
Okay, whiskey-tango-foxtrot. Why you use root, pfSense? Root is not a configured user. Anywhere. Seems like a really simple error, but the error has me table bashing my skull as I can't figure out where the directive is coming from. I won't allow root to connect to my MySQL production server unless I'm physically needing it. So that's why it isn't working now. However, pfSense is absolutely determined that it will never connect under anything else. I have checked manually the files ( both Snort's pbi barnyard config files and pfSense overall config ), and they match what is currently shown in the webgui ( that is to say, with the normal dbuser configured for the Snort db ).
In desperation following a remove / install of Snort still facing the same issues, I cleanwiped the drive and reinstalled pfSense from scratch - that is to say, clean from a CD with no imports from a previous config file, everything reentered by hand - and the error remains the same. pfSense is determined to use root only root and nothing but root, and I'm not gonna let it; especially when everything says it should be using the proper user that for some reason it is ignoring.
-
This is a barnyard error. Are you using i386 or x64?
