Snort failing to start on WAN



  • I am fairly new and have been following guides on setting up snort on wan and lan. I had an issue with subscription rules not updating which is now resolved.

    Now I am getting Snort won't restart on wan.

    System Logs show:

    FATAL ERROR: /usr/local/etc/snort/snort_65265_em0/rules/snort.rules(427) Unknown rule option: 'sd_pattern'.

    After rebooting pfsense I get his as well:

    /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 65265 -D -q –suppress-config-log -l /var/log/snort/snort_em065265 --pid-path /var/run --nolock-pidfile -G 65265 -c /usr/local/etc/snort/snort_65265_em0/snort.conf -i em0' returned exit code '1', the output was ''



  • You have most likely enabled "sensitive data" rules but the Sensitive Data Preprocessor (SDF) is disabled on the PREPROCESSORS tab.  This is an old song and dance, and if you search the forum here for "disabled preprocessor" you will find a lot of replies from me to folks who have done the same thing for other preprocessors.  Do not monkey with the Snort package defaults until you are very familiar with what all the options do.  In particular it is dangerous to make assumptions about things on the PREPROCESSORS tab and start disabling things there (or enabling default disabled ones without understanding the ramifications).

    I think you probably have a self-inflicted problem.  If you enabled the SD preprocessor, make sure you restart Snort on the interface.

    Bill



  • Yes that was it ty. I did disable SDF after reading through threads - not sure what the reason was though.

    Should I select anything to inspect for or leave it blank.

    I have spent the last 5 days and night straight (home network) going from "taming the beast thread" - I have only followed the first part of those rules on page 1, through to snort, which I have enabled on both lan and wan.

    I have followed the quick setup on Snort from yourself and jflsakfja.

    This firewall is on a dmz from my main router - running on a different subnet to a lan and wifi ap so I can test before moving to replace the router.

    I am also having issues with the http_inspect. I have read the threads on disabling and or adding sites to a whitelist but still having alot of sites blocked like speedtest.net

    Slim



  • The Sensitive Data rules have very limited benefit in my view in a home network environment.  They are more typically used in the corporate world to check for personally identifying information (SSN, etc.) being transmitted out of a corporate network.  I don't run SD in my setup at home.

    As for the HTTP_INSPECT preprocessor, it will cause a large number of false positives because so many web sites today violate some small letter of RFC rules.  I have a ton of the HTTP_INSPECT rules either disabled or suppressed.  Don't disable that whole preprocessor, though.  If you do, it will break other more necessary and critical rules.  Only disable the individual HTTP_INSPECT rules that give you trouble.

    The best way to get a handle on Snort or Suricata is to run them for several weeks in "alert only" mode, or in other words, with blocking disabled.  Then keep watch on all the alerts you get.  Decide which are likely false positives, disable those rules or suppress those alerts, then after maybe a month turn on blocking mode.

    Bill



  • Hi,

    Just did the upgrade from 3.2.9.2 , but the service for WAN was failed to restart:

    /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 27035 -D -q –suppress-config-log -l /var/log/snort/snort_igb027035 --pid-path /var/run --nolock-pidfile -G 27035 -c /usr/local/etc/snort/snort_27035_igb0/snort.conf -i igb0' returned exit code '1', the output was ''

    FATAL ERROR: /usr/local/etc/snort/snort_27035_igb0/rules/snort.rules(4000) byte_test rule option cannot extract more than 4 bytes without valid string prefix.

    Snort for my LAN and WLAN are working though.  How to fix it for the WAN??

    EDIT: Figured it out. That was due to ET Exploit rule 2002802, I have to disable it by now:

    alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET EXPLOIT Windows Media Player parsing BMP file with 0 size offset to start of image"; flow:established,from_server; file_data; content:"BM";  depth:2; byte_test:8,=,0,4,relative; reference:url,www.milw0rm.com/id.php?id=1500; reference:url,www.microsoft.com/technet/security/Bulletin/MS06-005.mspx; reference:cve,2006-0006; reference:bugtraq,16633; reference:url,doc.emergingthreats.net/bin/view/Main/2002802; classtype:attempted-user; sid:2002802; rev:10;)

    Damn it. whats going on there. It was working fine in the previous Snort version.



  • I had the very same problem after upgrading to 3.2.9.3.  After disabling 2002802, the WAN service started without issue.

    How in the world did you figure out it was that specific SID?  Just curious if I'm missing something in a log that would have helped me troubleshoot.

    Here was my error:

    FATAL ERROR: /usr/local/etc/snort/snort_41202_em0/rules/snort.rules(1420) byte_test rule option cannot extract more than 4 bytes without valid string prefix.
    


  • @rebman77:

    I had the very same problem after upgrading to 3.2.9.3.  After disabling 2002802, the WAN service started without issue.

    How in the world did you figure out it was that specific SID?  Just curious if I'm missing something in a log that would have helped me troubleshoot.

    Here was my error:

    FATAL ERROR: /usr/local/etc/snort/snort_41202_em0/rules/snort.rules(1420) byte_test rule option cannot extract more than 4 bytes without valid string prefix.
    

    The error message tells you the file and the line number within the file where the error is.  So in this case, the file is /usr/local/etc/snort/snort_41202_em0/rules/snort.rules and the error is happening on line 1420 in that file.

    Bill



  • @pfcode:

    Hi,

    Just did the upgrade from 3.2.9.2 , but the service for WAN was failed to restart:

    /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 27035 -D -q –suppress-config-log -l /var/log/snort/snort_igb027035 --pid-path /var/run --nolock-pidfile -G 27035 -c /usr/local/etc/snort/snort_27035_igb0/snort.conf -i igb0' returned exit code '1', the output was ''

    FATAL ERROR: /usr/local/etc/snort/snort_27035_igb0/rules/snort.rules(4000) byte_test rule option cannot extract more than 4 bytes without valid string prefix.

    Snort for my LAN and WLAN are working though.  How to fix it for the WAN??

    EDIT: Figured it out. That was due to ET Exploit rule 2002802, I have to disable it by now:

    alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET EXPLOIT Windows Media Player parsing BMP file with 0 size offset to start of image"; flow:established,from_server; file_data; content:"BM";  depth:2; byte_test:8,=,0,4,relative; reference:url,www.milw0rm.com/id.php?id=1500; reference:url,www.microsoft.com/technet/security/Bulletin/MS06-005.mspx; reference:cve,2006-0006; reference:bugtraq,16633; reference:url,doc.emergingthreats.net/bin/view/Main/2002802; classtype:attempted-user; sid:2002802; rev:10;)

    Damn it. whats going on there. It was working fine in the previous Snort version.

    According to the release notes for the Snort 2.9.9.0 binary, some changes were made to the byte_math and byte_test code.  Those changes may be the cause.  Perhaps the ET guys need to adapt/update that rule for the changes made in the new binary.

    Bill



  • @bmeeks:

    @rebman77:

    I had the very same problem after upgrading to 3.2.9.3.  After disabling 2002802, the WAN service started without issue.

    How in the world did you figure out it was that specific SID?  Just curious if I'm missing something in a log that would have helped me troubleshoot.

    Here was my error:

    FATAL ERROR: /usr/local/etc/snort/snort_41202_em0/rules/snort.rules(1420) byte_test rule option cannot extract more than 4 bytes without valid string prefix.
    

    The error message tells you the file and the line number within the file where the error is.  So in this case, the file is /usr/local/etc/snort/snort_41202_em0/rules/snort.rules and the error is happening on line 1420 in that file.

    Bill

    So what do you do about it?

    that rule (emerging-exploits 2002802) is disabled by default, so it didn't cause a problem on my end….

    Not bashing anyone, but sometimes those with a lot of expertise are wonderful at identifying errors for the forum but stop short of providing a solution.

    Rick



  • @Ramosel:

    @bmeeks:

    @rebman77:

    I had the very same problem after upgrading to 3.2.9.3.  After disabling 2002802, the WAN service started without issue.

    How in the world did you figure out it was that specific SID?  Just curious if I'm missing something in a log that would have helped me troubleshoot.

    Here was my error:

    FATAL ERROR: /usr/local/etc/snort/snort_41202_em0/rules/snort.rules(1420) byte_test rule option cannot extract more than 4 bytes without valid string prefix.
    

    The error message tells you the file and the line number within the file where the error is.  So in this case, the file is /usr/local/etc/snort/snort_41202_em0/rules/snort.rules and the error is happening on line 1420 in that file.

    Bill

    So what do you do about it?

    that rule (emerging-exploits 2002802) is disabled by default, so it didn't cause a problem on my end….

    Not bashing anyone, but sometimes those with a lot of expertise are wonderful at identifying errors for the forum but stop short of providing a solution.

    Rick

    The solution is to disable the rule if you had it enabled.  I have not investigated to verify, but as you say, that rule very well may be disabled by default in the category.  So users who had not monkeyed with any rule defaults (in terms what the authors publish as default enabled or default disabled) would not see the error.  I did not see it my virtual machine testing last night prior to posting the update.

    Bill



  • As always, Thanks Bill.

    So that's what I was hoping for as the correct (immediate) solution.  Even though the error identifies down to a file and a line within the file, there is really nothing you can do with that file or the offending line to resolve the issue cleanly…

    Rick



  • @Ramosel:

    As always, Thanks Bill.

    So that's what I was hoping for as the correct (immediate) solution.  Even though the error identifies down to a file and a line within the file, there is really nothing you can do with that file or the offending line to resolve the issue cleanly…

    Rick

    No, nothing other than disabling the offending rule until the rule authors fix it.  You could, if you wanted to research and fix the syntax, edit the actual ET Open rules file in /usr/local/etc/snort/rules.  Then it would be fine until the next daily rules update when your "fix" could get overwritten.

    Here's how rule generation works in the package.  All of the actual rules files from the vendors (ET or VRT) are stored in /usr/local/etc/snort/rules.  The ET rules have "emerging" pre-pended to their category names.  When the GUI package processes your selected/enabled rules, it grabs them from the relevent rules files in that directory and assembles them into the snort.rules file referenced in the error message.  That snort.rules file will contain all of the enabled and active rules for your Snort setup.  There is also a flowbit-required.rules file in the same directory as snort.rules.  That file contains any needed rules to satisfy flowbit requirements from your enabled/selected rules.  The snort.rules and flowbit-required.rules files are rebuilt each time Snort restarts, each time you save a change in the GUI, and after each automatic rules update.  They are rebuilt with content pulled from that master copy of the original rules files stored in /usr/local/etc/snort/rules.

    Bill



  • May 31 16:30:37 snort 71308 FATAL ERROR: The dynamic detection library "/usr/local/lib/snort_dynamicrules/browser-plugins.so" version 1.0 compiled with dynamic engine library version 2.6 isn't compatible with the current dynamic engine library "/usr/local/lib/snort_dynamicengine/libsf_engine.so" version 3.0.

    May 31 16:30:37 SnortStartup 71190 Snort START for WAN(37034_igb0)…


    Snort won't start here either. The rule discussed above is not involved.

    pfSense and Snort updated to most current versions.

    edit: to be clear, this problem started after I updated to the newest snort package available after upgrading pfSense to the newest version. The problem has no connection to the rule mentioned far above. The error message should make that clear. It looks like an obsolete library is involved. The rule mentioned above is not active, btw. It appears to be off by default.



  • @coffeecup25:

    May 31 16:30:37 snort 71308 FATAL ERROR: The dynamic detection library "/usr/local/lib/snort_dynamicrules/browser-plugins.so" version 1.0 compiled with dynamic engine library version 2.6 isn't compatible with the current dynamic engine library "/usr/local/lib/snort_dynamicengine/libsf_engine.so" version 3.0.

    May 31 16:30:37 SnortStartup 71190 Snort START for WAN(37034_igb0)…


    Snort won't start here either. The rule discussed above is not involved.

    pfSense and Snort updated to most current versions.

    edit: to be clear, this problem started after I updated to the newest snort package available after upgrading pfSense to the newest version. The problem has no connection to the rule mentioned far above. The error message should make that clear. It looks like an obsolete library is involved. The rule mentioned above is not active, btw. It appears to be off by default.

    Completely remove the Snort package and then reinstall it.  That should fix the problem.  Snort versions have tags that tie all the pieces together via the version number.  The shared object rules are tied that way.  Your error indicates the older version of the shared object rule libraries are being used instead of the newer ones.  A total remove and reinstall should fix it.

    In fact, because of the way PHP will cache files and reuse them during execution, it is generally best to completely remove and then reinstall Snort or Suricata when doing an upgrade.  So long as the "save settings" toggle is ON (and that is the default in both packages), then you won't lose any of your configuration.

    Bill



  • @bmeeks:

    @coffeecup25:

    May 31 16:30:37 snort 71308 FATAL ERROR: The dynamic detection library "/usr/local/lib/snort_dynamicrules/browser-plugins.so" version 1.0 compiled with dynamic engine library version 2.6 isn't compatible with the current dynamic engine library "/usr/local/lib/snort_dynamicengine/libsf_engine.so" version 3.0.

    May 31 16:30:37 SnortStartup 71190 Snort START for WAN(37034_igb0)…


    Snort won't start here either. The rule discussed above is not involved.

    pfSense and Snort updated to most current versions.

    edit: to be clear, this problem started after I updated to the newest snort package available after upgrading pfSense to the newest version. The problem has no connection to the rule mentioned far above. The error message should make that clear. It looks like an obsolete library is involved. The rule mentioned above is not active, btw. It appears to be off by default.

    Completely remove the Snort package and then reinstall it.  That should fix the problem.  Snort versions have tags that tie all the pieces together via the version number.  The shared object rules are tied that way.  Your error indicates the older version of the shared object rule libraries are being used instead of the newer ones.  A total remove and reinstall should fix it.

    In fact, because of the way PHP will cache files and reuse them during execution, it is generally best to completely remove and then reinstall Snort or Suricata when doing an upgrade.  So long as the "save settings" toggle is ON (and that is the default in both packages), then you won't lose any of your configuration.

    Bill

    I did that with the save settings on before writing about it here. It didn't work. Same error. Any other ideas?

    edit: A few months ago I did a router reset and reloaded all settings from a backup. I messed it up playing with DNSBL and a full reset was the only way I knew how to fix it. My point: the system was relatively clean when I updated it recently.



  • Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 37034 -D -q –suppress-config-log -l /var/log/snort/snort_igb037034 --pid-path /var/run --nolock-pidfile -G 37034 -c /usr/local/etc/snort/snort_37034_igb0/snort.conf -i igb0' returned exit code '1', the output was ''

    Jun 3 07:43:08 snort 70972 FATAL ERROR: The dynamic detection library "/usr/local/lib/snort_dynamicrules/browser-plugins.so" version 1.0 compiled with dynamic engine library version 2.6 isn't compatible with the current dynamic engine library "/usr/local/lib/snort_dynamicengine/libsf_engine.so" version 3.0.

    Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: [Snort] Snort START for WAN(igb0).
    ..
    Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: Starting Snort on WAN(igb0) per user request…


    Just for grins, I tried the unload / reload again. It didn't work.  Since I'm a normal user who uses pfSense in a normal way, I can only suspect that others who use snort and have upgraded have the same problem. Since it's silent and since, I assume, few look at their router page very often, I assume I'm not the only person who upgraded who has this problem. I just happened to notice. It looks like an upgrade installation problem. Obviously, it must work for a lot of people. But, that's the joy of programming for the public.

    The only packages I use are snort, pfblockerNG and openvpn and all in straightforward ways.



  • @coffeecup25:

    Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 37034 -D -q –suppress-config-log -l /var/log/snort/snort_igb037034 --pid-path /var/run --nolock-pidfile -G 37034 -c /usr/local/etc/snort/snort_37034_igb0/snort.conf -i igb0' returned exit code '1', the output was ''

    Jun 3 07:43:08 snort 70972 FATAL ERROR: The dynamic detection library "/usr/local/lib/snort_dynamicrules/browser-plugins.so" version 1.0 compiled with dynamic engine library version 2.6 isn't compatible with the current dynamic engine library "/usr/local/lib/snort_dynamicengine/libsf_engine.so" version 3.0.

    Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: [Snort] Snort START for WAN(igb0).
    ..
    Jun 3 07:43:08 php-fpm 66173 /snort/snort_interfaces.php: Starting Snort on WAN(igb0) per user request…


    Just for grins, I tried the unload / reload again. It didn't work.  Since I'm a normal user who uses pfSense in a normal way, I can only suspect that others who use snort and have upgraded have the same problem. Since it's silent and since, I assume, few look at their router page very often, I assume I'm not the only person who upgraded who has this problem. I just happened to notice. It looks like an upgrade installation problem. Obviously, it must work for a lot of people. But, that's the joy of programming for the public.

    The only packages I use are snort, pfblockerNG and openvpn and all in straightforward ways.

    Same here. Only using OpenET rules and only on WAN plus pfBlockNG with top 20 spammers, no other packages. Box is an APU2C4.



  • Do this to manually clean up those errant libraries.  For some reason on your systems (@coffecup25 and @Jailer) the package removal process is failing to delete all the files.

    1.  Remove the Snort package.
    2.  Open a CLI window using an SSH client (or use the CLI directly if you have physical firewall access).
    3.  Delete any and all snort directories you find under /usr/local/lib and anywhere else on /usr.

    Now exit the CLI and reinstall the package from the GUI.  That should fix it.

    Bill



  • @bmeeks:

    Do this to manually clean up those errant libraries.  For some reason on your systems (@coffecup25 and @Jailer) the package removal process is failing to delete all the files.

    1.  Remove the Snort package.
    2.  Open a CLI window using an SSH client (or use the CLI directly if you have physical firewall access).
    3.  Delete any and all snort directories you find under /usr/local/lib and anywhere else on /usr.

    Now exit the CLI and reinstall the package from the GUI.  That should fix it.

    Bill

    Will this delete all my current settings requiring Snort to be re tuned?



  • @Jailer:

    @bmeeks:

    Do this to manually clean up those errant libraries.  For some reason on your systems (@coffecup25 and @Jailer) the package removal process is failing to delete all the files.

    1.  Remove the Snort package.
    2.  Open a CLI window using an SSH client (or use the CLI directly if you have physical firewall access).
    3.  Delete any and all snort directories you find under /usr/local/lib and anywhere else on /usr.

    Now exit the CLI and reinstall the package from the GUI.  That should fix it.

    Bill

    Will this delete all my current settings requiring Snort to be re tuned?

    No.  All Snort interface settings are saved in the firewall's config.xml file.  The only "settings" saved on the disk are log files in /var/log/snort and any SID management files saved in /var/db/snort/sidmods.  There is nothing on the /usr volume that is part of the saved system settings for Snort.

    Bill



  • Bill you're a genius, thank you. Snort is up and running again.

    Now where is @Doktornotor to complain about that package manager….......



  • Got it. Thanks. It works again.

    Suggestion: Unless this is a 1 in a million issue or unless future updates will look for this problem and fix it quietly, define the problem and solution in a sticky somewhere. This will make it less disruptive for everyone.

    Edit: Could this have caused it?  My Admin profile is disabled since I consider it to be a security problem. Another profile has Admin duties. I had to enable Admin to perform the SSH folder deletion. Is it possible that this problem occurred because I updated Snort while not using the pfSense defined Admin profile?



  • I use the default admin profile and had the same issue so that's not likely the problem.


Log in to reply