Snort 2.9.4.1 pkg v. 2.5.6 Issue(s)



  • I thought let's start a new one

    This morning I upgraded my system with the latest 2.1 snapshot and also the new snort Snort 2.9.4.1 pkg v. 2.5.6 package
    That went wrong.

    
    Apr 22 09:28:46	SnortStartup[70273]: Snort START For WAN(54477_em0)...
    Apr 22 09:28:46	snort[67063]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_54477_em0//usr/pbi/snort-i386/etc/snort/snort_54477_em0/rules/snort.rules(0) Unable to open rules file "/usr/pbi/snort-i386/etc/snort/snort_54477_em0//usr/pbi/snort-i386/etc/snort/snort_54477_em0/rules/snort.rules": No such file or directory.
    Apr 22 09:28:41	SnortStartup[42997]: Snort STOP For WAN(54477_em0)...
    Apr 22 09:28:12	php: : Could not find the libsf_imap_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_pop_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_dns_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_dce2_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_gtp_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_ssl_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_smtp_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_ftptelnet_preproc file. Snort might error out!
    Apr 22 09:28:11	php: : Building new sig-msg.map file for WAN...
    Apr 22 09:28:02	php: : Resolving and auto-enabling any flowbit-required rules for WAN...
    Apr 22 09:27:54	php: : Updating rules configuration for: WAN ...
    Apr 22 09:27:54	php: : Could not find the libsf_imap_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_pop_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_dns_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_dce2_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_gtp_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_ssl_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_smtp_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_ftptelnet_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : The Rules update has finished.
    Apr 22 09:27:44	php: : EmergingThreats rules file update downloaded succsesfully
    Apr 22 09:27:35	php: : There is a new set of EmergingThreats rules posted. Downloading...
    Apr 22 09:27:35	php: : Snort Rules Attempts: 1
    Apr 22 09:27:14	php: : There is a new set of Snort VRT rules posted. Downloading...
    
    

    It seemed that everything was written to /etc/snort instead of to /usr/pbi/snort-i386/.
    Even /lib/snort was written. I could recover by updating the rules again but then:

    
    Apr 22 09:46:48	snort[91557]: FATAL ERROR: The dynamic detection library "/usr/pbi/snort-i386/lib/snort/dynamicrules/lib_sfdynamic_example_rule.so" version 1.0 compiled with dynamic engine library version 1.0 isn't compatible with the current dynamic engine library "/usr/pbi/snort-i386/lib/snort/dynamicengine/libsf_engine.so" version 1.17.
    Apr 22 09:46:48	php: /snort/snort_interfaces.php: Toggle(snort starting) for WAN(WAN)...
    

    So I deinstalled snort and "rm -rf" all snort directories and installed snort again. Snort is up again.
    I don't know what went wrong but I will try again on a VM. I suppose I can avoid this by deinstalling snort before upgrading my pfSense snapshot and install snort later.


  • Banned

    After the update of packages, then Snort didnt autostart when done installing.

    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: 1

    Manual start and it came on fine. Now I will see if it actually is running.



  • @Supermule:

    After the update of packages, then Snort didnt autostart when done installing.

    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: 1

    Manual start and it came on fine. Now I will see if it actually is running.

    It's not currently coded to auto-start upon a package install/reinstall.  It does detect if there were saved settings and restores those. I guess that could also be a flag to attempt an auto-restart.  Since I am not the original package creator, I will have to research that angle a bit to be sure no unintended consequences are introduced.

    Bill



  • @gogol:

    I thought let's start a new one

    This morning I upgraded my system with the latest 2.1 snapshot and also the new snort Snort 2.9.4.1 pkg v. 2.5.6 package
    That went wrong.

    
    Apr 22 09:28:46	SnortStartup[70273]: Snort START For WAN(54477_em0)...
    Apr 22 09:28:46	snort[67063]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_54477_em0//usr/pbi/snort-i386/etc/snort/snort_54477_em0/rules/snort.rules(0) Unable to open rules file "/usr/pbi/snort-i386/etc/snort/snort_54477_em0//usr/pbi/snort-i386/etc/snort/snort_54477_em0/rules/snort.rules": No such file or directory.
    Apr 22 09:28:41	SnortStartup[42997]: Snort STOP For WAN(54477_em0)...
    Apr 22 09:28:12	php: : Could not find the libsf_imap_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_pop_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_dns_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_dce2_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_gtp_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_ssl_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_smtp_preproc file. Snort might error out!
    Apr 22 09:28:12	php: : Could not find the libsf_ftptelnet_preproc file. Snort might error out!
    Apr 22 09:28:11	php: : Building new sig-msg.map file for WAN...
    Apr 22 09:28:02	php: : Resolving and auto-enabling any flowbit-required rules for WAN...
    Apr 22 09:27:54	php: : Updating rules configuration for: WAN ...
    Apr 22 09:27:54	php: : Could not find the libsf_imap_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_pop_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_dns_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_dce2_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_gtp_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_ssl_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_smtp_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : Could not find the libsf_ftptelnet_preproc file. Snort might error out!
    Apr 22 09:27:54	php: : The Rules update has finished.
    Apr 22 09:27:44	php: : EmergingThreats rules file update downloaded succsesfully
    Apr 22 09:27:35	php: : There is a new set of EmergingThreats rules posted. Downloading...
    Apr 22 09:27:35	php: : Snort Rules Attempts: 1
    Apr 22 09:27:14	php: : There is a new set of Snort VRT rules posted. Downloading...
    
    

    It seemed that everything was written to /etc/snort instead of to /usr/pbi/snort-i386/.
    Even /lib/snort was written. I could recover by updating the rules again but then:

    
    Apr 22 09:46:48	snort[91557]: FATAL ERROR: The dynamic detection library "/usr/pbi/snort-i386/lib/snort/dynamicrules/lib_sfdynamic_example_rule.so" version 1.0 compiled with dynamic engine library version 1.0 isn't compatible with the current dynamic engine library "/usr/pbi/snort-i386/lib/snort/dynamicengine/libsf_engine.so" version 1.17.
    Apr 22 09:46:48	php: /snort/snort_interfaces.php: Toggle(snort starting) for WAN(WAN)...
    

    So I deinstalled snort and "rm -rf" all snort directories and installed snort again. Snort is up again.
    I don't know what went wrong but I will try again on a VM. I suppose I can avoid this by deinstalling snort before upgrading my pfSense snapshot and install snort later.

    Were you running 2.1-BETA already, and just upgraded to the latest snapshot of that release, or did you upgrade a 2.0.x box to the latest 2.1-BETA snapshot?  Just trying to get a handle on the set of conditions so I can try it in my VM world.

    Bill


  • Banned

    A funny thing…

    Notice the date difference in the Snort Widget.

    The extra 13 inserted is the one with the package update.






  • @Supermule:

    A funny thing…

    Notice the date difference in the Snort Widget.

    The extra 13 inserted is the one with the package update.

    This may be caused by the change I made in Snort and Barnyard2 to record the year in timestamps.  Apparently the Snort Widget package is not quite sure how to cope with that ??  I've never used nor installed the widget, but I guess it's time I did so on a VM to see what dependencies it has with the main package.

    Bill


  • Banned

    I think it would be a good idea Bill :D



  • @bmeeks:

    Were you running 2.1-BETA already, and just upgraded to the latest snapshot of that release, or did you upgrade a 2.0.x box to the latest 2.1-BETA snapshot?  Just trying to get a handle on the set of conditions so I can try it in my VM world.

    I had 2.1 already running.

    BTW: this didn't happen before, so I think it has to do with latest 2.5.6 changes



  • @Supermule:

    I think it would be a good idea Bill :D

    Found the issue with date formatting in the Snort Dashboard Widget.  It's just a case of the old code doing hard substring breaks as it picks out the date from the timestamp.  The extra two-character year is now tripping it up.  I will submit a fix for it this evening when I get home that looks for the actual break character inserted by Snort (a dash character, "-").  This way it will work with either the old timestamps without the year or the new ones with the year.  Will also incorporate a "test" to make sure Snort is installed before the Widget tries to use some Snort files. That should prevent the error some folks reported when they had the Widget still installed, but had removed Snort itself.

    Bill


  • Banned

    Thunks up!!!



  • @gogol:

    @bmeeks:

    Were you running 2.1-BETA already, and just upgraded to the latest snapshot of that release, or did you upgrade a 2.0.x box to the latest 2.1-BETA snapshot?  Just trying to get a handle on the set of conditions so I can try it in my VM world.

    I had 2.1 already running.

    BTW: this didn't happen before, so I think it has to do with latest 2.5.6 changes

    It really shouldn't, because nothing in that part of the code (the package deinstall/reinstall) was touched this time.  The snapshot updates have had some issues of their own from time to time.  This morning, as a test, I upgraded a 2.0.2 box with the 2.5.5 Snort package to 2.0.3 and let it also upgrade the Snort package at same time.  This happens pretty much automatically because any firmware upgrade reinstalls all the packages.

    I have a 2.1-BETA VM I can test this on later.  It is on an older snapshot and has the 2.5.5 Snort package.

    Bill



  • 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.



  • Bill, everything working great on AMD64, 2.0.3 dual WAN etc. after this update. Thanks again for your work on the package :-)  As always, I uninstalled the package and then ran this command from the command line:```
    find /* | grep -i snort | xargs rm -rv

    
    Cheers,
    Dennis.


  • So far all is good on my LGA1155, G630T box with plenty of RAM and full install on SSD. 1 auto update has completed without issues.

    Only "issue" I have with Snort left is blocked list not surviving filter reload, but I'm not sure if that is by design or accidental feature.



  • @fragged:

    Only "issue" I have with Snort left is blocked list not surviving filter reload, but I'm not sure if that is by design or accidental feature.

    The "snort2c" table is not saved anywhere, so this is by design.



  • @gogol:

    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



  • @Supermule:

    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



  • @bmeeks:

    @Supermule:

    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


  • Banned

    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: 1

    Its 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: 1

    I find it a bit weird that the rules are up to date since one of the FW reports new rules are available.....?



  • @bmeeks:

    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.



  • @bmeeks:

    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



  • @Supermule:

    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: 1

    Its 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: 1

    I 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



  • @gogol:

    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.





  • Banned

    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:



  • Banned

    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.




  • @Supermule:

    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



  • @cjbujold:

    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 snort

    
    from 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

  • Banned

    We need a Snort bloq :D

    @bmeeks:

    @Supermule:

    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



  • @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



  • @judex:

    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



  • @judex:

    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


  • Banned

    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: 3

    Box 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: 1

    Everything is running as it should on 2.5.6 :)



  • @Supermule:

    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



  • @bmeeks:

    <awesome stuff="">Bill</awesome>

    Awesome! Thanks!


Log in to reply