Strange log entry after update
-
I started a reinstall of Snort and in the log I found this line - maybe that has something to do with the untar command returning something non zero:
"Installing Snort Subscriber ruleset...tar: so_rules/precompiled/FreeBSD-12/x86-64/2.9.19.0: Not found in archive"
and now tons of (with diverse SIDs):
Encoded Rule Plugin SID: 58807, GID: 3 not registered properly. Disabling this rule.
Encoded Rule Plugin SID: 54601, GID: 3 not registered properly. Disabling this rule.
etc...(Disabling IPS Policy makes this entries disappearing - obviously this error is IPS Policy related)
-
@fireodo said in Strange log entry after update:
I started a reinstall of Snort and in the log I found this line - maybe that has something to do with the untar command returning something non zero:
"Installing Snort Subscriber ruleset...tar: so_rules/precompiled/FreeBSD-12/x86-64/2.9.19.0: Not found in archive"
and now tons of (with diverse SIDs):
Encoded Rule Plugin SID: 58807, GID: 3 not registered properly. Disabling this rule.
Encoded Rule Plugin SID: 54601, GID: 3 not registered properly. Disabling this rule.
etc...(Disabling IPS Policy makes this entries disappearing - obviously this error is IPS Policy related)
Well, I know where that error is coming from. It may not be correctable. I will have to investigate.
The Shared Object (SO) rules are precompiled binary modules. They are actually written in the C programming language and compiled like a binary executable. They are compiled for a particular version of FreeBSD and a few other operating systems. Since pfSense is now up to FreeBSD 12.3 STABLE, it is possible there are no SO modules compatible with the new FreeBSD version.
Update: I don't see an easy fix for this until pfSense moves to the FreeBSD 13 branch. The only precompiled SO rules in the new Snort rules package are compiled for FreeBSD 13. I will investigate to see if changing the rules update process in the Snort package to work around this is possible.
-
@bmeeks said in Strange log entry after update:
Well, I know where that error is coming from. It may not be correctable. I will have to investigate.
Aha, good to know its not something specifically for my system ...
The Shared Object (SO) rules are precompiled binary modules. They are actually written in the C programming language and compiled like a binary executable. They are compiled for a particular version of FreeBSD and a few other operating systems. Since pfSense is now up to FreeBSD 12.3 STABLE, it is possible there are no SO modules compatible with the new FreeBSD version.
Thats what I also thought but I am no specialist ...
As I investigated I found this error "Failed to extract a rules-update archive." began early at begin of the month of march 2022 (the last update without error was 25.02.2022 and the first with error was 02.03.2022)
My update to pfsense 2.6.0 was on 14.02.2022. -
@fireodo said in Strange log entry after update:
As I investigated I found this error "Failed to extract a rules-update archive." began early at begin of the month of march 2022 (the last update without error was 25.02.2022 and the first with error was 02.03.2022)
My update to pfsense 2.6.0 was on 14.02.2022.That's probably when they changed the directory name in the rules tarball from FreeBSD 12 to FreeBSD 13. It's named "FreeBSD-13" now. I'm testing some solutions.
-
@bmeeks said in Strange log entry after update:
It's named "FreeBSD-13" now
Hope the rules are not compiled only for FreeBSD 13 ...
I'm testing some solutions.
Oh, many thanks!
-
I've created a Redmine Issue to track this: https://redmine.pfsense.org/issues/12979. I assigned it to myself. I'm working on the fix and will submit a Pull Request for the pfSense to review and merge in the very near future. Thank you for the report.
-
@bmeeks said in Strange log entry after update:
Thank you for the report.
You're welcome - and thank you for your work!
Kind regards,
fireodo -
I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.
-
@bmeeks said in Strange log entry after update:
I have posted a Pull Request to the pfSense Packages GitHub repo to address this issue. Here is a link to the request: https://github.com/pfsense/FreeBSD-ports/pull/1149. I've sent the pfSense developer team an email asking for an expedited review and merge.
Thank you!
PS. I can confirm it works! :-) -
The fix for the issue reported in this thread has been merged into Snort package version 4.1.5_2. This build should show up in the 2.6.0 CE and pfSense Plus 22.01 package repos as an available update shortly. The new version will appear in the DEVEL tree after the next snapshot rebuild happens there (likely overnight).
-
Hi Bill,
the error returned this morning but I can see any directory name change in the recent snapshot archive snortrules-snapshot-29190.tar.gz (like the FreeBSD-13 change). Needles to say that I dont have change anything in Snort since the last update and there is plenty of free disk space (df -h = zroot/tmp zfs 9.8G 396K 9.8G 0% /tmp).
"[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz"
Is there a possibility to start a update with more detailed log output to see whats the real problem? Because this error message is identic whit the one when the Snort Team has changed the denomination of the directory (FreeBSD-12 -> FreeBSD-13).Kind regards,
fireodo -
Hello,
Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")Thanks,
fireodo -
@fireodo said in Strange log entry after update:
Hello,
Does anybody else can confirm this?
("[Snort] Failed to extract a rules-update archive. Some snort rules might still be out-of-date. Make sure there is enough free disk space and try again. Tar file:/tmp/snort_rules_up/snortrules-snapshot-29190.tar.gz")Thanks,
fireodoI confirmed it. The Snort VRT has changed part of the pathname inside the tarball. They changed
x86_64tox86-64in part of the path.Here is a quick fix while I work on submitting a Pull Request to update the package.
Use your favorite text editor for Unix and edit the following file at the lines shown. Making a backup copy of the file prior to editing is recommended!
/usr/local/pkg/snort/snort_check_for_rule_updates/phpFind lines 631 and 632 in the file. They look like this:
if(snort_untar("xzf", "{$tmpfname}/{$snort_filename}", "{$tmpfname}", "so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/")) { snort_copy("{$tmpfname}/so_rules/precompiled/{$freebsd_version_so}/x86_64/{$snort_version}/*.so", "{$snortlibdir}/snort_dynamicrules/");Change the two instances of
x86_64tox86-64(one per line) and save the change. -
@bmeeks said in Strange log entry after update:
They changed x86_64 to x86-64 in part of the path.
Oha - my bad - that I have overlooked! Thanks a lot!
-
@bmeeks said in Strange log entry after update:
Use your favorite text editor for Unix and edit the following file at the lines shown. Making a backup copy of the file prior to editing is recommended!
/usr/local/pkg/snort/snort_check_for_rule_updates/phpDone and confirm it works as expected!
Thank you!
-
Pull Requests have been submitted to correct this issue in both the DEVEL and RELENG_2_6_0 branches of pfSense. I attempted to make the code a little more tolerant of any future path name changes in the Snort Rules update archive file. Look for a Snort package update to version 4.1.5_3 in the near future. The requests are here:
https://github.com/pfsense/FreeBSD-ports/pull/1161
https://github.com/pfsense/FreeBSD-ports/pull/1162In the meantime, if you hit this bug before the package update is posted, the quick fix is shown in an earlier post of mine above.
UPDATE: the pull requests listed above have been merged into their respective pfSense branches.
