Snort 2.9.4.1 pkg v. 2.5.5 Issue(s)
-
Clean install on the box from scratch. Something has fucked your box.
-
clean install all the box ? really ? this isn't Windows…there must be a solution....
how can i start snort from command line ? why i didn't get error on system logs ?
also I have note that snort start on LAN interface, only WAN don't work...so snort install should be right... -
clean install all the box ? really ? this isn't Windows…there must be a solution....
how can i start snort from command line ? why i didn't get error on system logs ?
also I have note that snort start on LAN interface, only WAN don't work...so snort install should be right...If only one interface won't start, then perhaps it is a problem with a preprocessor setting or a bogus rules files somehow.
Try deleting the WAN interface in the Snort settings and recreate it. I'm talking about from the Snort Settings tab, delete WAN interface and then add it back. Make sure that you click Save at the bottom of the page each time. This part is critical, because the startup shell script file gets created and/or modified only when the Save button is clicked. If the file does not get properly updated with all of your interfaces, then it won't know to start some of them.
Do you get no messages at all about Snort trying to start on your WAN interface? You should at least see a line saying "SnortStartup …" for your WAN interface. If you see nothing at all in the system log, then it really sounds like you missed clicking Save somewhere and the proper startup lines in the snort.sh shell script did not get created.
Post the complete contents of the file /usr/local/etc/rc.d/snort.sh (if you are Snort 2.0.x).
If you have 2.1-BETA install, then the file is in /usr/pbi/snort-{arch}/etc/rc.d where {arch} is i386 or amd64.
Bill
-
I setup snort.sh with the "sleep 5" parameter and this is the result.
Apr 21 00:09:43 php: : The Rules update has finished.
Apr 21 00:09:43 php: : Snort has restarted with your new set of rules…
Apr 21 00:09:41 kernel: em0: promiscuous mode enabled
Apr 21 00:09:41 SnortStartup[34589]: Snort START For Internet(9626_em0)…
Apr 21 00:07:50 snort[26316]: Could not remove pid file /var/run/snort_em09626.pid: No such file or directory
Apr 21 00:07:50 snort[26316]: Could not remove pid file /var/run/snort_em09626.pid: No such file or directory
Apr 21 00:07:49 kernel: em0: promiscuous mode disabled
Apr 21 00:07:49 snort[26316]: *** Caught Term-Signal
Apr 21 00:07:49 snort[26316]: *** Caught Term-Signal
Apr 21 00:07:48 SnortStartup[50697]: Snort STOP For Internet(9626_em0)…
Apr 21 00:07:47 php: : Building new sig-msg.map file for WAN...
Apr 21 00:07:45 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 21 00:07:43 php: : Updating rules configuration for: WAN ...
Apr 21 00:07:42 php: : EmergingThreats rules file update downloaded succsesfully
Apr 21 00:07:40 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 21 00:07:38 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 21 00:07:37 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 21 00:07:36 php: : Failed Rules Filesize: 0
Apr 21 00:07:36 php: : Snort VRT rules file download failed...
Apr 21 00:07:36 php: : Snort Rules Attempts: 5Snort started as it should and is running fine on BOTH the test box'es.
I think this sort of helps prove my hypothesis on the root cause. Sleeping longer before attempting the restart gives the last shutdown command enough time to actually complete.
I've changed the logic in the shell script to make it smarter. It now issues the STOP command to the running Snort process and then enters a loop where it queries the Snort process once per second to see if it's really dead yet. Once it gets no response, the script continues. It waits a max of 30 seconds on Snort to die before it bails out. On my tests, the "time to die" ranges from 2 seconds on a lightly loaded VM to something around 7 seconds on a busier box.
I also duplicate the same logic with the Barnyard2 shutdown (if Barnyard2 is running on the interface). This should guarantee that all the processes are really and truly stopped before attempting to start them again via the "restart" argument to the snort.sh shell script.
The shell script loops through every configured Snort interface in a similar manner. When commanded to "restart", it shuts them all down one at the time, then starts them back up one at the time.
I'm going to let this new code run on my boxes another day or two, then I will submit to the pfSense team as a Github Pull Request.
Bill
-
I see the an update was pushed.. grabbing now.
Thanks for all the work on this!
A manual rules update worked just fine and snort restarted with no issues on this new version.
-
I see the an update was pushed.. grabbing now.
Thanks for all the work on this!
A manual rules update worked just fine and snort restarted with no issues on this new version.
Yeah, I decided to go ahead and submit the Pull Request. Those pfSense developers must never rest… ;D ... it was accepted and merged soon after I posted it on Sunday evening.
I hope this fixes the Snort and Barnyard2 restart issues following updates. Also snuck in a fix for an old GUI nit where the Log Size Limit was not displaying correctly on the Global Settings tab, and configured Snort and Barnyard2 to log the year in their timestamps. This was mainly for folks who log to MySQL with Barnyard2 and might want to archive stuff for more than a year.
Bill
-
Well thanks for all the work on this Bill. Everything seems to be working fine. Auto rules update ran fine this morning. I also did this update by just updating via the packages.. Didnt have to remove and install fresh. So that seems to be working just fine.
-
Well thanks for all the work on this Bill. Everything seems to be working fine. Auto rules update ran fine this morning. I also did this update by just updating via the packages.. Didnt have to remove and install fresh. So that seems to be working just fine.
Good news … and thanks!
Bill
-
Got this from a fresh install.
Apr 22 13:14:46 SnortStartup[33113]: Snort STOP For Internet(9626_em0)…
Apr 22 13:14:31 php: /snort/snort_download_rules.php: The Rules update has finished.
Apr 22 13:14:31 php: /snort/snort_download_rules.php: Emerging Threat rules are up to date...
Apr 22 13:14:31 php: /snort/snort_download_rules.php: Snort GPLv2 Community Rules are up to date...
Apr 22 13:14:30 php: /snort/snort_download_rules.php: Snort VRT rules are up to date...
Apr 22 13:14:30 php: /snort/snort_download_rules.php: Snort MD5 Attempts: 1
Apr 22 12:46:22 check_reload_status: Reloading filter
Apr 22 12:46:21 check_reload_status: Syncing firewall
Apr 22 12:46:20 php: /pkg_mgr_install.php: Building new sig-msg.map file for WAN...
Apr 22 12:46:18 php: /pkg_mgr_install.php: Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 22 12:46:16 php: /pkg_mgr_install.php: Updating rules configuration for: WAN ...
Apr 22 12:46:16 php: /pkg_mgr_install.php: The Rules update has finished.
Apr 22 12:46:08 php: /pkg_mgr_install.php: EmergingThreats rules file update downloaded succsesfully
Apr 22 12:46:06 php: /pkg_mgr_install.php: There is a new set of EmergingThreats rules posted. Downloading...
Apr 22 12:46:05 php: /pkg_mgr_install.php: Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 22 12:46:04 php: /pkg_mgr_install.php: There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 22 12:46:03 php: /pkg_mgr_install.php: Snort Rules Attempts: 1Didnt autostart but had to manually start it. Otherwise it seems to be running.
-
This error message almost always means you have mixed 32-bit and 64-bit libraries on the system. These "unsupported layout" errors have happened before for many other packages besides just Snort, and each time it's caused by having a mix of 32-bit and 64-bit stuff on a system. In particular this error can happen when 64-bit libs wind up on a 32-bit box. I can't tell you how this might have happened, but I'm pretty sure that's what is wrong now.
I had to reformat the drive and reinstall pfSense, but I finally got Snort working. If I could only figure out why the pfSense installation won't work from a USB CDROM, I wouldn't be so put off, but the installation asks for a mount device and fails when a valid one is entered. If I plug in a SATA CDROM drive with the same disc, it just installs to the proper drive without asking me anything. This is on a rack-mounted PC w/o any external bays, so I have to unmount the PC and open it up to rerun the installation. Ugh! I think I'll pass on pfSebse and Snort updates for the next year.
-
This error message almost always means you have mixed 32-bit and 64-bit libraries on the system. These "unsupported layout" errors have happened before for many other packages besides just Snort, and each time it's caused by having a mix of 32-bit and 64-bit stuff on a system. In particular this error can happen when 64-bit libs wind up on a 32-bit box. I can't tell you how this might have happened, but I'm pretty sure that's what is wrong now.
I had to reformat the drive and reinstall pfSense, but I finally got Snort working. If I could only figure out why the pfSense installation won't work from a USB CDROM, I wouldn't be so put off, but the installation asks for a mount device and fails when a valid one is entered. If I plug in a SATA CDROM drive with the same disc, it just installs to the proper drive without asking me anything. This is on a rack-mounted PC w/o any external bays, so I have to unmount the PC and open it up to rerun the installation. Ugh! I think I'll pass on pfSebse and Snort updates for the next year.
I installed my current config from usb. My 1u system has no optical and I didnt have a usb cdrom. Mine installed just fine using the usb install method.. Maybe try that instead of cdrom?
