Snort 2.9.6.2 pkg v3.1.4 - Preprocessors blocks my WAN IP
-
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