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

bmeeks

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

The Snort package periodically writes configuration info to the config.xml file depending on what internal process may be going on. It does not "tag" its updates with a Snort identifier. That is something I can add as an enhancement in a later release.

What is happening in this specific instance is the daily update check for new rules is writing the "status" and "time" to the configuration file so it is persisted. This is new information that is displayed on the UPDATES tab. It shows the last time Snort checked for updated rules packages and what the result was: "success" or "fail". Since I have to make some other fixes anyway, I will add some tags to these updates so they don't say "…made unknown change..". I agree that can be an unnerving message… ;)

Bill

bmeeks

@fragged:

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

Oops! Looks like I need to find another way to handle this for ramdisk users. I run regular images so I have no experience with the ramdisk setup. Got any suggestions for how handle this?

Bill

bmeeks

@turker:

I cannot add manually suppress list.

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

This bug is fixed and the updated code will be posted in a Pull Request in the next day or two.

Bill

bmeeks

@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

I was out of the country on vacation when the Pull Request was accepted. The timing was unfortunate. Normally the reviews have been taking a little time to complete, so I posted the Pull Request a couple of days before I left expecting it to take about the same length of time as some previous ones for approval. I was expecting to be back home well before the request was approved. This time the Core Developers approved it more quickly. That is good, but unfortunately I did not have time to post my normal RELEASE NOTES. I will catch up and do that when I post the fixes for the identified bugs in the next day or so.

Bill

condector

he "duplicate entry" error is a problem with Barnyard 2.1.3 and the fix is to clear out the entire sig_reference table. It will be repopulated when Barnyard2 starts up again.

Stop all Barnyard2 processes.
Login to the MySQL server and login to the database in question.
Issue the command:
Code: [Select]
DELETE FROM sig_reference;
Restart a single Barnyard2 process first and let it completely start up.
Now start any additional processes.

Bill

This work for few moments and go down…

fragged

I keep seeing warnings like this by barnayard2 in the system log:


Apr 15 07:46:22 	barnyard2[30475]: WARNING database [Database()]: End of failed transaction block
Apr 15 07:46:22 	barnyard2[30475]: WARNING database: Failed Query Position [4] Failed Query Body [INSERT INTO data (sid,cid,data_payload) VALUES (1,1181,'4873010000010000000000010331783102637A0000FF0001000029FFFF000000000000');]
Apr 15 07:46:22 	barnyard2[30475]: WARNING database: Failed Query Position [3] Failed Query Body [INSERT INTO iphdr (sid, cid, ip_src, ip_dst, ip_ver, ip_hlen, ip_tos, ip_len, ip_id, ip_flags, ip_off,ip_ttl, ip_proto, ip_csum) VALUES (1,1181,1347571305,1356855242,4,5,40,63,0,0,0,55,17,23585);]
Apr 15 07:46:22 	barnyard2[30475]: WARNING database: Failed Query Position [2] Failed Query Body [INSERT INTO udphdr (sid, cid, udp_sport, udp_dport, udp_len, udp_csum) VALUES (1, 1181, 34104, 53, 43, 10122);]
Apr 15 07:46:22 	barnyard2[30475]: WARNING database: Failed Query Position [1] Failed Query Body [INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 1181, 477, '2014-04-15 07:46:16');]
Apr 15 07:46:22 	barnyard2[30475]: WARNING database: [Database()] Failed transaction with current query transaction
Apr 15 07:46:22 	barnyard2[30475]: [Database()]: Insertion of Query [INSERT INTO event (sid,cid,signature,timestamp) VALUES (1, 1181, 477, '2014-04-15 07:46:16');] failed

I checked the database and this particular event was successfully inserted into the database. ~~I've also spotted a few instances where classification_id and user_id is NULL.~~ (This is actually filled by Snorby, not Barnyard2)

simby

bmeeks: ki can you please add to only drop packet, and not to block or/and add 1 min block time?

fragged

@simby:

bmeeks: ki can you please add to only drop packet, and not to block or/and add 1 min block time?

Having Snort to drop packages is currently not possible as Snort doesn't work in a true inline mode.

bmeeks

@simby:

bmeeks: ki can you please add to only drop packet, and not to block or/and add 1 min block time?

As fragged says, Snort cannot currently operate in inline mode on pfSense. And even if it did, the packet throughput would be adversely impacted compared to the current libpcap arrangement. This is because network traffic would have to be context-switched from kernel space to user space, inspected, and then either dropped or sent back down from user space to kernel space to continue through the network stack. This context switching is not very efficient. One of the pfSense Core Developers told me that with true inline mode using Snort or Suricata the top throughput before lag became a serious issue was in the 50-100 megabit/sec range (depending on the hardware used). For some folks that would be OK, but for many others that level of throughput would not be sufficient.

I am planning to try and offer inline mode as an option, but with the big caveat that throughput will be limited in that mode. Unfortunately true inline mode also requires some changes to the pfSense kernel, so that means it can't happen with the current releases.

Bill

bmeeks

@condector:

he "duplicate entry" error is a problem with Barnyard 2.1.3 and the fix is to clear out the entire sig_reference table. It will be repopulated when Barnyard2 starts up again.

Stop all Barnyard2 processes.
Login to the MySQL server and login to the database in question.
Issue the command:
Code: [Select]
DELETE FROM sig_reference;
Restart a single Barnyard2 process first and let it completely start up.
Now start any additional processes.

Bill

This work for few moments and go down…

There are lots of complaints on the Google lists about these kinds of Barnyard2 errors. I'm not a Barnyard2 expert, but apparently some significant database changes were made with the last Barnyard2 update (which Snort and Suricata are now using on pfSense). These changes result in these kinds of errors. I will research some more to see if I can come up with a solution. In the meantime, do some Google searches on those errors and you should come across several solutions posted by the Barnyard2 developers. The solutions involve running some complicated SQL scripts directly in the database.

I posted some links a couple of months ago to an excellent set of scripts that fixed the problem for me. I will see if I can find my old post and update this thread with it. The root cause here is having old Barnyard2 tables and data in the MySQL database but using the new Barnyard2 binary.

I think this also is a problem when multiple Barnyard2 processes are sharing the same DB. I don't know what the Barnyard2 developers did to cause this, but I agree it is irritating.

Bill

gscasny

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

I had this exact issue (along with continuing "Duplicate Entry" issues), but to fix it, I removed the "Sensor Name" in the Barnyard2 portion of the web gui. This corrected barnyard2 logging in as root. I was able to repeat the issue and correct it by adding a name to the "Sensor Name" - broke, and then removing it.. fixed.

gscasny

@bmeeks:

@condector:

he "duplicate entry" error is a problem with Barnyard 2.1.3 and the fix is to clear out the entire sig_reference table. It will be repopulated when Barnyard2 starts up again.

Stop all Barnyard2 processes.
Login to the MySQL server and login to the database in question.
Issue the command:
Code: [Select]
DELETE FROM sig_reference;
Restart a single Barnyard2 process first and let it completely start up.
Now start any additional processes.

Bill

This work for few moments and go down…

There are lots of complaints on the Google lists about these kinds of Barnyard2 errors. I'm not a Barnyard2 expert, but apparently some significant database changes were made with the last Barnyard2 update (which Snort and Suricata are now using on pfSense). These changes result in these kinds of errors. I will research some more to see if I can come up with a solution. In the meantime, do some Google searches on those errors and you should come across several solutions posted by the Barnyard2 developers. The solutions involve running some complicated SQL scripts directly in the database.

I posted some links a couple of months ago to an excellent set of scripts that fixed the problem for me. I will see if I can find my old post and update this thread with it. The root cause here is having old Barnyard2 tables and data in the MySQL database but using the new Barnyard2 binary.

I think this also is a problem when multiple Barnyard2 processes are sharing the same DB. I don't know what the Barnyard2 developers did to cause this, but I agree it is irritating.

Bill

Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.

bmeeks

@gscasny:

Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.

I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0

Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.

Bill

gscasny

@bmeeks:

@gscasny:

Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.

I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0

Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.

Bill

Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..

Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.

The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.

bmeeks

@gscasny:

@bmeeks:

@gscasny:

Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.

I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0

Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.

Bill

Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..

Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.

The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.

Thanks for the feedback on the sensor name anomaly. I will look into that. Could be I have a mistake in the code someplace. I know I never coded "root" by design, but I do have fat fingers when typing… :(

Bill

gscasny

@bmeeks:

@gscasny:

@bmeeks:

@gscasny:

Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.

I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0

Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.

Bill

Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..

Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.

The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.

Thanks for the feedback on the sensor name anomaly. I will look into that. Could be I have a mistake in the code someplace. I know I never coded "root" by design, but I do have fat fingers when typing… :(

Bill

Anytime, and anything I can do to help…

The first link you posted fixed the duplicate entry issue - BUT - although I now see events in Snorby, the dashboard is not showing any events, but when I look at events or sensors is shows all the events (I have a few thousand events now).. any ideas?

BBcan177

Hi gscasny,

Did you do a full Security Onion install or is this a Virtual Machine ISO boot?

Would be interested to know the steps you took to get pfSense to SO working?

Are the alerts visible in SGUIL or just Snorby?

Appreciate any info you can share.

Thanks in advance.

gscasny

@BBcan17:

Hi gscasny,

Did you do a full Security Onion install or is this a Virtual Machine ISO boot?

Would be interested to know the steps you took to get pfSense to SO working?

Are the alerts visible in SGUIL or just Snorby?

Appreciate any info you can share.

Thanks in advance.

It's a full install. It's a "Server" install from the "Advanced" install as I run Snort on our edge FW's as sensors. I am logging only to Snorby at the moment, as SGUIL is on my list after OSSEC as we currently use OSSEC at client sites but not via Sec onion…. it bums me a little that SGUIL X windows application only... But I am happy to share any/all info I find out..

BBcan177

S.O. is great. I have OSSEC running on all of my Windows and Linux servers (Works really slick) Let me know if you need any help with that.

I run Snort on our edge FW's as sensors.

Are these SO sensors or pfSense snort?

I'm not sure what you mean by "SGUIL X windows application only"?

gscasny

@BBcan17:

S.O. is great. I have OSSEC running on all of my Windows and Linux servers (Works really slick) Let me know if you need any help with that.

I run Snort on our edge FW's as sensors.

Are these SO sensors or pfSense snort?

I'm not sure what you mean by "SGUIL X windows application only"?

The sensors are our build of pfsense.

SGUIL X win only - meaning I have to run the interface in X, instead of via a web interface like Snorby or ELSA (which I don't use..we use a SIEM product for log storage and correlation)..

I really like OSSEC as a host ids.. we have a few installs, but I am looking to standardize the deployment and monitoring of OSSEC along with our IDS sensors and SIEM…