Snort 2.9.6.2 pkg v3.1.4 - Preprocessors blocks my WAN IP
-
Hi,
It seems that all alerts generated by preprocessors are blocking my WAN IP, too. (I think since the update to 3.1.4)
For example, this alert
11/10/14-18:14:27.572670 ,140,18,1,"(spp_sip) Content length mismatch",UDP,71.6.Y.Y,41480,84.159.X.X,5060,54321,Potentially Bad Traffic,2,f
blocks both IPs. (71.6.Y.Y and 84.159.X.X. 84.159.X.X -> my WAN IP)
also this alert blocks both source and destination:
11/10/14-20:44:39.784310 ,122,21,1,"(portscan) UDP Filtered Portscan",,5.146.Y.Y,,84.159.X.X,,4307,Attempted Information Leak,2,
It seems only be a problem, for preprocessors alerts.
Is it possible, that $HOME_NET is being ignored?
(My WAN IP is in the $HOME_NET, I can see it, if i click on "view list". )
Sometimes a portscan is detected with my WAN IP as source. But I think the preprocessor should ignore it, or not?
The option "_Ignore Scanne_r" should use the $HOME_NET (Leave blank for default. Default value is $HOME_NET.)Thank you, for any help or suggestions!!
-
Hi,
It seems that all alerts generated by preprocessors are blocking my WAN IP, too. (I think since the update to 3.1.4)
For example, this alert
11/10/14-18:14:27.572670 ,140,18,1,"(spp_sip) Content length mismatch",UDP,71.6.Y.Y,41480,84.159.X.X,5060,54321,Potentially Bad Traffic,2,f
blocks both IPs. (71.6.Y.Y and 84.159.X.X. 84.159.X.X -> my WAN IP)
also this alert blocks both source and destination:
11/10/14-20:44:39.784310 ,122,21,1,"(portscan) UDP Filtered Portscan",,5.146.Y.Y,,84.159.X.X,,4307,Attempted Information Leak,2,
It seems only be a problem, for preprocessors alerts.
Is it possible, that $HOME_NET is being ignored?
(My WAN IP is in the $HOME_NET, I can see it, if i click on "view list". )
Sometimes a portscan is detected with my WAN IP as source. But I think the preprocessor should ignore it, or not?
The option "_Ignore Scanne_r" should use the $HOME_NET (Leave blank for default. Default value is $HOME_NET.)Thank you, for any help or suggestions!!
$HOME_NET has nothing to do with IP addresses that are not blocked. That is from the PASS LIST. There is a default PASS LIST that should include your WAN IP, default gateway, DNS servers and all locally-attached networks. To see that list, do this:
Go to the INTERFACES tab and click to edit the interface in Snort. Scroll down and find the PASS LIST combo-box. It should be set to "default". Out to the right, click the VIEW LIST button.
Examine the contents of that list. You should see your WAN IP and the other items I listed as default entries showing up there. If not, then that is your problem.
Bill
-
I got something similar after a power failure, pfsense 2.1.5 Snort 2.9.6.2 pkg v3.1.4, the WAN IP was blocked ….
Nov 10 17:15:14 snort[54050]: [122:3:1] (portscan) TCP Portsweep [Classification: Attempted Information Leak] [Priority: 2] {PROTO:255} 50.21.134.xx-> 173.194.43.97 Nov 10 17:15:14 snort[54050]: [122:3:1] (portscan) TCP Portsweep [Classification: Attempted Information Leak] [Priority: 2] {PROTO:255} 50.21.134.xx-> 173.194.43.97 Nov 10 17:09:07 snort[54050]: [122:3:1] (portscan) TCP Portsweep [Classification: Attempted Information Leak] [Priority: 2] {PROTO:255} 50.21.134.xx-> 65.55.163.222 Nov 10 17:09:07 snort[54050]: [122:3:1] (portscan) TCP Portsweep [Classification: Attempted Information Leak] [Priority: 2] {PROTO:255} 50.21.134.xx-> 65.55.163.222 Nov 10 16:48:06 php: rc.newwanip: pfSense package system has detected an ip change 199.192.238.xx -> 50.21.134.xx... Restarting packages.I add this one to the suppress list
#(portscan) TCP Portsweep 17:18 lundi 10 novembre 2014 Block au reboot suppress gen_id 122, sig_id 3 -
$HOME_NET has nothing to do with IP addresses that are not blocked. That is from the PASS LIST. There is a default PASS LIST that should include your WAN IP, default gateway, DNS servers and all locally-attached networks. To see that list, do this:
Go to the INTERFACES tab and click to edit the interface in Snort. Scroll down and find the PASS LIST combo-box. It should be set to "default". Out to the right, click the VIEW LIST button.
Examine the contents of that list. You should see your WAN IP and the other items I listed as default entries showing up there. If not, then that is your problem.
Bill
Thank you, for the quick answer! :-)
Yes, my actual WAN IP is also in the PASS LIST! So, the WAN IP shouldn´t be blocked?
My WAN IP ist only blocked with alerts generated by a preprocessor, not with the "normal" ruleset.
And the "Ignore Scanner" option should use the HOME NET, if it´s blank. But did see alerts, with my WAN IP as source. (And because of this, WAN IP was also blocked).
-
$HOME_NET has nothing to do with IP addresses that are not blocked. That is from the PASS LIST. There is a default PASS LIST that should include your WAN IP, default gateway, DNS servers and all locally-attached networks. To see that list, do this:
Go to the INTERFACES tab and click to edit the interface in Snort. Scroll down and find the PASS LIST combo-box. It should be set to "default". Out to the right, click the VIEW LIST button.
Examine the contents of that list. You should see your WAN IP and the other items I listed as default entries showing up there. If not, then that is your problem.
Bill
Thank you, for the quick answer! :-)
Yes, my actual WAN IP is also in the PASS LIST! So, the WAN IP shouldn´t be blocked?
My WAN IP ist only blocked with alerts generated by a preprocessor, not with the "normal" ruleset.
And the "Ignore Scanner" option should use the HOME NET, if it´s blank. But did see alerts, with my WAN IP as source. (And because of this, WAN IP was also blocked).
Have you stopped and restarted Snort to see if that helps? The internal code that does the blocking only reads the PASS LIST during startup. If your WAN IP changed for some reason and Snort did not restart, then the new IP might get blocked because the "in use" PASS LIST would still contain the old IP.
Bill
-
Have you stopped and restarted Snort to see if that helps? The internal code that does the blocking only reads the PASS LIST during startup. If your WAN IP changed for some reason and Snort did not restart, then the new IP might get blocked because the "in use" PASS LIST would still contain the old IP.
Bill
My WAN IP changes every 24h.
But why the WAN IP get´s only blocked by alerts generated by preprocessors? As I mentioned before, It never gets blocked by the "normal" ruleset. (The Option "Which IP to Block" is set to "both")
If it´s the changing WAN IP, should the "normal" Ruleset not also block my WAN IP? But they never do. (And I get some alerts a day).
Or I am thinking wrong?
Thank you!
-
Have you stopped and restarted Snort to see if that helps? The internal code that does the blocking only reads the PASS LIST during startup. If your WAN IP changed for some reason and Snort did not restart, then the new IP might get blocked because the "in use" PASS LIST would still contain the old IP.
Bill
My WAN IP changes every 24h.
But why the WAN IP get´s only blocked by alerts generated by preprocessors? As I mentioned before, It never gets blocked by the "normal" ruleset. (The Option "Which IP to Block" is set to "both")
If it´s the changing WAN IP, should the "normal" Ruleset not also block my WAN IP? But they never do. (And I get some alerts a day).
Or I am thinking wrong?
Thank you!
As far as the blocking module is concerned, there is no difference between rule alerts and preprocessor alerts – they are the same.
Is your WAN IP always assigned from the same subnet? If so, you could create an Alias with that subnet and assign the alias to the "ignore scanners" setting for the portscan preprocessor. There is also nothing wrong with simply turning off the portscan preprocessor. It has become prone to false positives of late.
Bill
-
As far as the blocking module is concerned, there is no difference between rule alerts and preprocessor alerts – they are the same.
Is your WAN IP always assigned from the same subnet? If so, you could create an Alias with that subnet and assign the alias to the "ignore scanners" setting for the portscan preprocessor. There is also nothing wrong with simply turning off the portscan preprocessor. It has become prone to false positives of late.
Bill
No, I think from different subnets… I turned off the portscan preprocessor for now.
Just a workaround, but i hope the WAN IP won´t be blocked for a long time... ;-D
Thank you, for your support! :)
-
As far as the blocking module is concerned, there is no difference between rule alerts and preprocessor alerts – they are the same.
Is your WAN IP always assigned from the same subnet? If so, you could create an Alias with that subnet and assign the alias to the "ignore scanners" setting for the portscan preprocessor. There is also nothing wrong with simply turning off the portscan preprocessor. It has become prone to false positives of late.
Bill
No, I think from different subnets… I turned off the portscan preprocessor for now.
Just a workaround, but i hope the WAN IP won´t be blocked for a long time... ;-D
Thank you, for your support! :)
I bet the bug I fixed today for nanoBSD installs could also be a problem for you. That bug prevented the "save configuration" function from running when called automatically by pfSense during reboots or during IP address changes. That function not getting called would cause the PASS LIST to not get auto-update when your IP changed and Snort was restarted.
Update to the latest v3.1.5 version of the GUI package, turn the preprocessor back on, and see if things behave better. You can simply go to the INSTALLED PACKAGES tab and click the XML icon beside the Snort package. No need to reboot or uninstall/reinstall.
Bill
-
I tried the XML reinstall … but it fails
Removing snort components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. Beginning package installation for snort . Downloading package configuration file... done. Saving updated package information... done. Downloading snort and its dependencies... Checking for package installation... Loading package configuration... done. Configuring package components... Additional files... snort_edit_hat_data.php failed. Removing package... Starting package deletion for snort-2.9.6.2-i386...done. Removing snort components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. done. Failed to install package. Package reinstallation failed.I then reinstalled the package.
-
I bet the bug I fixed today for nanoBSD installs could also be a problem for you. That bug prevented the "save configuration" function from running when called automatically by pfSense during reboots or during IP address changes. That function not getting called would cause the PASS LIST to not get auto-update when your IP changed and Snort was restarted.
Update to the latest v3.1.5 version of the GUI package, turn the preprocessor back on, and see if things behave better. You can simply go to the INSTALLED PACKAGES tab and click the XML icon beside the Snort package. No need to reboot or uninstall/reinstall.
Bill
I will test it. Thx!
-
I tried the XML reinstall … but it fails
Removing snort components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. Beginning package installation for snort . Downloading package configuration file... done. Saving updated package information... done. Downloading snort and its dependencies... Checking for package installation... Loading package configuration... done. Configuring package components... Additional files... snort_edit_hat_data.php failed. Removing package... Starting package deletion for snort-2.9.6.2-i386...done. Removing snort components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Removing package instructions...done. Auxiliary files... done. Package XML... done. Configuration... done. done. Failed to install package. Package reinstallation failed.I then reinstalled the package.
That error indicates you lost connectivity to the pfSense Packages Repository server (like maybe it got blocked by Snort or there was a network issue). Just for grins, stop Snort and clear all blocks before attempting the update.
Bill
-
OK, until now no further blocking of my WAN IP.
I can see some preprocessor alerts (portscan), but no blocking of my WAN IP.
v3.1.5 seems to solve my problem! :)
Thx, again! :)
-
OK, until now no further blocking of my WAN IP.
I can see some preprocessor alerts (portscan), but no blocking of my WAN IP.
v3.1.5 seems to solve my problem! :)
Thx, again! :)
Thank you for the feedback. Glad it fixed your problem.
Bill
-
I had the same problem, so I wil do the XML-reinstall as you said, Bill, to see if it fixes anything.
(Disabling portscan preprocessors and rebooting did not solve anything).
What is weird in my case is: it only happens on WAN1 (VDSL), not on WAN2 (Cable);
And, of course, being the noob that I am, I have no clue why my WAN1-IP would be detected as doing a port scan on some remote IP at all.
And, something even more weirder:
Source: 122.225.97.66
Destination: 81.x.x.x. => my WAN
SID: 136:1 ((spp_reputation) packets blacklisted)And then my WAN gets blocked by Snort, and not the 122.225.97.66 ???
-
@Hollander:
I had the same problem, so I wil do the XML-reinstall as you said, Bill, to see if it fixes anything.
(Disabling portscan preprocessors and rebooting did not solve anything).
What is weird in my case is: it only happens on WAN1 (VDSL), not on WAN2 (Cable);
And, of course, being the noob that I am, I have no clue why my WAN1-IP would be detected as doing a port scan on some remote IP at all.
And, something even more weirder:
Source: 122.225.97.66
Destination: 81.x.x.x. => my WAN
SID: 136:1 ((spp_reputation) packets blacklisted)And then my WAN gets blocked by Snort, and not the 122.225.97.66 ???
The update to 3.1.5 should fix the WAN IP getting blocked. The bug fixed in that update causes Snort to ignore the new WAN IP change, so that means your new WAN IP does not get put into the default automatic PASS LIST. As for portscan sensitivity, I have a noticed a few more than I used to get many months ago. The GUI package code I maintain has nothing to do with that, however. That is something triggered by the Snort binary that comes from the snort.org folks.
Bill
