Snort still blocking a Network that is listed in Whitelist
-
Good day all. I am attempting to re-setup Snort (2.9.5.5 pkg v3.0.3) on my pfSense box (2.1-RELEASE (i386)) and I have been running into a lot of issues with it detecting things that I believe it should not be. I am getting the below alert which is causing a Google IP to be blocked. I believe this is from the Google Music app or Chrome, but I have not tracked it down to that yet. The IP is in the range of Google issues IP addresses according to a whois lookup (74.125.0.0/16). So, I created a whitelist and checked all the options for it and linked it to an Alias list I made so I could add in some IPs that I never want to block. I set the aliases up under the IP tab and added in the above network (74.125.0.0/16) so that it would not be blocked. I keep checking on it and these alerts still keep popping up and block the IPs in that range. Would someone please let me know if I am missing something on this? Thank you!
(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE - 01/31/14-12:00:10
ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-11:57:53 -
Previous thread about HTTP Inspect: https://forum.pfsense.org/index.php/topic,72064.0.html
Are you sure that your whitelist is actually being used and not the default one? You need to select it in the settings for your Snort interface.
-
I do have the whitelist selected in the settings. If I press the "View List" link to view it, I do see all the networks I should be allowing. I followed the suggestion in the post provided by @fragged and I will monitor that to see if it makes a difference.
-
I restarted Snort and got the same errors as before, plus an additional few.
1 74.125.225.116 Resolve host via reverse DNS lookup (http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE - 01/31/14-04:00:09
ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-13:01:01 Delete host from Blocked Table
2 74.125.225.115 Resolve host via reverse DNS lookup (http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE - 01/31/14-12:00:10
ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-12:58:06 Delete host from Blocked Table
3 74.125.225.113 Resolve host via reverse DNS lookup ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-13:00:06 Delete host from Blocked Table
4 74.125.225.112 Resolve host via reverse DNS lookup ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-12:58:48 Delete host from Blocked Table
5 74.125.225.114 Resolve host via reverse DNS lookup ET TROJAN Zeus Bot GET to Google checking Internet connectivity - 01/31/14-12:59:30 Delete host from Blocked Table -
I created a whitelist and checked all the options for it and linked it to an Alias list I made so I could add in some IPs that I never want to block. I set the aliases up under the IP tab and added in the above network (74.125.0.0/16)
In Snort:Whitelists, did you add an alias in the "Add custom IP Addresses from configured Aliases" section?
In Firewall:Aliases, when you edit the Alias you created for the Whitelist, did you select the "Type" as "Network"?
When you enter the Address, you would enter 74.125.0.0 in the network section, and the CIDR as 16
If it was me, I wouldnt add a Netblock like that to the Whitelist, I would either -
- Disable the Rule that triggered the alert or 2) add a Suppression with the Single IP address that caused the alert.
Snort needs to be tuned which could take months of your time if you want to fine tune it properly for your network.
-
@BBcan17:
I created a whitelist and checked all the options for it and linked it to an Alias list I made so I could add in some IPs that I never want to block. I set the aliases up under the IP tab and added in the above network (74.125.0.0/16)
In Snort:Whitelists, did you add an alias in the "Add custom IP Addresses from configured Aliases" section?
In Firewall:Aliases, when you edit the Alias you created for the Whitelist, did you select the "Type" as "Network"?
When you enter the Address, you would enter 74.125.0.0 in the network section, and the CIDR as 16
If it was me, I wouldnt add a Netblock like that to the Whitelist, I would either -
- Disable the Rule that triggered the alert or 2) add a Suppression with the Single IP address that caused the alert.
Snort needs to be tuned which could take months of your time if you want to fine tune it properly for your network.
Fragged is correct. Snort needs tuning for your environment. It is not just a "install the package and sit back and forget about it" sort of software package. It requires analysis and tuning.
One thing coming in the next version on pfSense is the ability from the ALERTS tab to force disable a rule (both regular and preprocessor/decoder rules). You can also simply add a Suppress List entry as well from the ALERTS tab.
Bill
-
@BBcan17:
Snort needs to be tuned which could take months of your time if you want to fine tune it properly for your network.
Fragged is correct. Snort needs tuning for your environment. It is not just a "install the package and sit back and forget about it" sort of software package. It requires analysis and tuning.
One thing coming in the next version on pfSense is the ability from the ALERTS tab to force disable a rule (both regular and preprocessor/decoder rules). You can also simply add a Suppress List entry as well from the ALERTS tab.
Bill
You cut me deep shrek! Fragged is a good guy anyways… lol
-
@BBcan17:
@BBcan17:
Snort needs to be tuned which could take months of your time if you want to fine tune it properly for your network.
Fragged is correct. Snort needs tuning for your environment. It is not just a "install the package and sit back and forget about it" sort of software package. It requires analysis and tuning.
One thing coming in the next version on pfSense is the ability from the ALERTS tab to force disable a rule (both regular and preprocessor/decoder rules). You can also simply add a Suppress List entry as well from the ALERTS tab.
Bill
You cut me deep shrek! Fragged is a good guy anyways… lol
:-[ … sorry, got my posters confused. I should have acknowledged BBcan17 as the source on that one.
Bill
-
I updated to Snort 2.9.5.5 pkg v3.0.3 and now ip-s in my whitelist are suddenly blocked.
-
I updated to Snort 2.9.5.5 pkg v3.0.3 and now ip-s in my whitelist are suddenly blocked.
Is the correct whitelist assigned/associated with the interface on the Interface tab? Scroll down to the bottom of the page and be sure the correct whitelist is selected in the drop-down. After setting and saving the whitelist, you will need to restart Snort for the change to take effect.
Bill
-
I updated to Snort 2.9.5.5 pkg v3.0.3 and now ip-s in my whitelist are suddenly blocked.
Is the correct whitelist assigned/associated with the interface on the Interface tab? Scroll down to the bottom of the page and be sure the correct whitelist is selected in the drop-down. After setting and saving the whitelist, you will need to restart Snort for the change to take effect.
Bill
:o stupid me… I changed the name in "Whitelists" and of course you need to reset them in all the interfaces.
Maybe you could add a warning that the whitelist is used in an interface and should be re-enabled? -
:o stupid me… I changed the name in "Whitelists" and of course you need to reset them in all the interfaces.
Maybe you could add a warning that the whitelist is used in an interface and should be re-enabled?I can do that. I already flag an error message when trying to delete a "currently assigned to an interface" whitelist. I can do the same with rename, or else just silently go ahead and change the name for all interfaces it is assigned to (and maybe just pop up an info box to let the user know). I think I like the "just rename it on assigned interfaces" option best.
I'll put this on my TODO list. To late, though, for the 3.0.4 version that is in review right now.
Bill
-
:o stupid me… I changed the name in "Whitelists" and of course you need to reset them in all the interfaces.
Maybe you could add a warning that the whitelist is used in an interface and should be re-enabled?I can do that. I already flag an error message when trying to delete a "currently assigned to an interface" whitelist. I can do the same with rename, or else just silently go ahead and change the name for all interfaces it is assigned to (and maybe just pop up an info box to let the user know). I think I like the "just rename it on assigned interfaces" option best.
I'll put this on my TODO list. To late, though, for the 3.0.4 version that is in review right now.
Bill
No problem, it's just to prevent stupid questions like this in the future, although I know that even if you warn people, they still don't -read- it…