Snort 2.9.2.3 pkg v. 2.5.0 Issues

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.

kilthro

I just updated the snort package and now upon restart its giving me
Jul 22 12:38:41 snort[26253]: FATAL ERROR: /usr/local/etc/snort/snort_44959_re0/rules/snort_botnet-cnc.rules(372) Unknown rule option: 'ssl_state'.
Jul 22 12:38:41 snort[26253]: FATAL ERROR: /usr/local/etc/snort/snort_44959_re0/rules/snort_botnet-cnc.rules(372) Unknown rule option: 'ssl_state'.

I havent changed my rules/categories. The same as i have been running for some time.

Good news was when I updated I didnt get the errors in the system log like i did before upon completion of the install.

I noticed a new SSL option on the preprocesser Tab.

Enable that option and restarted no issues/errors so far.

I want to say thanks for all the work you all have been doing on this package to keep it updated/adding new features/ resolving bugs.

I cant imagine not having snort up and running. :-)

Fesoj

kilthro,

try to deactivate the rules that require the SSL preprocessor and see what happens. Then fiddle around with snort.conf for the associated interface(s). With some luck the snort user's manual contains sufficient info to do that.

Please report when things are running.

kilthro

@Fesoj:

kilthro,

try to deactivate the rules that require the SSL preprocessor and see what happens. Then fiddle around with snort.conf for the associated interface(s). With some luck the snort user's manual contains sufficient info to do that.

Please report when things are running.

Sorry if my post was misleading. I had the error and I did get it to run fine after enabling the ssl option. I was just posting stating that I had the error, I found the new option and enabled it and all is working just fine now..

Just getting some strange mem cap reached alerts in snort now for pop normalization… Need to look into that.. Other than that, all appears good. Need to try the auto update out later . ;)

Thanks for your hard work with this package.

Fesoj

kilthro,

so the "Enable SSL Data" option was not checked? And after enabling it, the snort config was ok?

kilthro

@Fesoj:

kilthro,

so the "Enable SSL Data" option was not checked? And after enabling it, the snort config was ok?

Correct. It wasnt enabled. Never seen the option there before. So I enabled it and it did fix the problem/error that I was having.

On a side note I am noticing

"(POP) No memory available for decoding. Memcap exceeded" - 07/22-13:01:54

in my alerts.. I dont see a memory setting in the snort package. Is this something now I have to adjust somewhere else? Never had it before until todays update.

bmeeks

@Fesoj:

bmeeks,

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

Update: Initially I picked the wrong patch.

I see now, I misunderstood the full flow of the code. I was thinking the entire contents of the rule archive (either Emerging Threats or Snort) were extracted first in a temp directory, and then copied over to the working directory in pieces. That appears to be not true for everything. Looks like by the time the snippet of code I posted earlier gets executed, it's too late because code further up above has already overwritten the files. Changing the order as you did is the best idea for now.

I did have one thought, though. Is it not possible that from time to time there may be legitimate differences in the config files from Emerging Threats and Snort such that simply using the Snort version might cause a different problem? What about a technique that compared the two files and made sure all unique lines from both files got merged into the final classification.config and the other configuration files?

Fesoj

kilthro,

I dont see a memory setting in the snort package.

as far as I remember, the some of the snort preprocessors have this option. See the default snort.conf from the package (not the ones in the interface directories). Maybe that helps.

Fesoj

bmeeks,

What about a technique that compared the two files…

the best thing is probably to build a union of all type declarations and in case of duplicate entries, maybe the one with the longer description could be chosen. Looks like a freshman homework problem. :)