Snort 2.9.4.1 pkg v. 2.5.6 Issue(s)
-
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
-
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
I will use your rule for my troubleshooting. It should work, but the text you type in the text area is run through a Base64 encode before being stored in the config file. It's then extracted via a Base64 decode before going into the custom.rules file. That process may be altering the format. This is a part of the Snort package I did not write and have never toyed with before, so I will have to tread carefully.
As for the Apply Changes button, that actually performs the rules file generation from all the selected rules. All Save does is save the choices (or custom rules) into the config.xml file of pfSense. Apply Changes actually calls the rules building routine, and at that point any custom rules stored in config.xml get physically written to the custom.rules file.
Bill
-
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.
Alex
Alex:
I copied and pasted your rule exactly as shown in your post into the "custom.rules" dialog on one of my 2.0.3 test virtual machines. I then did a Save and then Apply Changes to actually generate the rules file. I opened the resulting custom.rules file and it was fine (no carriage returns). I then restarted Snort on the affected interface (WAN on my test VM), and it restarted just fine.
UPDATED: While executing my various testing scenarios for the upcoming 2.5.7 release, I believe I stumbled upon your issue with the Apply Changes button when using Custom Rules. The short version is "the button ain't there" when editing Custom Rules. It only shows up when editing the Rules Categories. My bad… :-[ I just made some changes that will be in the upcoming 2.5.7 release to address this shortcoming. The [b]Save button on the Custom Rules dialog will now save the custom rules and generate the correct file in the interface's directory. I also added a Clear button that lets you just instantly clear out all the custom rules for the interface at once and then regenerate the enforcing rules file again.
First up, I am in the US and using the standard US English locale settings. Is that what you are using, or do you maybe have a different language or keyboard layout in your environment?
Try pasting your rule again directly from your post above into your firewall and repeat what I did. Let me know how that goes for you. Your rule as written in your original post is correct and looks fine. Without the quotes would be incorrect syntax, so that's why the error is thrown. The dialog actually passes your custom rule text off to Snort for validation before saving it. If Snort balks at the syntax, then an error is thrown requiring the user to fix it before saving.
Bill
-
Box 1:
Apr 25 00:08:04 php: : The Rules update has finished.
Apr 25 00:08:04 php: : Snort has restarted with your new set of rules…
Apr 25 00:08:02 kernel: em0: promiscuous mode enabled
Apr 25 00:08:02 SnortStartup[21448]: Snort START For Internet(9626_em0)…
Apr 25 00:06:14 kernel: em0: promiscuous mode disabled
Apr 25 00:06:14 snort[52077]: *** Caught Term-Signal
Apr 25 00:06:14 snort[52077]: *** Caught Term-Signal
Apr 25 00:06:13 SnortStartup[6666]: Snort STOP For Internet(9626_em0)…
Apr 25 00:06:12 php: : Building new sig-msg.map file for WAN...
Apr 25 00:06:10 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 25 00:06:08 php: : Updating rules configuration for: WAN ...
Apr 25 00:06:07 php: : EmergingThreats rules file update downloaded succsesfully
Apr 25 00:06:05 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 25 00:06:04 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 25 00:06:03 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 25 00:06:03 php: : Snort VRT rules are up to date...
Apr 25 00:06:03 php: : Snort MD5 Attempts: 3Box 2:
Apr 25 00:03:49 php: : The Rules update has finished.
Apr 25 00:03:49 php: : Emerging Threat rules are up to date...
Apr 25 00:03:48 php: : Snort GPLv2 Community Rules are up to date...
Apr 25 00:03:47 php: : Snort VRT rules are up to date...
Apr 25 00:03:47 php: : Snort MD5 Attempts: 1Everything is running as it should on 2.5.6 :)
-
Everything is running as it should on 2.5.6 :)
Good to hear. I'm about ready to submit the Pull Request for my 2.5.7 update that solves all the open issues I posted earlier plus a handful of small nits I discovered during testing of my other fixes.
I also found some boo-boos in the rules update code where some string variables were not properly escaped with {} when used in quotes. While in there I decided to make the verification of the downloaded rules files a little more robust. The old code which I inherited simply looked at the downloaded file size, and if greater than a set amount, it assumed the file was OK to unpack and use. I changed that to now calculate the MD5 hash of the downloaded rules file and compare that to the posted MD5 hash from the origin web site. Only if they match is the file then unpacked and the rules within it used to update the system. This new verification process is performed for all the rule sets (Snort VRT, GPLv2 and ET). If there is a MD5 mismatch, it is logged in the new log file viewable from the Updates tab.
I'm going to run through my test battery one time this evening with 2.0.3 and 2.1 machines to see if I can break it with installs, uninstalls and updates. If it survives testing, then I will post the Pull Request Thursday evening U.S. Eastern time.
Bill
-
