Snort 2.9.4.1 pkg v. 2.5.6 Issue(s)
-
Bill,
The same problem happened on a VM upgrading to the latest 2.1 snapshot of today (2.1-BETA1 (i386) built on Mon Apr 22 04:52:29 EDT 2013)
Maybe something changed in the snapshots? I don't know, you are the expert, at least relative to me. ;)Edit: tried again in VM, but now I deinstalled Snort first before updating pfSense. After the update I installed Snort again and that went ok. Remember that this procedure (automatic update without deinstalling snort first) went ok with package version 2.5.5 and I don't see any commits at first sight that it is a change in the snapshots.
I have been able to replicate this with my 2.1-BETA virtual machines. I am working on a solution. This one is a bit vexing because of the multiple steps involved with a firmware update (a new snapshot) and a Snort package upgrade. What goes wrong is the test for the proper PBI directory for Snort, so then the rules get installed to the wrong place and it goes downhill from there… :( I will get it whipped, but I need another day or two.
In the meantime, for folks having issues with the 2.1-BETA snapshot updates, follow this routine:
1. First make sure you have Snort configured to save settings on uninstall (on the Global Settings tab).
2. BEFORE updating your snapshot uninstall Snort by clicking the "X" on the Installed Packages tab.
3. Upgrade to the latest snapshot and THEN reinstall Snort from the Available Packages tab.I know this is a pain, but hopefully it will be temporary.
Bill
-
Thunks up!!!
I just submitted a Pull Request containing the Snort Dashboard Widget fix for correctly displaying timestamps containing the YEAR. I also included logic to detect when the Snort package itself is not installed, but the Dashboard Widget is still installed, to prevent a crash of the GUI. It will now print a message in the alerts table within the widget that Snort is not installed.
Bill
-
Thunks up!!!
I just submitted a Pull Request containing the Snort Dashboard Widget fix for correctly displaying timestamps containing the YEAR. I also included logic to detect when the Snort package itself is not installed, but the Dashboard Widget is still installed, to prevent a crash of the GUI. It will now print a message in the alerts table within the widget that Snort is not installed.
Bill
Thanks!
-
Folks:
I think we may be narrowing down the list of open issues in the current Snort package version 2.5.6. Here are items that I am aware of still open. Actually I think these are all holdovers from the 2.5.5 package. I have working fixes for these in my current test environment. I just want to be sure I've caught everything major before I push out a 2.5.7 package update.
OPEN ISSUES
1. Snort not saving edits to the Rules Update and Remove Blocked Offenders cron jobs.
2. Snapshot updates on 2.1-BETA systems do not fully complete the Snort rules update post-upgrade and Snort does not start until a manual rules update is performed.
3. Snort not auto-starting after a package reinstall with prior saved settings.
Did I miss any big ones in my list? I wanted to double-check and see if anything else was lurking out there before pushing another update.
Bill
-
Got this on only one of the box'es.
Apr 23 00:09:08 php: : The Rules update has finished.
Apr 23 00:09:08 php: : Snort has restarted with your new set of rules…
Apr 23 00:09:06 SnortStartup[54291]: Snort START For Internet(36256_em0)…
Apr 23 00:09:06 kernel: em0: promiscuous mode enabled
Apr 23 00:07:25 snort[40906]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 23 00:07:25 snort[40906]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 23 00:07:25 kernel: em0: promiscuous mode disabled
Apr 23 00:07:25 snort[40906]: *** Caught Term-Signal
Apr 23 00:07:25 snort[40906]: *** Caught Term-Signal
Apr 23 00:07:24 SnortStartup[2845]: Snort STOP For Internet(36256_em0)…
Apr 23 00:07:24 php: : Building new sig-msg.map file for WAN...
Apr 23 00:07:21 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 23 00:07:20 php: : Updating rules configuration for: WAN ...
Apr 23 00:07:19 php: : EmergingThreats rules file update downloaded succsesfully
Apr 23 00:07:16 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 23 00:07:16 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 23 00:07:14 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 23 00:07:13 php: : Failed Rules Filesize: 0
Apr 23 00:07:13 php: : Snort VRT rules file download failed...
Apr 23 00:07:13 php: : Snort Rules Attempts: 5
Apr 23 00:03:05 php: : There is a new set of Snort VRT rules posted. Downloading...
Apr 23 00:03:05 php: : Snort MD5 Attempts: 1Its the one running Version 2.5.5
The one running 2.5.6 says:
Apr 23 00:03:23 php: : The Rules update has finished.
Apr 23 00:03:23 php: : Emerging Threat rules are up to date...
Apr 23 00:03:22 php: : Snort GPLv2 Community Rules are up to date...
Apr 23 00:03:22 php: : Snort VRT rules are up to date...
Apr 23 00:03:22 php: : Snort MD5 Attempts: 1I find it a bit weird that the rules are up to date since one of the FW reports new rules are available.....?
-
Folks:
I think we may be narrowing down the list of open issues in the current Snort package version 2.5.6. Here are items that I am aware of still open. Actually I think these are all holdovers from the 2.5.5 package. I have working fixes for these in my current test environment. I just want to be sure I've caught everything major before I push out a 2.5.7 package update.
OPEN ISSUES
1. Snort not saving edits to the Rules Update and Remove Blocked Offenders cron jobs.
2. Snapshot updates on 2.1-BETA systems do not fully complete the Snort rules update post-upgrade and Snort does not start until a manual rules update is performed.
3. Snort not auto-starting after a package reinstall with prior saved settings.
Did I miss any big ones in my list? I wanted to double-check and see if anything else was lurking out there before pushing another update.
Bill
Thats it! After that I will submit my wish list. ;)
-
I had my first ruleset update from ET, not Snort VRT and the "stop-start" sequence looks ok now.
Apr 23 06:04:20 kernel: em0: promiscuous mode enabled Apr 23 06:04:20 SnortStartup[79922]: Snort START For WAN(54477_em0)... Apr 23 06:03:45 kernel: em0: promiscuous mode disabled Apr 23 06:03:45 snort[80791]: *** Caught Term-Signal Apr 23 06:03:44 SnortStartup[61056]: Snort STOP For WAN(54477_em0)...35 seconds between those two commands.
-
Folks:
I think we may be narrowing down the list of open issues in the current Snort package version 2.5.6. Here are items that I am aware of still open. Actually I think these are all holdovers from the 2.5.5 package. I have working fixes for these in my current test environment. I just want to be sure I've caught everything major before I push out a 2.5.7 package update.
OPEN ISSUES
1. Snort not saving edits to the Rules Update and Remove Blocked Offenders cron jobs.
2. Snapshot updates on 2.1-BETA systems do not fully complete the Snort rules update post-upgrade and Snort does not start until a manual rules update is performed.
3. Snort not auto-starting after a package reinstall with prior saved settings.
Did I miss any big ones in my list? I wanted to double-check and see if anything else was lurking out there before pushing another update.
Bill
I believe thats all the open issues atm.. Anything else that was mentioned was wish list type adds.
Thats all
-
Got this on only one of the box'es.
Apr 23 00:09:08 php: : The Rules update has finished.
Apr 23 00:09:08 php: : Snort has restarted with your new set of rules…
Apr 23 00:09:06 SnortStartup[54291]: Snort START For Internet(36256_em0)…
Apr 23 00:09:06 kernel: em0: promiscuous mode enabled
Apr 23 00:07:25 snort[40906]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 23 00:07:25 snort[40906]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 23 00:07:25 kernel: em0: promiscuous mode disabled
Apr 23 00:07:25 snort[40906]: *** Caught Term-Signal
Apr 23 00:07:25 snort[40906]: *** Caught Term-Signal
Apr 23 00:07:24 SnortStartup[2845]: Snort STOP For Internet(36256_em0)…
Apr 23 00:07:24 php: : Building new sig-msg.map file for WAN...
Apr 23 00:07:21 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 23 00:07:20 php: : Updating rules configuration for: WAN ...
Apr 23 00:07:19 php: : EmergingThreats rules file update downloaded succsesfully
Apr 23 00:07:16 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 23 00:07:16 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 23 00:07:14 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 23 00:07:13 php: : Failed Rules Filesize: 0
Apr 23 00:07:13 php: : Snort VRT rules file download failed...
Apr 23 00:07:13 php: : Snort Rules Attempts: 5
Apr 23 00:03:05 php: : There is a new set of Snort VRT rules posted. Downloading...
Apr 23 00:03:05 php: : Snort MD5 Attempts: 1Its the one running Version 2.5.5
The one running 2.5.6 says:
Apr 23 00:03:23 php: : The Rules update has finished.
Apr 23 00:03:23 php: : Emerging Threat rules are up to date...
Apr 23 00:03:22 php: : Snort GPLv2 Community Rules are up to date...
Apr 23 00:03:22 php: : Snort VRT rules are up to date...
Apr 23 00:03:22 php: : Snort MD5 Attempts: 1I find it a bit weird that the rules are up to date since one of the FW reports new rules are available.....?
The 2.5.5 box is failing to actually update the rules, so it never writes an updated MD5 file with the new hash. You can compare the hash values shown for the rules on the two boxes. It's on the Update tab.
Bill
-
I had my first ruleset update from ET, not Snort VRT and the "stop-start" sequence looks ok now.
Apr 23 06:04:20 kernel: em0: promiscuous mode enabled Apr 23 06:04:20 SnortStartup[79922]: Snort START For WAN(54477_em0)... Apr 23 06:03:45 kernel: em0: promiscuous mode disabled Apr 23 06:03:45 snort[80791]: *** Caught Term-Signal Apr 23 06:03:44 SnortStartup[61056]: Snort STOP For WAN(54477_em0)...35 seconds between those two commands.
Yep, that shows the shutdown took some time on your box. I think this long shutdown process was creating a sort of race condition like I explained earlier where it actually was detecting the shutting down (but still running) Snort process and sent it a soft restart command instead of waiting for the shutdown to complete and doing a cold start. Because Snort was in the process of shutting down in response to the STOP command, it ignored the soft restart. So at the end you were left with no running Snort process.
Now the STOP part of the script waits until Snort is actually dead before proceeding to call the START code.
Bill
-
Noticed that the dashboard widget is showing that snort is active (and it is) but when I look at the snort service the screen shows that it needs to be started.
-
No no its running! it says enabled….
-
The "Play" button (seen in cjbujold's image) means it needs to be started, the "X" means it's running and clicking it stops Snort.
This is enabled and running:
-
Could it be a cache problem in the browser??
I have the same here where it says enabled and running, but showing the stop icon.
-
Could it be a cache problem in the browser??
I have the same here where it says enabled and running, but showing the stop icon.
The icon in your screen image is correct. It means Snort is running. Ermal made a change to the icons last year. The new scheme alters the icon depending on what you can do. When it's the Green Arrow, that means Snort needs starting (that is, it is stopped). The Red X icon means that Snort can be stopped (or in other words, it is currently running). Can be a little counterintuitive at first, but you get used to it.
The ENABLED text simply means Snort and/or Barnyard2 is turned on for the interface. It does not necessarily mean they are currently running. If you uncheck the Enable check box on the If Settings tab for a given interface, then the text on this screen will change to DISABLED.
Bill
-
Noticed that the dashboard widget is showing that snort is active (and it is) but when I look at the snort service the screen shows that it needs to be started.
This mismatch was reported by some folks last year if I recall correctly. Did you do a
```
ps -ax | grep snortfrom the command line to be sure a Snort process is actually running? There should be an instance of Snort running for each ENABLED interface (where Snort is enabled on the interface). Each Snort process will have some arguments that include the UUID for the interface so you can tell them apart. One more thing to try. Do a browser page refresh on that **Snort Interfaces** tab screen and see if perhaps the icon will change to the Red X indicating Snort is running. Bill -
We need a Snort bloq :D
Could it be a cache problem in the browser??
I have the same here where it says enabled and running, but showing the stop icon.
The icon in your screen image is correct. It means Snort is running. Ermal made a change to the icons last year. The new scheme alters the icon depending on what you can do. When it's the Green Arrow, that means Snort needs starting (that is, it is stopped). The Red X icon means that Snort can be stopped (or in other words, it is currently running). Can be a little counterintuitive at first, but you get used to it.
The ENABLED text simply means Snort and/or Barnyard2 is turned on for the interface. It does not necessarily mean they are currently running. If you uncheck the Enable check box on the If Settings tab for a given interface, then the text on this screen will change to DISABLED.
Bill
-
@bmeeks: Thanks again for your great efforts on this package.
For me there is still one open point: under 2.1 beta snort 2.5.5 I am still not able to save custom rules in the custom.rules form under categories.
The generated file stays empty.Best wishes, Judex
-
@bmeeks: Thanks again for your great efforts on this package.
For me there is still one open point: under 2.1 beta snort 2.5.5 I am still not able to save custom rules in the custom.rules form under categories.
The generated file stays empty.Best wishes, Judex
This works for me. On the RULES tab for the interface in Snort, there is now an Apply Changes button. You must click that button to actually build the rules from the files you have selected on that tab (including any custom rules).
I think this works in 2.5.5, but I know it works in 2.5.6.
Bill
-
Thank you for clearing that up. I did not realize that "Apply Changes" button before and thought saving would be enough.
However, when I put in a rule like this on for example:alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (flags:S; flow: stateless; detection_filter:track by_src, count 200, seconds 5; msg:"SYN flood attack detected!"; classtype:attempted-dos; sid:1000002; rev:1;)
without quotes I get an error. If I put it in with quotes it gets saved but with carriage returns in the custom rules file. The interface fails to start afterwards.
Am I doing something else wrong?
The rule works great if I load it via the "include my.rules" in the advanced processing options of the specific interface, and put a file called my.rules in the interface directory of course.Alex
BTW: I am already using 2.5.6
