Snort stupid question: whitelists and Suppress lists.
-
Bill,
with your last post you opened my eyes!
Now I'm starting to understand this thing much better.
Many, many, many thanks for doing such a great job and for your kindness.
Snort is now working on my system in conjunction with pfblocker
(pfblocker is doing some raw filtering using Bluetack PIP Filter (.gz), ET blockrules compromised IPs and ET Block-IPs (.txt))I enriched Snort LAN rules with your suggestions (balanced policy in use) while leaving the WAN instance set to Connectivity IPS policy.
I'm using a suppress list by @asterix found here:
https://forum.pfsense.org/index.php?topic=56267.15
Speaking of the "SNORT GPLv2 COMMUNITY RULES": you suggested not to tick the checkbox "Install Snort Community rules".
Unfortunately this was ticked before I purchased the VRT subscription and now the tab Updates shows that GPLv2 COMMUNITY RULES are installed (and I don't know how to uninstall them). Un-ticking the checkbox in Global Settings doesn't get rid ot them. Hope this is not a problem.
Now testing, testing, testing…
-
Bill,
with your last post you opened my eyes!
Now I'm starting to understand this thing much better.
Many, many, many thanks for doing such a great job and for your kindness.
Snort is now working on my system in conjunction with pfblocker
(pfblocker is doing some raw filtering using Bluetack PIP Filter (.gz), ET blockrules compromised IPs and ET Block-IPs (.txt))I enriched Snort LAN rules with your suggestions (balanced policy in use) while leaving the WAN instance set to Connectivity IPS policy.
I'm using a suppress list by @asterix found here:
https://forum.pfsense.org/index.php?topic=56267.15
Speaking of the "SNORT GPLv2 COMMUNITY RULES": you suggested not to tick the checkbox "Install Snort Community rules".
Unfortunately this was ticked before I purchased the VRT subscription and now the tab Updates shows that GPLv2 COMMUNITY RULES are installed (and I don't know how to uninstall them). Un-ticking the checkbox in Global Settings doesn't get rid ot them. Hope this is not a problem.
Now testing, testing, testing…
Uncheck the GPLv2 Community Rules in two places. Unchecking them on the Global Settings tab means they will no longer be included in automatic updates. Unchecking them on the Categories tab for an interface, and then saving the configuration, means they will no longer be included in the enforcing rules for that Snort instance. I can add some code into the current update I'm working on to automatically remove them from the other places when the Global Settings box is unchecked. So long as they are unchecked on the Categories tab (and when unchecked and saved, they will be hidden on that tab anyway), they are not actually in the enforcing rules set Snort is using to inspect traffic. Oh, and no real harm if they are included. It would just mean some duplication in your rules. If you have plenty of CPU and RAM (and most setups these days do have plenty of extra CPU and RAM), then this duplication is no big deal.
Bill
-
I can't find where to uncheck the GPLv2 Community Rules in the Categories tab, probably because I did it in the past without the "awareness" I have today ;)
This is a screenshot
(and know I'm going to study what does this sentence mean "Note: Auto-enabled rules generating unwanted alerts should have their GID:SID added to the Suppression List for the interface.)
-
I can't find where to uncheck the GPLv2 Community Rules in the Categories tab, probably because I did it in the past without the "awareness" I have today ;)
Snort:Global Settings - Install Snort Community Rules
-
@BBcan17:
I can't find where to uncheck the GPLv2 Community Rules in the Categories tab, probably because I did it in the past without the "awareness" I have today ;)
Snort:Global Settings - Install Snort Community Rules
No, no I was trying to get rid of them because they're included in the paid VRT subscription. Now the only place I can see them is in the Updates tab. For me is resolved.
-
@BBcan17:
I can't find where to uncheck the GPLv2 Community Rules in the Categories tab, probably because I did it in the past without the "awareness" I have today ;)
Snort:Global Settings - Install Snort Community Rules
No, no I was trying to get rid of them because they're included in the paid VRT subscription. Now the only place I can see them is in the Updates tab. For me is resolved.
Yes, that is a GUI display bug I need to fix. It does not mean they are being included in your rules. Just means the old MD5 file is still there for the code to see and display.
Bill
-
Bill,
I'd like to better understand the concept of Add auto-generated IP Addresses in the Whitelists.
I setup two default whitelists: one for the LAN and the other for the WAN.
As you can see I haven't setup any Aliases because – after the setup of the Suppress list by @asterix – I'm not getting any false positives.
-
First question: Have I to setup the same suppress list on the WAN and the LAN?
-
Second question: are these whitelists ok? (see attached screenshots)
I'm asking this because, in the LAN whitelist, I unchecked the entry «Add WAN interface IPs to the list» to get the Alerts to work (blindly following and advice found in the fora).
-
-
Bill,
I'd like to better understand the concept of Add auto-generated IP Addresses in the Whitelists.
I setup two default whitelists: one for the LAN and the other for the WAN.
As you can see I haven't setup any Aliases because – after the setup of the Suppress list by @asterix – I'm not getting any false positives.
-
First question: Have I to setup the same suppress list on the WAN and the LAN?
-
Second question: are these whitelists ok? (see attached screenshots)
I'm asking this because, in the LAN whitelist, I unchecked the entry «Add WAN interface IPs to the list» to get the Alerts to work (blindly following and advice found in the fora).
First up, go back and check that box for the WAN interface IP. You never want to "block it", so you always want it in the whitelist. Unchecking that box is a good way to get your network tied up in knots, and even more so if you have to remotely administer the firewall and don't have a backdoor network. If your WAN IP is blocked by Snort, then no traffic comes or goes. That's generally not a good thing.
The default whitelist is composed of the entries shown with checkboxes on that page. It includes the WAN interface IP, the next-hop gateway on the WAN, and all locally attached networks. It also includes your DNS servers (the ones either you manually configured when setting up pfSense, or the ones supplied by the DHCP server on the WAN if you have that kind of configuration). As you surmised, you have the option of adding more addresses to the whitelist by creating an Alias and populating it with the addresses. Then on the whitelist tab you can add it to the Addresses: alias box at the bottom of the page. It is perfectly fine to leave that blank, though, if you have no other IPs to whitelist. Your typical home network would not have need of any more, for example.
Here is what I recommend in terms of blocking setups for the LAN. First, leave all the default checkboxes checked on the Whitelist. Actually, in most situations, you don't need to create a whitelist at all. The automatic default one will be fine. You get the automatic default one when the whitelist drop-down on the Interface Settings tab is set to "default". Next, on the same Interface Settings tab in the blocking section, configure it to block BOTH and check the Kill States checkbox. By choosing block BOTH (that means SRC and DST addresses) for a bad packet, you are sure to block communication between an infected LAN host and whomever it is trying to talk to on the Internet. So whether your LAN host is the SRC or DST of the traffic, a block will be inserted. Here is why BOTH is the best choice. Remember the default whitelist will not block LAN host IP addresses, so that would mean if you choose only SRC or only DST, and one of those is your LAN host, that bad traffic would not get blocked. However, by telling Snort to block BOTH ends of the conversation (the SRC and DST simultaneously, you are guaranteed to block the bad traffic even when one of them (either SRC or DST) is on the whitelist. What literally happens in this scenario is as follows. Assume the blocking plugin within Snort sees bad traffic from a LAN host to a BOT CC server. In this example, your LAN host is the SRC while the BOT CC server is the DST. The blocking plugin sees the LAN host IP range is on the whitelist, so it won't insert a block for SRC address. If all you had selected was to block SRC, then you see how the LAN host could still phone home to the evil IP. However, since you chose BOTH as the blocking instructions, the Snort blocking plugin will also insert a block for the DST IP (the BOT CC server). So your LAN host's traffic can't get to the BOT CC server. If the roles were reversed so that the LAN host was the DST instead, the traffic would still get blocked if you have BOTH chosen. This is why BOTH is the new default choice for this parameter. It was formerly just SRC.
Bill
-
-
A fine read indeed! Thanks for taking the time :)
-
Disabling Snort on the LAN interface stops that firewall IPv6 log entries. This is quite strange!
Oh…I remember why now. Snort puts interfaces it runs on in promiscuous mode, so the interface sees all traffic. You can choose not to log that since it's all link local stuff anyway.
Bill
Actually you can only stop logging that ipv6 link local traffic if you enable ipv6 on pfsense 2.1 which seems backwards. You would then need to create a rule to block all ipv6 on the floating tab and not log it.
With 2.0.3, ipv6 disabled in advanced settings, and default drop logging enabled (the default setting), all ipv6 is dropped without logging. There was a change though in 2.1 where now if default block logging is enabled (the default setting) ipv6 will be logged and you can not change that with ipv6 disabled. I can understand why the change was made because it seems logical to do with ipv6 the same as you do with ipv4 with the default block logging enabled. With ipv6 disabled in advanced settings though it just doesn't make sense to log ipv6 IMHO even with default drop logging enabled.
With pfsense 2.0.3:
if(!isset($config['system']['ipv6allow'])) {
$ipfrules .= "# Block all IPv6\n";
$ipfrules .= "block in quick inet6 all\n";
$ipfrules .= "block out quick inet6 all\n";
}With pfsense 2.1:
if(!isset($config['system']['ipv6allow'])) {
$ipfrules .= "# Block all IPv6\n";
$ipfrules .= "block in {$log} quick inet6 all label "Block all IPv6"\n";
$ipfrules .= "block out {$log} quick inet6 all label "Block all IPv6"\n";These are implicit rules with 'quick' that come before any user rules so you can not override them and set them to not log.
I would love to see ipv6 not logged if ipv6 is disabled. The packets are blocked and since you have disabled ipv6 why would you care about them?.
-
A fine read indeed! Thanks for taking the time :)
I really need to make time to update the HELP pages on the pfSense Wiki for Snort. I will commit to doing that immediately after I post the upcoming Snort 2.9.6.0 update. Having all of the complexity of the Snort package adequately documented is way overdue.
Bill
-
A fine read indeed! Thanks for taking the time :)
I really need to make time to update the HELP pages on the pfSense Wiki for Snort. I will commit to doing that immediately after I post the upcoming Snort 2.9.6.0 update. Having all of the complexity of the Snort package adequately documented is way overdue.
Bill
We are grateful for your GREAT work and for these useful explanations!
-
Here is what I recommend in terms of blocking setups for the LAN. First, leave all the default checkboxes checked on the Whitelist.
Bill,
I re-read this thread:
https://forum.pfsense.org/index.php?topic=67805.0
and now I'm trying to understand this topic a bit more in depth: for me made sense to uncheck the WAN Interface IPs in the LAN Whitelist…
-
Here is what I recommend in terms of blocking setups for the LAN. First, leave all the default checkboxes checked on the Whitelist.
Bill,
I re-read this thread:
https://forum.pfsense.org/index.php?topic=67805.0
and now I'm trying to understand this topic a bit more in depth: for me made sense to uncheck the WAN Interface IPs in the LAN Whitelist…
Panz:
The best answer I can give you is "never change any of the default settings" in whitelists on the WHITELISTS tab. They are there for very good reasons. If you want to experiment, that's fine, but just be prepared to lock yourself completely out of the firewall to the point that only a local console and keyboard can get you in.
Bill
-
OK! :)
