Snort update coming soon – please read about an important change!
-
Thats not necessary on 2.0.3
Just for your info. Emerging web client rules works fine.
-
Maybe this is a memory issue? How much memory are you guys using? Did you enable the same amount of rules on the WAN and LAN interface?
-
Looks like I'm running those rules just fine too on pfSense 2.1.1 and the latest package version. I have 8 GB of memory with over 6 GB free.
-
@BBcan17:
Maybe this is a memory issue? How much memory are you guys using? Did you enable the same amount of rules on the WAN and LAN interface?
System says I'm using 21% of the 4GB on board.
for Supermule: On the previous package, the Emerging Web Client rules worked fine. I double checked on a backup system I keep ready to go. It only fails on this new package.
EDIT
I've updated to pfsense 2.1.1. Update reinstalled all packages fine. Services/Snort still says v3.0.5, Installed packages shows v3.0.6… so not sure really what version is running.Snort will only start if "emerging-web_client.rules" is unchecked.
Rick
-
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>
