Snort update coming soon – please read about an important change!

fragged

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.

drew134

@RonpfS:

@fragged:

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 packages

I'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. :)

vatson

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 2014

I 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 2014

Opened ~~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

fragged

Sounds like a log event from Snort's update check? Are you running the update check every 12 hours with a 30 minute offset?

vatson

@fragged:

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.

fragged

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.

Cino

@fragged:

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

turker

I cannot add manually suppress list.

(2.1.2-RELEASE (amd64), Snort2.9.6.0 pkg v3.0.6)

BBcan177

@turker:

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>

bmeeks

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

Cino

Welcome back Bill!!

armouredking

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 mode

This 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.

digdug3

This is a barnyard error. Are you using i386 or x64?

armouredking

@digdug3:

This is a barnyard error. Are you using i386 or x64?

x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.

bmeeks

@armouredking:

@digdug3:

This is a barnyard error. Are you using i386 or x64?

x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.

This version of the Snort package made some big changes to Barnyard2 like adding more output plugins. One side effect of that was it needed to reconfigure how the MySQL DB login info was stored. I wrote some code in the installation routines that attempts to migrate the old MySQL settings to the new format. It is possible some old settings could trip it up. Your error is a MySQL login error, and when the login fails Barnyard2 will stop. Go to the Barnyard tab in Snort and manually re-enter the login ID and password for the MySQL DB, then click Save. Try to start Barnyard2 after that on the Snort Interfaces tab.

Bill

Cino

@armouredking:

@digdug3:

This is a barnyard error. Are you using i386 or x64?

x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.

its a barnyard issue with the config i think. I comment out line 2030 in the snort.inc file:


config gen_file:            {$snortcfgdir}/gen-msg.map
# config hostname:            {$snortbarnyard_hostname_info}
config interface:           {$if_real}

then i added something like this to the advance config section in the gui


config hostname: pfsense_wan

i also noticed that I can only get barnyard2 to run on one interface… if I enabled it to 2 other interfaces, i get this error in the log shortly after it connects:


Apr 13 00:48:07 	barnyard2[54841]: ===============================================================================
Apr 13 00:48:07 	barnyard2[54841]: database: Closing connection to database "snort"
Apr 13 00:48:07 	barnyard2[54841]: Barnyard2 exiting
Apr 13 00:48:07 	barnyard2[54841]: FATAL ERROR: database mysql_error: Duplicate entry '26455-2' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('18176','26455','2');]
Apr 13 00:45:19 	barnyard2[8131]: ===============================================================================

i haven't had a chance to research it yet

bmeeks

@Cino:

@armouredking:

@digdug3:

This is a barnyard error. Are you using i386 or x64?

x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.

its a barnyard issue with the config i think. I comment out line 2030 in the snort.inc file:
config gen_file:            {$snortcfgdir}/gen-msg.map
# config hostname:            {$snortbarnyard_hostname_info}
config interface:           {$if_real}
then i added something like this to the advance config section in the gui
config hostname: pfsense_wan
i also noticed that I can only get barnyard2 to run on one interface… if I enabled it to 2 other interfaces, i get this error in the log shortly after it connects:
Apr 13 00:48:07 	barnyard2[54841]: ===============================================================================
Apr 13 00:48:07 	barnyard2[54841]: database: Closing connection to database "snort"
Apr 13 00:48:07 	barnyard2[54841]: Barnyard2 exiting
Apr 13 00:48:07 	barnyard2[54841]: FATAL ERROR: database mysql_error: Duplicate entry '26455-2' for key 'PRIMARY' SQL=[INSERT INTO sig_reference (ref_id,sig_id,ref_seq) VALUES ('18176','26455','2');]
Apr 13 00:45:19 	barnyard2[8131]: ===============================================================================
i haven't had a chance to research it yet

The "duplicate entry" error is a MySQL problem in the DB caused by the update to Barnyard2 to version 2.1.3. The sig_reference table has to be cleared. I have to be away for a few hours but will post a link with a fix when I get back.

Bill

BBcan177

Hello Bill,

Welcome Back!

A few questions/Comments in regards to the new Snort 2.9.6.0 pkg v3.0.6:

When I click the DNS resolv Icon, it loads the diag_dns.php page correctly, but when I click back, it sometimes displays "Confirm Form Resubmission" error? If I was on the LAN interface and view an alert it brings me back to the WAN interface in this scenario. (in Chrome)
I also noticed that when I rebooted pfSense and click on a Snort Interface to start it, it created duplicate pids per interface. At that time the IPrep alerts were not reporting but
other alerts were being alerted? On the Snort Interface page would it be beneficial to list the number of PIDS found?
With the addition of the IPrep processor there are a lot more alerts in the Alerts Tab, maybe for a later release you might incorporate a "filter button" as you had suggested previously.
What is the order of the processors? Does IPrep block before or after other processors/Rules?
A nice feature would be to report the BlockList name in the Alert window? Maybe this could be on the Block Page?

A single Block List file like this where the comment sections gets displayed beside the alert?

172.33.42.32/16 # Emerging Threats
58.253.234.59/32 # IBlock BadPeer
etc …

or multiple blocklist files and display the filename which is the Blocklist Name to display in the Block page?

Adding the DisplayIPlistStats to the Gui to show memory used and total entries loaded would be a good feature.

Apart from that, I have the IPrep processor running on 4 boxes. I am using my custom shell script to download all of the blocklists (including the Iblock list which is in an IP range format that IPrep cant use directly) and saving the single blocklist file in /var/db/snort/iprep and running the pkill -HUP snort command to restart all interfaces in the background. Cron is running the script as per its own scheduler.

I do notice that the snort2c file is not getting cleared anymore? Not sure if thats a fix in 2.1.2 or with not using pfBlocker anymore? To confirm 100% will need to let it run for several days to see if this continues.

Thanks again for all the Hard work you do to maintain these projects. We need to start a Vote for the best pfSense package Maintainer!! ;)

armouredking

@bmeeks:

@armouredking:

@digdug3:

This is a barnyard error. Are you using i386 or x64?

x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.

This version of the Snort package made some big changes to Barnyard2 like adding more output plugins. One side effect of that was it needed to reconfigure how the MySQL DB login info was stored. I wrote some code in the installation routines that attempts to migrate the old MySQL settings to the new format. It is possible some old settings could trip it up. Your error is a MySQL login error, and when the login fails Barnyard2 will stop. Go to the Barnyard tab in Snort and manually re-enter the login ID and password for the MySQL DB, then click Save. Try to start Barnyard2 after that on the Snort Interfaces tab.

Bill

Yeah, I'd believe that it was a caching thing or a transfer at the start but then I did this:

@armouredking:

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.

Gonna go out on a limb and say that it isn't a transfer issue. It simply isn't reading the configuration I gave it - the files I checked in Barynard's conf and the conf.xml for pfSense, as well as the GUI, are all pointing to the correct login but pfSense is still attempting to login with root and getting refused. Reentering the information by hand has no effect.

bmeeks

@armouredking:

Yeah, I'd believe that it was a caching thing or a transfer at the start but then I did this:

@armouredking:

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.

Gonna go out on a limb and say that it isn't a transfer issue. It simply isn't reading the configuration I gave it - the files I checked in Barynard's conf and the conf.xml for pfSense, as well as the GUI, are all pointing to the correct login but pfSense is still attempting to login with root and getting refused. Reentering the information by hand has no effect.

This one has me puzzled. I have Barnyard2 running on my production system and several test VM setups with no issues (both i386 and AMD64 and 2.0.3 and 2.1.2 systems). Do you have the login ID and IP address entered into the MySQL DB for Barnyard2? On the MySQL DB server, can you login to the database with the same credentials you are using on the pfSense box? It really should not be using "root" at all as that is not coded anywhere in the source code for the package.

Bill