Snort 2.9.2.3 pkg v. 2.5.0 Issues

mdima

PS: If you search the snort forums, you'll find several places where people have difficulties with IP ranges in whitelists, but I have not looked at the details whether this applies here, or whether these issues have been resolved, or whether the issues were due to a misunderstanding how snort works.

@Cino:

Whitelist has always been single IPs. It would be nice to use CDIR but it wasn't built that way. Ever since this change to the snort binary,

ok, we understood what the problem is. Before white lists were generated as "IP lists", now even the "default" whitelist is generated as a "network list" and it does not work anymore.

I am now looking at the Spoink code to see what we can do to restore this functionality… but for the moment I have to turn off the IP blocking or everything gets stuck in few minutes!

Ciao,
Michele

Fesoj

Michel,

after reading Cino's comment, that is in line with what I had in mind, your analysis is right. CIDR entries in the default file seem to be wrong and don't seem to work as expected. For my box the generated entries contain
(1) the loopback address
(2) the WAN address of the box (which is static in my case, so that's fine) [currently the subnet]
(3) the LAN address of the box [currently the subnet]
(4) and the DNS servers

I am wondering what happens if under point 2 the WAN address is dynamic. Would this mean that when blocking is enabled, you cannot generally avoid blocking yourself? Maybe there is an update mechanism.

mdima

@Fesoj:

Michel,
after reading Cino's comment, that is in line with what I had in mind, your analysis is right. CIDR entries in the default file seem to be wrong and don't seem to work as expected. For my box the generated entries contain
I am wondering what happens if under point 2 the WAN address is dynamic. Would this mean that when blocking is enabled, you cannot generally avoid blocking yourself? Maybe there is an update mechanism.

Thanks! But consider, I have about 80 VIPs, 5 NICs, it would be unconfortable to mantain a IP list aligned for the local IPs…
I mean, managing the HOME_NET with an Alias is awesome, just the whitelists should be managed as before, with an "host alias" for the part the user can decide (probably this should be noticed in the interface), and for the "default" part of the white list as single IP addresses without CIR.

Now that the problem is known and identified, I trust in Ermal to fix it... ;) Thanks!!

Michele

Cino

Imho I think the default home_net list should be exempt. If you need blocking, create a custom netlist.

Fesoj

Cino,

understood. As long as a custom list is possible.

Fesoj

If you see the following error message in your system log:

FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf

you can either add the type declaration by hand (see some of the earlier posts), or try the following patch:

https://github.com/bsdperimeter/pfsense-packages/pull/288

The reference classification.config file gets extracted from the rule set package (Snort.org and/or Emergingthreats.net), where the last download overwrites the first one. Currently the Snort.org rules are downloaded and unpacked before the ET rules, where the ET rules don't declare the sdf type. Hence the fatal error. The patch reverses the order of unpacking the archives since the Snort.org rules seem to have all the necessary declarations.

Happy patching.

UPDATE: with package vs. 2.5.1 this is obsolete

eri--

@Fesoj:

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.

That is why the option of add wan ips is there.
It will get the right address when theip changes. at least on 2.0+

Cino

It's been part of the GUI for years and is still there. For custom Netlist.

Fesoj

It will get the right address when theip changes. at least on 2.0+

I checked that and the IP of the WAN nic does not get blocked.

Fesoj

ermal,

That is why the option of add wan ips is there.

part of the discussion today was about whether the IP ranges actually work in the whitelist (alert_pf). Essentially, they don't work, but I might be wrong.

eri--

I pushed some fixes to snort to prevent issues with so rules.
Also changed a bit the upgrade process.

Please test again.

Fesoj,

I tested the whitelist features and they work with ranges.
Have you installed teh latest binary?

bmeeks

@Fesoj:

If you see the following error message in your system log:

FATAL ERROR: /usr/local/etc/snort/snort_56964_re1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf

The reference classification.config file gets extracted from the rule set package (Snort.org and/or Emergingthreats.net), where the last download overwrites the first one. Currently the Snort.org rules are downloaded and unpacked before the ET rules, where the ET rules don't declare the sdf type. Hence the fatal error.

In looking through the snort_check_for_rule_updates.php file, I see the following lines of code that are, I believe, supposed to prevent the classification.config overwrite when both snort and emgerging threats rules are used.

	if ($snortdownload == 'off') {
		foreach (array("classification.config", "reference.config", "sid-msg.map", "unicode.map") as $file) {
			if (file_exists("{$snortdir}/rules/{$file}"))
				@copy("{$snortdir}/rules/{$file}", "{$snortdir}/{$file}");
		}

This piece of code is in the Emerging Threats extraction and copy section, and it appears to be designed to prevent overwriting the classification.config and other files extracted earlier in the code when Snort rules are enabled. The value of the variable should be "on" when Snort rules are enabled, and thus the copying of the classification.config and other configuration files from the Emerging Threats rules package is bypassed. This would leave the "correct" versions of these files extracted from the Snort rules package.

Why is this section of code not working?

Fesoj

ermal,

I tested the whitelist features and they work with ranges.

give me a few days and I'll present an example, it just takes some time to document it. It is also possible that I am misunderstanding s.th. here. My setup is working, so I am fine. Also, I am using the latest binaries.

eri--

I removed subnets/cidr mask from auto generated addreses for whitelist and you can put them with the alias you configure if you want.

I bumped the package to 2.5.1

Fesoj

bmeeks,

Why is this section of code not working?

well, if you download both rule sets, then the ET part will enter the loop where some files from the rules directory of the unpacked archive are copied into the configuration directory, thereby overwriting the any previous version.

bmeeks

@Fesoj:

bmeeks,

Why is this section of code not working?

well, if you download both rule sets, then the ET part will enter the loop where some files from the rules directory of the unpacked archive are copied into the configuration directory, thereby overwriting the any previous version.

Well, it's sort of a moot point now since I see in the latest update Ermal changed the code a bit so Emerging Threats are done first.

The way I understood the old code, it unpacked each rule set into a temp directory and then copied files into the working directory. The snippet I posted should have been hit before the classification.config file from Emerging Threats was copied over into the working directory. If it saw that Snort downloads were "on", it should have skipped the @copy function where the Emerging Threats classification.config and other configuration files were copied from the temp area where they were extracted into the working directory along with the previously extracted and copied Snort files.

judex

2.5.1 throws the following error which was not there before without changing any configuration (did complete reinstall):

FATAL ERROR: /usr/local/etc/snort/snort_4672_em1/rules/snort_botnet-cnc.rules(366) Unknown rule option: 'ssl_state'.

[EDIT] Suprise: the preprocessor page is heavily modified and now we have to enable SSL data separately. It was unchecked and thats where the error came from. Doing further testing now.

Fesoj

bmeeks,

https://github.com/Fesoj/pfsense-packages/compare/patch-3 :)

Update: Initially I picked the wrong patch.

Fesoj

judex,

FATAL ERROR: /usr/local/etc/snort/snort_4672_em1/rules/snort_botnet-cnc.rules(366) Unknown rule option: 'ssl_state'.

there is a section in the snort user's manual about the dynamic SSL preprocessor. I've never found a reason to activate this one.

On the other hand, did you activate this for the latest version or did the error message appear out of nowhere?

judex

Thx for your answer and the investitgation you did during the last days Fesoj!

I edited my post because I found the new preproc settings and enabled SSL data there. Now snort starts without warning.

If I do not enable SSL-data an preproc page I get the errors from botnet-cnc and if disabled from exploit.rules…So I obviousely need it if I want to enable botnet rules etc.