Snort SID 120:3 with antivirus updates

bmeeks

@chemlud:

Oooops, found something:

The two appliances working are

Snort 2.9.4.6 pkg v. 2.6.1

and the one with the blockings is

Snort 2.9.5.5 pkg v. 3.0.0.

I forgot: I had to delete and re-install Snort on this appliance due to a malfunction 1-2 days after the initial setup and apparently got the newer version…

So this might be the explanation, but what has changed between these 2 versions that changes the behaviour of the HTTP inspect?

What is the recommended procedure for update (in the meantime pkg v3.0.1 is available)? Complete removal and subsequent new installation or simple re-installation?

From some quick perusing of the Snort Mailing List, I saw some other similar errors with HTTP_INSPECT in version 2.9.5.5. Looks like the new Snort binary may not be always correctly handling stream5 reassembly in some situations. That in turn could trip up the HTTP_INSPECT preprocessor.

For now I recommend adding a Suppress List entry for that alert using the process I described in an earlier post.

Bill

Guest

Updating to Snort 2.9.5.5 pkg v3.0.1 did not solve the problem. I set 120:3 on the suppress list for the while to stop these problems. Hope the problem is resolved soon…

Thanks so far!

bmeeks

@chemlud:

Updating to Snort 2.9.5.5 pkg v3.0.1 did not solve the problem. I set 120:3 on the suppress list for the while to stop these problems. Hope the problem is resolved soon…

Thanks so far!

Updating to 3.0.1 only affects the GUI code, not the Snort binary itself. That is the "2.9.5.5" number in the package name. Until that changes, any binary-related issues will remain. And since pfSense essentially just takes the Snort binary "as-is" from Snort VRT, any issues they have we will have on pfSense. I am finding some posts via Google with false positives with HTTP_INSPECT. Unfortunately that sort of has been the nature of that beast for a long time. Seems nobody can fully agree on exactly what the "standards" for web traffic really are… ;)

Bill

Guest

Seems nobody can fully agree on exactly what the "standards" for web traffic really are… ;)

…as long as my provider (or the NSA) do not corrupt my antivirus- and antimalware software updates ;)

I might be paranoid, but... :-X

A Former User

We'll get right on it. The standards need "fixing" anyways ;D

That rule is on my suppression list, so it is a false positive anyway. Feel free to suppress it until the reason for it being false positive is identified.

Guest

Merry christmas! ;D

I must confess, I'm a little more confused today as before. I added this suppress rule on Monday:

, but today I found this on the block list:

???

Makes no sense to me, huh?

Snort was stopped/restarted in the meantime several times (for updates of rule sets), so that should not be the problem.

Any suggestions? :o

PS: I totally forgot: There is no event in the "Alerts" list for this block… ;)

A Former User

You did not select the appropriate suppress list in snort's options
The host generated a different alert and was blocked for that reason (snort keeps track of previous "violations")

bmeeks

@chemlud:

Merry christmas! ;D

I must confess, I'm a little more confused today as before. I added this suppress rule on Monday:

, but today I found this on the block list:

???

Makes no sense to me, huh?

Snort was stopped/restarted in the meantime several times (for updates of rule sets), so that should not be the problem.

Any suggestions? :o

PS: I totally forgot: There is no event in the "Alerts" list for this block… ;)

One thing that is curious is the name of the Suppress List. If it was automatically generated, then the name should be "wansuppress_xxxx" where the "xxxx" is a random number. Is yours actually blank like shown (that is, no trailing random number)? Can you post a screenshot of the Suppress tab so I can which lists are shown?

You need to check the WAN interface in Snort and be sure this particular Suppress List name is chosen in the drop-down on the WAN Interface tab.

Finally, jflsakfia is correct that Snort pulls all previous history for an IP when showing it in the Block List.

Bill

Guest

Sorry, I removed the random number from the suppress list, just for the case. But the correct list is chosen in the "WAN settings" menu and the number of alerts/blocks has dramatically decreased since then. But this single block without an alert troubled me…

Yes, this IP was blocked various times in the past (one of the antivirus update servers contacted frequently by the Windows machines), so the "historic knowledge" of snort is the most likely explanation. Thank you for the extra lesson on snort.

Btw: Many, many thanks for any support provided so far. For years I had this Cisco stuff and NEVER got support of that qualitiy via the support forum. That (besides collapsing tunnels, unusable logs, intransparent firmware policies etc pp) was the reason for the decision to switch to pfSense. (Only thing that really frustrated me was that I learned shortly after that Cisco has bought Snort. I'm still a little shocked about that, in the post-Snowden era, but that is only my persional opinion…)

A Former User

Snort keeps a previous log of alerts generated by a host, but doesn't actually act based on them. Let's take an example:
host 1.1.1.1 was banned because of rule "I don't like this host because."
That was considered a false positive and added to the suppression list (or rule disabled is actually the proper procedure). Snort restarted, host removed from blocked tab.

A couple days later, the same host, host 1.1.1.1 gets banned because of rule "I don't like all same numbers in IP."

Now the blocked tab will say:

1.1.1.1 "I don't like this host because." and a date/time stamp.
"I don't like all same numbers in IP." and a date/time stamp.

The host appears to be blocked because of 2 reasons, but snort's most recent ban is based on the most recent alert generated ("I don't like all same numbers in IP."). The older data (I don't like this host because.") is just there to remind us that a host is really really bad.

If a host gets banned again after adding some rule to the suppression list/disabling the rule, then snort's interface was not restarted. Or something else triggered on that host. If neither of those happens, then it's not the expected behaviour.

Cisco? Is that a microwave oven maker? Can't remember…...oh, THAT cisco. Yeap, snort is pretty much doomed. After they add the remote update feature. Which is needed for the remote backdoor. For remote support of course.
Disclaimer: cisco mentioned in the paragraph above is entirely fictional. Any similarities to an actual company are purely coincidental. cough