Snort SID 120:3 with antivirus updates
-
I checked the fibre modem (a "Fiber2Home" modem connected to the appliance via RJ45, saying it can handle 802.1P/Q and extended frames with up to 1536 bytes), indicating no collisions and full-duplex…
At the appliance for WAN MTU was blank and "Speed and duplex" set to default (should be auto). The provider recommends "auto" and gives no recommendation for MTU. With these settings I get 100baseTX/full-duplex from the provider (nominell it's a 100Mbit plug....)
Tried with 1000T/full-duplex (with and w/o m master and/or flowcontrol) and got no access from the provider, tried 100TX/full-duplex (with and w/o m flowcontrol), made no difference, same problem from time to time with snort as described above. The status for the interface looks not that bad, or?
All clients access the same external servers.
Sorry for abusing the packages area with an apparent WAN-interface problem blush, but I'm not so deep into TCP that I could solve this now easily…
Any help welcome!
-
@chemlud:
I checked the fibre modem (a "Fiber2Home" modem connected to the appliance via RJ45, saying it can handle 802.1P/Q and extended frames with up to 1536 bytes), indicating no collisions and full-duplex…
At the appliance for WAN MTU was blank and "Speed and duplex" set to default (should be auto). The provider recommends "auto" and gives no recommendation for MTU. With these settings I get 100baseTX/full-duplex from the provider (nominell it's a 100Mbit plug....)
Tried with 1000T/full-duplex (with and w/o m master and/or flowcontrol) and got no access from the provider, tried 100TX/full-duplex (with and w/o m flowcontrol), made no difference, same problem from time to time with snort as described above. The status for the interface looks not that bad, or?
All clients access the same external servers.
Sorry for abusing the packages area with an apparent WAN-interface problem blush, but I'm not so deep into TCP that I could solve this now easily…
Any help welcome!
I don't see any errors being shown, so looks like the link is OK. That was a long-shot anyway. You can either continue to hunt for some difference in configuration between the "working" and the "non-working" appliances, or you can just whitelist the particular external IPs so that are never blocked. To do this, create a host or network Alias under Firewall…Aliases and add the IP addresses of the external servers. You must use the literal IP and NOT a FQDN (fully-qualified domain name). Snort can't work with FQDNs. Once the Alias is created, then go to the Whitelists tab in Snort and create a whitelist if you don't have one already. Scroll down to the bottom and type in the name of the Alias (or click the Aliases button) to open the Alias window and select one. Save the change.
Now go to the Snort Interface tab for the interface and scroll down to the bottom where the Whitelist drop-down is located. Select the whitelist you either created or edited earlier. Save the changes and restart Snort on the interface. That should do it.
Bill
-
The servers for the antivirus updates vary over time, from the alerts/block list in snort, so it will be never ending to update the server list, as long as I allow complete internet, or?
What keeps me worrying is that the block occurs only with updates for virus scanner and anti-malware software. Strange to me…
Thanx for your suggestions!
chemlud
PS: The HTTP inspect is under "snort interfaces ", "WAN preprocessors" and there is nothing to configure that could affect the results of this filter, or? So there should be no differences between the three appliances setup, correct?
-
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?
-
@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
-
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!
-
@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
-
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
-
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.
-
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… ;)
-
- 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")
-
@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
-
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…)
-
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