Snort 2.9.2.3 pkg v. 2.5.0 Issues
-
@ermal:
Should behave better if you just reinstall.
No new binary needed.I couldn't wait for my box to auto update but wanted to test your changes before i leave for my annual military training. So I ran the the cron job from shell and seems to work.. It downloaded a new set of rules and started snort… I love the fact now we dont have to download a new ruleset went we do a reinstall.. Thank you again!!!
/root(1): /usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php >> /tmp/snort_update.log rm: /usr/local/etc/snort/snortrules: No such file or directory /root(2):
P.S I sent a small donation in today for beer ;D
Are you sure when you ran the rule update there was indeed an update downloaded?
-
Ermal, reinstalled (AMD64, 2.0.1) and got this:
Jul 18 22:04:22 snort[23595]: FATAL ERROR: Failed to load /usr/local/lib/snort/dynamicrules/bad-traffic.so: /usr/local/lib/snort/dynamicrules/bad-traffic.so: Undefined symbol "freeRuleData"
Jul 18 22:04:22 snort[23595]: Loading dynamic detection library /usr/local/lib/snort/dynamicrules/bad-traffic.so…However, an uninstall, manual delete, and reinstall worked. Will set to autoupdate and see what happens.
-
Had the same issues with auto-update. I didn't reinstall, but just updated manually and the manually restarted the Snort interface(s).
This worked for me this time. Will disable auto-update in the meanwhile. -
@ermal:
Should behave better if you just reinstall.
No new binary needed.I couldn't wait for my box to auto update but wanted to test your changes before i leave for my annual military training. So I ran the the cron job from shell and seems to work.. It downloaded a new set of rules and started snort… I love the fact now we dont have to download a new ruleset went we do a reinstall.. Thank you again!!!
/root(1): /usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php >> /tmp/snort_update.log rm: /usr/local/etc/snort/snortrules: No such file or directory /root(2):
P.S I sent a small donation in today for beer ;D
Are you sure when you ran the rule update there was indeed an update downloaded?
Looks like I spoke too soon, check again this morning. And it failed
-
At the moment snort ist working ok.
Autoupdates fail but snort keeps on snorting on my system.
Manual update works, if I delete snortrules MD5 file before.
WAN blocking does not occur any more.
Greets, Judex
-
WAN blocking does not occur any more.
Hi, I was updating this morning, few hours ago, and my WAN IPs were still get blocked (block: Both), even if they are on the whitelist (both choosing a whitelist then leaving "default" as whitelist)…
Thanks,
Michele -
Ermal this is still not fixed.
If snort is running and downloads a new rule update then tries to apply it, the same will occur. I have the latest version update. Of course if I uninstall snort and reinstall it will start again and run fine but it is still not fixed as the next rule update will cause the same error.
Jul 18 12:19:33 snort[31831]: FATAL ERROR: /usr/local/etc/snort/snort_27588_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 12:19:33 snort[31831]: FATAL ERROR: /usr/local/etc/snort/snort_27588_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 12:19:33 snort[31831]: Initializing rule chains…
Jul 18 12:19:33 snort[31831]: Initializing rule chains…
Jul 18 12:19:33 snort[31831]: +++++++++++++++++++++++++++++++++++++++++++++++++++
Jul 18 12:19:33 snort[31831]: +++++++++++++++++++++++++++++++++++++++++++++++++++I'm still getting this too. I delete the md5 files and redownload the snort rules, snort starts fine after that. But, next time new rules are downloaded, I'll get this error again.
-
Hi,
I am just curious about how you are updating (System packages or Git repository). The regular package update is about 2 days old, but ermal has updated the sources since then.
A quick check to find out what you are running is to check select the "Rules" tab of one of the snort interfaces. If there is visual glitch on top of the page, then you are still running an "old" version.
I had some of the messages reported here a couple of days ago, but not lately. If someone is not sure what is currently installed a diff -u for a candidate file (e.g. snort.inc) and the corresponding one from https://github.com/bsdperimeter/pfsense-packages/tree/master/config/snort should clarify the situation.
-
Fesoj,
When you see updates on git and/or announces on forum, just wait 15 minutes after the update date-time and then re-install the package.
att,
Marcello Coutinho -
Hi,
I am just curious about how you are updating (System packages or Git repository). The regular package update is about 2 days old, but ermal has updated the sources since then.
A quick check to find out what you are running is to check select the "Rules" tab of one of the snort interfaces. If there is visual glitch on top of the page, then you are still running an "old" version.
I had some of the messages reported here a couple of days ago, but not lately. If someone is not sure what is currently installed a diff -u for a candidate file (e.g. snort.inc) and the corresponding one from https://github.com/bsdperimeter/pfsense-packages/tree/master/config/snort should clarify the situation.
You are correct that latest code does appear to have solved the issue. But it has not been added to the package as of yet. I manually added it and it is working.
-
Marcello,
When you see updates on git and/or announces on forum, just wait 15 minutes after the update date-time and then re-install the package.
yes, I do know that. It just looks to me that some of the current posts relate to older versions of snort and not to the up to date version in the repository.
BTW, if someone is interested, I have a short quick&dirty script that checks whether the binary package from files.pfsense.org has been updated, since the version string does not necessarily get updated. If there's any interest, I'll post it.
-
Fesoj..thanks for posting that information. I've been slowly collecting bits and pieces of the github process into my grey matter..your post helps. It would be helpful to me and no doubt others if you could post a "Github and SNORT for Dummies". This would certainly help out with more detailed feedback in the troubleshooting process for Ermal. I would be interested in that script :-)
I believe another issue here is that reinstalling SNORT over an existing version is behaving differently (depending on what got sync'd) than first uninstalling -> deleting leftover bits -> and reinstalling. Over the last year of messing with SNORT the clean install has become my standard install to avoid the issue of troubleshooting leftover files/code/configuration.
-
Here it is:
#!/bin/sh DLURL=http://files.pfsense.com/packages/8/All SNORT=snort-2.9.2.3-i386.pbi.sha256 if [ -e $SNORT ]; then mv -f $SNORT $SNORT.bak fi echo "Getting $DLURL/$SNORT" wget "$DLURL/$SNORT" echo echo if [ -e $SNORT ] && [ -e $SNORT.bak ]; then delta=`diff -q $SNORT $SNORT.bak` if [ -n "$delta" ]; then echo "+------------------+" echo "| Update available |" echo "+------------------+" else echo "+---------------------+" echo "| No update available |" echo "+---------------------+" fi fi
The script does not update anything and it needn't be on the pfSense box. It just reports about an update between subsequent calls. Strictly speaking it is valid only for pfSense 2.1, but the *.tbz files typically get updated about the same time (give or take an hour, or so).
-
Forgive my newbishness..but how/where would you execute the script? Assume little/no knowledge of BSD..sadly I'm a windows guy. :-) If I understand correctly, it does not actually look at SNORT file version on the router?
-
I'm a windows guy.
Could be even worse.
The setup is as follows:
(1) there's your PC running Windows, some flavor of Linux, whatever, and
(2) there's your pfSense based router
and you do your regular work on your PC (and not on the router). In my case it is Windows 7 or precise Ubuntu.Save the script in some file and give it a name, e.g. check-snort-update.sh. If you are using a Linux machine put it into ~/bin or /usr/local/bin. On Windows you have several options. Either you use cygwin (http://www.cygwin.com/), or you install your favorite Linux distro using VirtualBox (https://www.virtualbox.org/), then do the same things, as you would do on a Linux machine. You might need to issue a chmod a+x check-snort-update.sh if you want to make the script executable (or always call it with sh check-snort-update.sh).
See the attachment for a typical run on my Windows machine (using cygwin).
-
Ermal this is still not fixed.
If snort is running and downloads a new rule update then tries to apply it, the same will occur. I have the latest version update. Of course if I uninstall snort and reinstall it will start again and run fine but it is still not fixed as the next rule update will cause the same error.
Jul 18 12:19:33 snort[31831]: FATAL ERROR: /usr/local/etc/snort/snort_27588_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 12:19:33 snort[31831]: FATAL ERROR: /usr/local/etc/snort/snort_27588_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 12:19:33 snort[31831]: Initializing rule chains…
Jul 18 12:19:33 snort[31831]: Initializing rule chains…
Jul 18 12:19:33 snort[31831]: +++++++++++++++++++++++++++++++++++++++++++++++++++
Jul 18 12:19:33 snort[31831]: +++++++++++++++++++++++++++++++++++++++++++++++++++I'm still getting this too. I delete the md5 files and redownload the snort rules, snort starts fine after that. But, next time new rules are downloaded, I'll get this error again.
Actually need to correct this post. I had to delete the snort package altogether and reinstall before downloading the rules would allow snort to start. I got the error about the .so file and FreeDataType error (or something like that. It's in a previous post on this thread). I see an update was done yesterday, I'll post back if this problem continues.
-
If I understand correctly, it does not actually look at SNORT file version on the router?
That's correct. It just checks, whether there was a change in the md5 value of the snort package. I use it the following way: if there was an announcement about an update, that does not really affect my setup, I just call the script, e.g. every morning. If the script says "Update", I'll just do the binary package update.
If there was an update that touches my setup, I'll have a look at the git repository and then I'll update either by hand or from the repository, but that works only for the php scripts. The package update follows once the script says "Update" to avoid useless downloads (and sometimes the installation hassle that follows).
Essentially, you do the package update only after the script says so.
-
Perfecto Fesoj. Exactly what I was looking for. One great thing about sorting through this stuff is learning a lot more about the UNIX/Linus/BSD world. Let's face it..anything really important runs in that OS milieu anyway :-)
-
Hi guys,
some feedback from my side too:pfsense 2.0.1-RELEASE
Snort 2.9.2.3 pkg v. 2.5.0I faced the same issues you mentioned before so there is no need to write them again.
Till yesterday the snort was working and I had only the issue with the blocking of whitelisted IPs so I had blocking OFF.
This morning with the latest auto update I got the known "sdf" FATAL ERROR. So I turned auto-update OFF, reinstalled the snort package, downloaded the rules again and now I get FATAL ERROR "freeRuleData" for a ruleset(bad-traffic.so). I disabled this one as well as all SO rules, but I got still this error. I reinstalled the package (having unselected these rulesets) but still the same error…So these issues are still unresolved for me:
1. Auto-update issues / FATAL ERRORS
2. Blocking of Whitelisted IPsCheers,
/CS -
In snort.inc the lines 1308 and 1309 contain bogus sed commands, such that the initial installation cannot complete without errors. You cannot patch this by hand, because this code gets called only during the initial installation as part of the function snort_postinstall(). So this part of snort.inc should better be correct.
Some of the recent posts seem to be related to the sed typos, but I don't know whether it is responsible for all of them. Maybe I was lucky because my setup doesn't need the sensitive data preproc.
ermal,
please update the sed commands (e.g. mwexec("/usr/bin/sed -I.bak -f {$g['tmp_path']}/sedcmd …) and trigger an update of the binary package (or I'll come up with a real dirty patch).