Snort 2.9.2.3 pkg v. 2.5.0 Issues
-
Marcello,
apply your patches and follow pull request options
that was easy.
-
The following applies only for a fresh installation of snort. You must remove the package before applying the following recipe. The procedure is also recommended only for courageous fellows.
(1) Install the snort package
(2) Go to Status: System logs: System
(3) If you find one or more of the following error messages:
Jul 20 18:57:33 php: /pkg_mgr_install.php: Beginning package installation for snort.
Jul 20 18:57:33 check_reload_status: Syncing firewall
Jul 20 18:58:22 php: /pkg_mgr_install.php: The command '/usr/bin/sed -I '' -e -f /tmp/sedcmd /usr/local/etc/snort/snort_26134_em0/preproc_rules/preprocessor.rules' returned exit code '1', the output was 'sed: 1: "-f ": invalid command code -'
Jul 20 18:58:22 php: /pkg_mgr_install.php: The command '/usr/bin/sed -I '' -e -f /tmp/sedcmd /usr/local/etc/snort/snort_26134_em0/preproc_rules/decoder.rules' returned exit code '1', the output was 'sed: 1: "-f ": invalid command code -'
Jul 20 18:58:22 php: /pkg_mgr_install.php: The command '/usr/bin/sed -I '' -e -f /tmp/sedcmd /usr/local/etc/snort/snort_26134_em0/preproc_rules/preprocessor.rules' returned exit code '1', the output was 'sed: 1: "-f ": invalid command code -'
Jul 20 18:58:22 php: /pkg_mgr_install.php: The command '/usr/bin/sed -I '' -e -f /tmp/sedcmd /usr/local/etc/snort/snort_26134_em0/preproc_rules/decoder.rules' returned exit code '1', the output was 'sed: 1: "-f ": invalid command code -'
Jul 20 18:58:22 check_reload_status: Syncing firewall
Jul 20 18:58:23 check_reload_status: Reloading filter
Jul 20 18:58:23 check_reload_status: Syncing firewallproceed with (4), otherwise stop.
(4) In file /usr/local/pkg/snort/snort.inc find the lines at the end with the sed commands
@file_put_contents("{$g['tmp_path']}/sedcmd", $sedcmd); mwexec("/usr/bin/sed -I '' -e -f {$g['tmp_path']}/sedcmd {$snortcfgdir}/preproc_rules/preprocessor.rules"); mwexec("/usr/bin/sed -I '' -e -f {$g['tmp_path']}/sedcmd {$snortcfgdir}/preproc_rules/decoder.rules"); @unlink("{$g['tmp_path']}/sedcmd");
and update as follows
@file_put_contents("{$g['tmp_path']}/sedcmd", $sedcmd); mwexec("/usr/bin/sed -I.bak -f {$g['tmp_path']}/sedcmd {$snortcfgdir}/preproc_rules/preprocessor.rules"); mwexec("/usr/bin/sed -I.bak -f {$g['tmp_path']}/sedcmd {$snortcfgdir}/preproc_rules/decoder.rules"); @unlink("{$g['tmp_path']}/sedcmd");
See also: https://github.com/bsdperimeter/pfsense-packages/pull/286/files
(5) Within the webConfigurator go to Diagnostics: Command Prompt and enter the 2 php statements into the PHP execute field:
require_once('/usr/local/pkg/snort/snort.inc');
snort_postinstall();This operates silently unless there is an error.
(6) Check the result with
find /usr/local/etc/snort -name '*.bak'
You should see at least 2 backup files.
Good luck.
UPDATE: the patch does not solve the
FATAL ERROR: /usr/local/etc/snort/snort_9486_em1/preproc_rules/preprocessor.rules(202) Unknown ClassType: sdf
problem (though that should be easy to fix, rules were commented out a couple of days ago, but I don't know what the real problem was). -
Marcello,
do you have a quick explanation how the GUI part of a package gets installed? Obviously, there are no PHP files inside snort-2.9.2.3.tbz. Maybe they come from pkg-config-0.25_1.tbz or somewhere else.
Thanx for your time.
-
Do you have a quick explanation how the GUI part of a package gets installed?
The package install script copy xml, inc and php files and then install freebsd package.
att,
Marcello Coutinho -
Ermal, am seeing consistently the same behaviour now with Snort 2.5.0 on AMD64 2.0.1 ( 2 different installations)
1. If emerging threats or snort files are not updated, all ok.
2. If either file set is updated during auto update, the GUI shows both interfaces stopped.
3. Running ps aux | grep snort however shows one of the two interfaces running.$ ps aux | grep snort
root 17164 0.0 0.1 9120 1124 ?? S 1:24AM 0:00.01 grep snort4. If I attempt to start the interface from the GUI, the log generates:
snort[57587]: FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Cheers,
Dennis. -
$ ps aux | grep snort
root 17164 0.0 0.1 9120 1124 ?? S 1:24AM 0:00.01 grep snortI do not see any interface running, just a grep process that searches for snort…
Anyway, the impacts seem to be very different. So I have to delete the MD5 file and snort rules get downloaded. If I do not do that and update manually snort keeps running - no sdf error any more. Autoupdate always returns that "download 15 min blabla etc..." message.
-
I've suggested a code change (https://github.com/Fesoj/pfsense-packages/compare/patch-2). This and obeying aaronritter's remark (http://forum.pfsense.org/index.php/topic,51493.msg275905.html#msg275905) seems to let the sensitive data preproc run correctly. Currently, the classification.config files should be patched by hand after every update of the rules.
I haven't found the place that writes the classification.config files. If this gets patched, snort should survive updates again.
UPDATE: with package vs. 2.5.1 this is obsolete
-
Hello,
just uninstalled/reinstalled this morning, the package works fine (Sensitive Data Processor disabled), but it still blocks the WAN addresses… so I am still running with blocking off.Thanks,
Michele -
mdima,
do you mean with WAN address the WAN side of your box or any outside address? If it is the WAN address of your box, then you need to add the ip to the whitelist of the interface.
-
@Fesoj: It's the same, with or without whitelist… and by default it should exclude local IP addresses and so on.
Probably this can help: my current HomeNet is an Alias that contains sub-aliases of local and remote IP addresses that should not be detected/blocked by Snort...
Thanks,
Michele -
mdima,
HOME_NET != WHITELIST. On the WAN side, I have the default HOME_NET, but a special whitelist (including the IP address on the WAN side (I don't know what to do in case of an ISP supplied address using DHCP)) and this works fine. It's just the way things are setup. As I said before, it is now easier than ever to shoot oneself in the foot.
-
snort[57587]: FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
has been observed here several times. If you have installed only the ET rules, the file classification.config does not contain the required entry. The rules from Snort.org do have the definition. Both rule sets contain their own classification.config file. I think only 1 of them gets installed (but I may be wrong).
ermal, could you please have a look at this issue?
UPDATE: with package vs. 2.5.1 this is obsolete
-
mdima,
HOME_NET != WHITELIST. On the WAN side, I have the default HOME_NET, but a special whitelist (including the IP address on the WAN side (I don't know what to do in case of an ISP supplied address using DHCP)) and this works fine. It's just the way things are setup. As I said before, it is now easier than ever to shoot oneself in the foot.
Fesoj, I already specified as Whitelist the Alias where my WAN network is, and anyway it gets blocked. Before this didn't happen, I think it has something to do with the new features of the whitelist management…
-
snort[57587]: FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
has been observed here several times. If you have installed only the ET rules, the file classification.config does not contain the required entry. The rules from Snort.org do have the definition. Both rule sets contain their own classification.config file. I think only 1 of them gets installed (but I may be wrong).
ermal, could you please have a look at this issue?
I too am now consistently receiving this same error in my system log and am unable to start my interface manually. I wish snort still auto-updated snort rules and successfully restarted after the rules update. Has since become a manual process recently.
snort[57587]: FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
-
I currently have no problems and everything works as expected.
Did you have a look at
(1) http://forum.pfsense.org/index.php/topic,51493.msg275905.html#msg275905
(2) http://forum.pfsense.org/index.php/topic,51493.msg276246.html#msg276246
(3) http://forum.pfsense.org/index.php/topic,51493.msg276317.html#msg276317
?What happens when you deactivate all rules? Which IPs are blocked (whitelisting works on my machine)?
UPDATE: with package vs. 2.5.1 this is obsolete
Update: Also http://forum.pfsense.org/index.php/topic,51493.msg276334.html#msg276334 matters.
-
Fesoj, I reviewed the hyperlinks you suggested and didn't see a fix for the FATAL ERROR (sdf issue). If anything, someone said there isn't a fix for the sdf issue. I will try to disable all rules and see whether snort will start on the interface. Thanks.
EDIT: deselecting all rules for the interface and attempting to manually start the snort on the interface fails. still returns same (sdf) error.
-
miles267,
first the files classification.config are incomplete. Secondly the sed commands in snort.inc are srambled. You need to take care of both issues.
… I am currently working on a patch to allow automatic updates (of the rules---not the package, because you'll need patched sources).
-
miles267,
here's the source patch for snort.inc: https://github.com/Fesoj/pfsense-packages/compare/patch-2
You need to edit 4 places by hand. Good luck.
Update: If someone feels uncomfortable with that, I could post my patched file…
UPDATE: with package vs. 2.5.1 this is obsolete
-
miles267,
here's the source patch for snort.inc: https://github.com/Fesoj/pfsense-packages/compare/patch-2
You need to edit 4 places by hand. Good luck.
Update: If someone feels uncomfortable with that, I could post my patched file…
Fesoj, thank you SO MUCH. Edited the snort.inc file with the (4) lines of code you suggested (delete/add lines) and the interface started without issue. Appreciate your help and attention to detail.
-
miles267, it aint't over yet. Make sure you patch the various classification.config files as well. The manual patches to classification.config won't survive any rule updates…