Snort 2.9.4.6 Pkg v 2.5.9
-
Bill,
I am using PFSense 2.0.3-RELEASE (amd64)
Here is what I receive when I check for Barnyard
$ ps -ax |grep barnyard2
34971 ?? S 0:00.00 sh -c ps -ax |grep barnyard2
35558 ?? S 0:00.00 grep barnyard2$ grep barnyard /var/log/system.log
Jul 1 08:37:15 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)…
Jul 1 08:40:44 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...
Jul 1 08:52:14 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...Thanks for the help
cjb
-
So it updated and it didnt crash. I can only assume that line was the issue. Thanks for the help
Thanks for the feedback. I've fixed that line in my source code repository. I have that one and another small fix I will submit in the near future, but won't bump the package version number so it won't show as a new package update.
I am making good progress on the multi-engine configurations. I'm finished with HTTP_INSPECT, FRAG3 and STREAM5. Also saw Snort 2.9.5 was posted yesterday by the Snort.org guys. Will most likely wait and release the new multi-engine Snort with an update to the 2.9.5 binary, but need to wait until the 2.9.5 rules are available for the registered, free users at Snort.org. Don't want to repeat the mistake of last time when the binary got updated ahead of the new rules being available for the registered users (the subscriber users always get the latest rules immediately).
Bill
-
Bill,
I am using PFSense 2.0.3-RELEASE (amd64)
Here is what I receive when I check for Barnyard
$ ps -ax |grep barnyard2
34971 ?? S 0:00.00 sh -c ps -ax |grep barnyard2
35558 ?? S 0:00.00 grep barnyard2$ grep barnyard /var/log/system.log
Jul 1 08:37:15 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)…
Jul 1 08:40:44 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...
Jul 1 08:52:14 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...Thanks for the help
cjb
OK, your barnyard2 instance is not starting up. It's trying, but then dies badly since there is no further logging. My first guess is that something (another package perhaps) has stepped on a shared library. Try removing (deleting) and reinstalling Snort to see if that helps. Just click the "save settings on deinstall" checkbox on the Global Settings tab first, and you won't lose your Snort configuration. It's possible, though, that the Snort remove and reinstall still won't fix the shared library if it's marked as "in use" by another package.
If that does not work (or you have already tried it), then we need to try starting barnyard2 from the command line to see if it will give us some clues. From a console prompt just type "barnyard2" and ENTER. If it makes it far enough into starting, it will fuss about no configuration file. However, I'm going to guess it barfs first with a missing or wrong version library. Post back with the results.
Bill
P.S. – I don't remember the details, but seems like another user had barnyard2 troubles a while back that were traced to a shared library conflict. You might try a search on the Forum to see if you find it. It was maybe 2 or 3 months back (definitely from this year, though).
-
I am making good progress on the multi-engine configurations. I'm finished with HTTP_INSPECT, FRAG3 and STREAM5. Also saw Snort 2.9.5 was posted yesterday by the Snort.org guys. Will most likely wait and release the new multi-engine Snort with an update to the 2.9.5 binary, but need to wait until the 2.9.5 rules are available for the registered, free users at Snort.org. Don't want to repeat the mistake of last time when the binary got updated ahead of the new rules being available for the registered users (the subscriber users always get the latest rules immediately).
Bill
Good to hear that they are finished. Can you post screenshots of how they are going to look?. Yes it would be best to hold out on the update until everyone is able to get the rules. The snort manual got updated too which is nice also. Anyway thanks again.
-
barnyard problem update
Tried removing and re-installing package same error the error is:
/libexec/ld-elf.so.1: Shared object "libmysqlclient.so.18" not found required by "barnyard2".
How can I install it, since a re-install does not do the trick.
Thanks for the help
cjb
-
It's a problem with the 2.0.X package manager system. With 2.1's PBI's things usually remove and install in a more sane way. With 2.0.X packages might share some of the additional components and things might break because of that.
-
It's a problem with the 2.0.X package manager system. With 2.1's PBI's things usually remove and install in a more sane way. With 2.0.X packages might share some of the additional components and things might break because of that.
fragged is correct. On the 2.0.x platform, libraries such as MySQL and others are shared among applications. It's a condition not all that unlike the "DLL Hell" that existed in Windows where different versions of the same DLL stored in different places caused all kinds of grief.
The 2.1 platform with PBI sort of puts each application and all of its "shared libraries" into a type of "jail" where they appear to be shared for the application, but really aren't. Each app has its own copy of the libraries in a dedicated directory tree isolated from other apps.
First up, run this command on the console to see what version of MySQL is actually installed on your box:
pkg_info | grep mysqlIt should come back and say mysql-client-5.5.30. My guess is yours will come back with something different. If it does, then run this command to see what installed the version you have (the backslashes and asterisks are required and act as wildcards):
pkg_info \*mysql*\Look for the "Required by:" line. That will show what other package might be using MySQL on your box. Again, the correct response there would be:
Required by: barnyard2-1.12Run the commands above and post back one more time. You can also check out this post from jimp showing the best way to fix these shared library issues on 2.0.x: http://forum.pfsense.org/index.php/topic,63253.msg342512.html#msg342512
Bill
-
barnyard issue:
Ran the first command and got back the following:
mysql-client-5.1.53-multitreaded sql database(client)
mysql-client-5.1.57-multitreaded sql database(client)
mysql-client-5.5.29-multitreaded sql database(client)
mysql-client-5.6.30-multitreaded sql database(client)Ran the second command and got back:
pkg_info: No match
Then removed snort again and ran from the shell the command:
pkg_delete -f *snort* *barny* *mysql*
Re-installed snort
and Now I receive the following error in the log and barnyard does not start
Jul 4 10:29:05 barnyard2[8071]: Writing PID "8071" to file "/var/run/barnyard2_em02472.pid"
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)This is the setting for MYSQL in Snort for barnyard
output database: alert, mysql, dbname=snort user=snort host=localhost password=xyz
When I re-run the first command I now get:
mysql-client-5.5.30-multitreaded sql database(client) - This is good!!!
The second command still comes with "No Match" - Not so GOOD!!!
Any suggestions on how to fix? Thanks
cjb
-
barnyard issue:
Ran the first command and got back the following:
mysql-client-5.1.53-multitreaded sql database(client)
mysql-client-5.1.57-multitreaded sql database(client)
mysql-client-5.5.29-multitreaded sql database(client)
mysql-client-5.6.30-multitreaded sql database(client)Ran the second command and got back:
pkg_info: No match
Then removed snort again and ran from the shell the command:
pkg_delete -f *snort* *barny* *mysql*
Re-installed snort
and Now I receive the following error in the log and barnyard does not start
Jul 4 10:29:05 barnyard2[8071]: Writing PID "8071" to file "/var/run/barnyard2_em02472.pid"
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)This is the setting for MYSQL in Snort for barnyard
output database: alert, mysql, dbname=snort user=snort host=localhost password=xyz
When I re-run the first command I now get:
mysql-client-5.5.30-multitreaded sql database(client) - This is good!!!
The second command still comes with "No Match" - Not so GOOD!!!
Any suggestions on how to fix? Thanks
cjb
My mistake on the second command. I pasted in the backslash and asterisk backwards. It should be this way:
pkg_info \*mysql\*Yes, having the myslq-client-5.5.30 is good. That is the correct version.
Are you trying to have the MySQL database on the firewall? If so, then you would need to manually install MySQL Server. That's not recommended. When using Barnyard2, you should have a remote MySQL install on a separate database server. The Barnyard2 setup in Snort is simply a client that needs the MySQL client to communicate with a remote database.
From your database string, it appears you are trying to connect to a local MySQL instance: host=localhost
There won't be one unless you jump through hoops and install the full MySQL database server on the firewall. What you should do is install MySQL server on a separate box (physical or VM), configure the database for Snort, then put that database server name in the database string in Barnyard2.
I run Snorby on a separate virtual machine. I have MySQL Server installed on that VM, and my Barnyard2 database connect string points there. Unless you use a third-party tool like Snorby or others like it, there is no real benefit to logging via Barnyard2 with MySQL.
Bill
-
I just updated Snort to package version 2.5.9 on my machine which is running 2.1-RC0.
I'm not sure if this bug is known or not, and I didn't see it in the thread.
With the new installation of the Snort package, I created a new, empty suppress list. Afterwards, clicking the suppress button in the alerts tab under the SID column did not work as expected. No suppression entry was generated in the suppression list and the line in the alert was not 'greyed out' to indicate the rule was being suppressed.
As a workaround, I manually created one suppression rule by copying and pasting a rule from the example on the suppression page and saved. Automatic suppression generation buttons worked fine after that.
-
I just updated Snort to package version 2.5.9 on my machine which is running 2.1-RC0.
I'm not sure if this bug is known or not, and I didn't see it in the thread.
With the new installation of the Snort package, I created a new, empty suppress list. Afterwards, clicking the suppress button in the alerts tab under the SID column did not work as expected. No suppression entry was generated in the suppression list and the line in the alert was not 'greyed out' to indicate the rule was being suppressed.
As a workaround, I manually created one suppression rule by copying and pasting a rule from the example on the suppression page and saved. Automatic suppression generation buttons worked fine after that.
Thanks for the report. I will check it out in my VM test environment and attempt to reproduce. Just to be sure I have the correct initial conditions:
– you created an empty but named Suppress List and then assigned that list to the Snort interface.
-- next, you clicked on an Alert entry on the Alerts tab to auto-add the event to the Suppress List, but it did not work.
-- you then created an entry manually in the same Suppress List, and then auto-additions worked.Did I get the sequence correct?
Bill
-
I remember seeing similar behavior and I am pretty sure it was with a blank whitelist too. I ended up editing the whitelist manually for some reason and at some point I noticed it was working again.
-
I just updated Snort to package version 2.5.9 on my machine which is running 2.1-RC0.
I'm not sure if this bug is known or not, and I didn't see it in the thread.
With the new installation of the Snort package, I created a new, empty suppress list. Afterwards, clicking the suppress button in the alerts tab under the SID column did not work as expected. No suppression entry was generated in the suppression list and the line in the alert was not 'greyed out' to indicate the rule was being suppressed.
As a workaround, I manually created one suppression rule by copying and pasting a rule from the example on the suppression page and saved. Automatic suppression generation buttons worked fine after that.
I remember seeing similar behavior and I am pretty sure it was with a blank whitelist too. I ended up editing the whitelist manually for some reason and at some point I noticed it was working again.
I found this bug. The fix will be in the next Snort Package update. The code I wrote blindly assumed any pre-existing Suppress List would not initially be "empty". That was a dumb assumption on my part. Should have thought about the scenario described here. I was testing for a "if not empty" list and updating it with the new entry, but if the list was empty my code was just falling through the "if statement" and doing nothing.
Sorry about that… :(
Bill -
No worries mate!! The Snort package has elevated itself a 1000 times since you began development on it!
Bloody good job!
-
Every time I do a reboot, no upgrade or so, just a reboot, I have 2 processes of Snort running:
root(2): ps uaxwwww | grep snort root 8350 4.5 17.6 629508 364924 ?? Ss 12:24PM 0:53.61 /usr/pbi/snort-i386/bin/snort -R 54477 -E -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 21658 2.3 17.9 634628 370092 ?? SNs 12:24PM 0:03.93 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 31323 0.0 0.1 3468 1240 0 S+ 12:26PM 0:00.00 grep snortI have to kill both processes from the terminal and restart Snort from the webGUI.
The -E option has something to do with Windows logging. Where does that come from? Does this have something to do how this version was compiled? -
You have a cron job running??
-
Every time I do a reboot, no upgrade or so, just a reboot, I have 2 processes of Snort running:
root(2): ps uaxwwww | grep snort root 8350 4.5 17.6 629508 364924 ?? Ss 12:24PM 0:53.61 /usr/pbi/snort-i386/bin/snort -R 54477 -E -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 21658 2.3 17.9 634628 370092 ?? SNs 12:24PM 0:03.93 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 31323 0.0 0.1 3468 1240 0 S+ 12:26PM 0:00.00 grep snortI have to kill both processes from the terminal and restart Snort from the webGUI.
The -E option has something to do with Windows logging. Where does that come from? Does this have something to do how this version was compiled?The process with the -E argument is not being generated by the default package installation. Something else is launching that process. Have you looked in all the startup scripts for your firewall to see if something else is launching a Snort instance?
Bill
-
Every time I do a reboot, no upgrade or so, just a reboot, I have 2 processes of Snort running:
root(2): ps uaxwwww | grep snort root 8350 4.5 17.6 629508 364924 ?? Ss 12:24PM 0:53.61 /usr/pbi/snort-i386/bin/snort -R 54477 -E -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 21658 2.3 17.9 634628 370092 ?? SNs 12:24PM 0:03.93 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 31323 0.0 0.1 3468 1240 0 S+ 12:26PM 0:00.00 grep snortI have to kill both processes from the terminal and restart Snort from the webGUI.
The -E option has something to do with Windows logging. Where does that come from? Does this have something to do how this version was compiled?The process with the -E argument is not being generated by the default package installation. Something else is launching that process. Have you looked in all the startup scripts for your firewall to see if something else is launching a Snort instance?
Bill
Bill,
I also see this on my VM. During the boot process I sshd into my VM and the snort.sh startup script is also running twice:
ps auxwwww | grep snort root 10800 78.0 17.9 636420 372192 v0- RL 10:15PM 0:15.15 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 41460 20.0 1.8 240132 36832 ?? RN 10:15PM 0:00.48 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 40567 17.0 0.1 3644 1576 ?? SN 10:15PM 0:00.00 /bin/sh /usr/local/etc/rc.d/snort.sh start root 10447 0.0 0.1 3644 1500 v0- S 10:15PM 0:00.00 /bin/sh /usr/local/etc/rc.d/snort.sh start root 42050 0.0 0.1 4696 2332 0 RV 10:15PM 0:00.00 grep snort (tcsh)A few moments later:
ps auxwwww | grep snort root 41460 89.0 50.9 2305540 1057752 ?? RN 10:15PM 1:43.48 /usr/pbi/snort-i386/bin/snort -R 54477 -D -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 71694 62.0 4.7 361988 98480 ?? Rs 10:17PM 0:08.92 /usr/pbi/snort-i386/bin/snort -R 54477 -E -q -l /var/log/snort/snort_em054477 --pid-path /var/run --nolock-pidfile -G 54477 -c /usr/pbi/snort-i386/etc/snort/snort_54477_em0/snort.conf -i em0 root 40567 0.0 0.0 3644 0 ?? IWN - 0:00.00 /bin/sh /usr/local/etc/rc.d/snort.sh start root 74561 0.0 0.1 3468 1236 0 S+ 10:17PM 0:00.00 grep snortOne snort.sh script has stopped and the -E argument appears
Another few moments later the other snort.sh script has ended and I am left with two snort processes.
I grepped into my machine with the following string: "/var/log/snort/snort_em054477" and only the snort startup script has this string.
What could be causing the snort startup script running twice? -
I grepped into my machine with the following string: "/var/log/snort/snort_em054477" and only the snort startup script has this string.
What could be causing the snort startup script running twice?I don't know what could be launching the startup script twice. Also not sure how that -E argument is getting on there either.
If you can, completely remove Snort from the firewall via System…Packages and click the X to delete the package. So long as you have the box checked on the Global Settings tab to save the configuration on de-install, then everything will come back OK. After removing Snort, and before installing again, reboot the firewall to see what happens in terms of something else trying to start Snort. If some other thing is attempting to launch it, then it should log some kind of error with the files removed.
Re-install Snort and see if that makes any difference. This is a strange problem. There were some issues a long time ago (as in about a year ago) with multiple instances of Snort getting started on reboot, but Ermal and I are pretty sure those are behind us with changes to the startup scripts. I have been doing a lot of startup/shutdown/reboot operations on my VMs while testing the next Snort update, and I have not noticed this problem.
Bill
-
I grepped into my machine with the following string: "/var/log/snort/snort_em054477" and only the snort startup script has this string.
What could be causing the snort startup script running twice?I don't know what could be launching the startup script twice. Also not sure how that -E argument is getting on there either.
If you can, completely remove Snort from the firewall via System…Packages and click the X to delete the package. So long as you have the box checked on the Global Settings tab to save the configuration on de-install, then everything will come back OK. After removing Snort, and before installing again, reboot the firewall to see what happens in terms of something else trying to start Snort. If some other thing is attempting to launch it, then it should log some kind of error with the files removed.
Re-install Snort and see if that makes any difference. This is a strange problem. There were some issues a long time ago (as in about a year ago) with multiple instances of Snort getting started on reboot, but Ermal and I are pretty sure those are behind us with changes to the startup scripts. I have been doing a lot of startup/shutdown/reboot operations on my VMs while testing the next Snort update, and I have not noticed this problem.
It is becoming even more weird. This what I did.
-
Booted my VM where the two processes of Snort were running after a (re)boot
-
Killed both processes
-
Removed Snort package
-
Rebooted and there was no trace of Snort processes
-
Installed Snort package again and now this:
Jul 21 21:58:12 php: /pkg_mgr_install.php: Beginning package installation for snort . Jul 21 21:59:01 php: /pkg_mgr_install.php: [Snort] Saved settings detected... rebuilding installation with saved settings... Jul 21 21:59:01 php: /pkg_mgr_install.php: [Snort] Downloading and updating configured rule types... Jul 21 21:59:02 php: /pkg_mgr_install.php: [Snort] There is a new set of Snort VRT rules posted. Downloading... Jul 21 21:59:49 php: /pkg_mgr_install.php: [Snort] There is a new set of EmergingThreats rules posted. Downloading... Jul 21 21:59:51 php: /pkg_mgr_install.php: [Snort] EmergingThreats rules file update downloaded successfully Jul 21 21:59:54 php: /pkg_mgr_install.php: [Snort] The Rules update has finished. Jul 21 21:59:54 php: /pkg_mgr_install.php: [Snort] Updating rules configuration for: WAN ... Jul 21 21:59:56 php: /pkg_mgr_install.php: [Snort] Enabling any flowbit-required rules for: WAN... Jul 21 21:59:56 php: /pkg_mgr_install.php: [Snort] Building new sig-msg.map file for WAN... Jul 21 21:59:57 php: /pkg_mgr_install.php: [Snort] Finished rebuilding installation from saved settings... Jul 21 21:59:57 php: /pkg_mgr_install.php: [Snort] Starting Snort using rebuilt configuration... Jul 21 21:59:59 SnortStartup[37422]: Snort START for WAN(54477_em0)... Jul 21 21:59:59 php: /pkg_mgr_install.php: [Snort] Package post-installation tasks completed... Jul 21 21:59:59 check_reload_status: Syncing firewall Jul 21 22:00:01 check_reload_status: Reloading filter Jul 21 22:01:51 snort[22965]: Could not create configuration reload thread.Googling for that error shows that this is in the Snort code.
I rebooted again without starting snort in the WebGUI gives this log:
Jul 21 22:08:17 SnortStartup[11448]: Snort START for WAN(54477_em0)... Jul 21 22:08:19 login: login on ttyv0 as root Jul 21 22:08:19 sshlockout[15602]: sshlockout/webConfigurator v3.0 starting up Jul 21 22:08:24 check_reload_status: Syncing firewall Jul 21 22:08:29 SnortStartup[33999]: Snort START for WAN(54477_em0)... Jul 21 22:10:20 snort[75620]: Could not create configuration reload thread. Jul 21 22:10:36 snort[83412]: Could not create configuration reload thread.Now there is a trace of two Snort processes starting up, but exiting with that error.
Rebooted again without Snort starting from the webGUI (I thought that maybe it would become three processes ;))
But that gave me the same log entries as above.Then I started Snort from the webGUI:
Jul 21 22:19:03 php: /snort/snort_interfaces.php: Toggle (snort starting) for WAN(WAN)... Jul 21 22:19:03 php: /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN ... Jul 21 22:19:05 php: /snort/snort_interfaces.php: [Snort] Enabling any flowbit-required rules for: WAN... Jul 21 22:19:05 php: /snort/snort_interfaces.php: [Snort] Building new sig-msg.map file for WAN... Jul 21 22:19:06 php: /snort/snort_interfaces.php: [Snort] Snort START for WAN(em0)... Jul 21 22:20:54 snort[89067]: Could not create configuration reload thread.So now Snort doesn't even start anymore :(
Now I removed Snort without saving the settings and reinstalled the package and configured it again. Rebooted and bam: back where I started with 2 Snort processes and one with the -E argument.
What can I do more?
-
