Snort failing to start on WAN
-
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
-
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
-
@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
-
@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
-
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.
-
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
-
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.
-
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
-
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?
-
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.
