Snort stupid question: whitelists and Suppress lists.
-
Maybe a silly question, but reading the Snort documentation I can't find a reassuring answer: if I put some IPs in a Snort whitelist or in the Suppress list, do they bypass only Snort control or do they bypass pfSense rules too? ???
-
Maybe a silly question, but reading the Snort documentation I can't find a reassuring answer: if I put some IPs in a Snort whitelist or in the Suppress list, do they bypass only Snort control or do they bypass pfSense rules too? ???
The "whitelists" you manage on the Whitelists tab in the Snort package are not the same as the whitelists discussed in the Snort documentation at Snort.org. They are sort of similar, but not the same. Let me briefly explain.
Snort on pfSense can block the IP addresses of offenders. However, there are some addresses in a typical firewall setup that you would not want to block (say the firewall network interfaces themselves; or your WAN external IP and next-hop gateway). To prevent this, the Snort package creates a default whitelist of addresses that it will never block even if they produce an alert. The user can also create custom whitelists on the Whitelists tab. The key with this whitelist, though, is that it is at the end of the decoding/detection chain and is the last thing checked just before a block is inserted.
Now let's talk about the whitelists and blacklists mentioned in the online Snort documentation. These are actually part of the IP Reputation preprocessor added not too long ago to the Snort binary. The IP Reputation preprocessor is the first thing an incoming packet hits, and the IP addresses in the packet (source and destination) are compared to lists of IPs in some whitelist and blacklist files. If an IP is on a blacklist, it is immediately alerted on and no further processing is done on that packet. If the IP is on a whitelist, then two options can be chosen. Either the packet can be implicitly trusted, or it can be un-blacked. Implicitly trusted means the packet is allowed through with no alerts and no further inspection. Un-blacked means the packet is not immediately alerted on, and is instead passed through the decoding and detection engines for analysis. In the current Snort package, the IP Reputation preprocessor is not present.
In the next Snort package update I'm working on, the IP Reputation preprocessor will be available. You will be able to create true whitelists and blacklists that operate as described in the online documentation at Snort.org. However, the existing Whitelists tab will also still be there because it has a unique and slightly different function in the pfSense Snort package due to the way blocking is implemented. There will be a new tab called IP Rep for each interface, and a top-level tab called IP Lists for managing the collection of blacklist and whitelist files.
Bill
-
Thank you @bmeeks for you detailed explanation!
Let me write down some examples, just to be sure that I'm understanding well.
In my Whitelist (that's basically an Alias with a bunch of IPs listed) I put this IP address:
178.236.4.23
Let's assume this IP is owned by a Bad Guy; question: is this whitelisted IP allowed to enter my firewall (e.g. from WAN), bypassing pfSense standard rules? (the rules in charge of inspecting it if Snort were not installed)?
2nd question: I have this entry in the Suppress list:
#(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
suppress gen_id 120, sig_id 3, track by_src, ip 151.1.67.227Is IP 151.1.67.227 allowed to bypass pfSense standard rules too?
I'm asking this because misconfiguration of such a powerful tool could cause more troubles than those I'm trying to solve :)
Thank you again.
-
Thank you @bmeeks for you detailed explanation!
Let me write down some examples, just to be sure that I'm understanding well.
In my Whitelist (that's basically an Alias with a bunch of IPs listed) I put this IP address:
178.236.4.23
Let's assume this IP is owned by a Bad Guy; question: is this whitelisted IP allowed to enter my firewall (e.g. from WAN), bypassing pfSense standard rules? (the rules in charge of inspecting it if Snort were not installed)?
If you have IP 178.236.4.23 as part of a whitelist defined on the WHITELISTS tab in Snort, then traffic to and from that IP will be inspected by Snort, but it would never be blocked by Snort (assuming you have "block offenders" enabled on the INTERFACE SETTINGS tab for the interface). Snort will generate alerts on that IP address if it sees bad things, but it will not block the traffic because the IP is on the Whitelist. The WHITELISTS tab really means "IP addresses that Snort won't block, but will inspect and alert on". Contrast this with the whitelists feature of the upcoming IP Reputation preprocessor I discussed earlier. With IP REP, whitelisting means Snort will never inspect the packet if set to implicitly trust the whitelist. The packet will still traverse your pfSense firewall rules, though. So if something in the regular rules blocks it, it still is blocked.
2nd question: I have this entry in the Suppress list:
#(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
suppress gen_id 120, sig_id 3, track by_src, ip 151.1.67.227Is IP 151.1.67.227 allowed to bypass pfSense standard rules too?
I'm asking this because misconfiguration of such a powerful tool could cause more troubles than those I'm trying to solve :)
Thank you again.
When an IP address is part of a Suppression List, then Snort will no longer generate alerts for that IP even if it does bad things. The alert and any subsequent blocking action are "suppressed" as far as Snort is concerned. Read on to the next section for what is probably the real and short answer to your questions.
The Bottom Line
Now none of this Snort activity has much at all to do with your regular pfSense firewall rules. All packets still go through your firewall. The only thing Snort can do is manually insert a block for specific IP addresses when it identifies bad traffic. Stated another way, if you put one of the IP addresses from your two example into a pfSense firewall rule with BLOCK as the action, then traffic from the IP would always be blocked no matter what Snort does. Snort does not replace your firewall, it only boosts the capability by allowing selective blocks based on signatures instead of purely by static IP only.Bill
-
Thank you, very clear and precise!
After Snort installation I'm seeing a lot of firewall logs including IPv6 addresses; is this normal?
-
Thank you, very clear and precise!
After Snort installation I'm seeing a lot of firewall logs including IPv6 addresses; is this normal?
Snort has nothing to do with what shows up in the firewall logs. That is purely up to pfSense. Snort actually inserts any IP address it wishes to block into an Alias table in the pfSense firewall, but there is no logging on the firewall side of IP addresses in that table. Instead, Snort shows IPs it blocked on its own BLOCKED tab.
As for being normal, the new 2.1 and up versions of pfSense seem to be quite "chatty" with IPv6 link local traffic (at least in my VMware test environment I've noticed that.
Bill
-
Disabling Snort on the LAN interface stops that firewall IPv6 log entries. This is quite strange!
-
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
-
I was trying to follow your instructions from this post
https://forum.pfsense.org/index.php/topic,62928.msg341417.html#msg341417
so: how do I log Snort LAN activity to fully achieve the scope of that advice?
-
I was trying to follow your instructions from this post
https://forum.pfsense.org/index.php/topic,62928.msg341417.html#msg341417
so: how do I log Snort LAN activity to fully achieve the scope of that advice?
Not sure I fully understand your question. Snort will log naturally to its own alert file (and to Barnyard2 if you enable that option and have a remote MySQL database
or syslog server where Barnyard2[edit: output to syslog is coming in next Snort update] can send the data). Bad things (or potentially bad things) Snort finds in traffic will be visible on the ALERTS tab. You can also configure Snort to log events to the system log. Snort does not, and cannot, log events to the firewall log.If you are asking more of a philosophy question for how to see which particular internal hosts on a LAN might be infected, then here is why I suggested the method you linked. Most home networks (and in fact, most corporate networks) use NAT to allow internal hosts to communicate with the Internet. So if you put Snort only on the WAN interface, it will see all the traffic, but the only "internal address" it will ever see is the WAN interface's IP address. So the logs for Snort would always show just your firewall's WAN IP address for any internal host. This is because Snort sees stuff "pre-NAT' on the way in and "post-NAT" on the way out. So you would get an alert if an internal host triggered a Snort alert when some malware phoned home, but the only two IP addresses you would have are the external CC BOT on the Internet and your firewall's WAN IP. Neither of those will help you find which internal host is infected. However, if you run Snort on the LAN side of your firewall, now it sees the real LAN hosts' internal IP addresses. It will also still see the external target IP addresses. So you get a much better picture in your logs of which internal host might be a problem.
The last thing you want to do (IMHO) is run the exact same rules on the WAN and LAN. That just wastes resources. I run a fairly comprehensive rule set on my LAN interface, and then just a rudimentary set of ET COMPROMISED and ET DROP rules on the WAN side.
If I failed to adequately answer your question in my rambling response, rephrase it and hit me again… ;D
Bill
-
Understood. ;)
So, to review all the alerts generated by Snort for the LAN interface I should simply go to Snort –> Alerts --> "Instance to inspect" and choose the LAN interface.
Then I should look at the SRC column and there are my internal machines and their activity. Is this correct?
Second (and important) question: how do I setup "just a rudimentary set of ET COMPROMISED and ET DROP rules on the WAN side"?
I have a paid subscription for personal use of VRT rules.
Thank you, I'm learning A LOT!
-
Understood. ;)
So, to review all the alerts generated by Snort for the LAN interface I should simply go to Snort –> Alerts --> "Instance to inspect" and choose the LAN interface.
Then I should look at the SRC column and there are my internal machines and their activity. Is this correct?
Second (and important) question: how do I setup "just a rudimentary set of ET COMPROMISED and ET DROP rules on the WAN side"?
I have a paid subscription for personal use of VRT rules.
Thank you, I'm learning A LOT!
Correct on where to look – the ALERTS tab and select the LAN instance to view. As for SRC or DST, that depends on whether for a particular exchange your LAN machine was the originator or receiver of the traffic. Either way, if you see a LAN host in either the SRC or DST column, you will want to investigate the alert. Right away let me say, in case you are new to Intrusion Detection Systems like Snort, that false positives are unfortunately quite common. That means Snort (and other tools as well) will sometimes mistake perfectly OK traffic as something bad and generate an alert. Worse, if block offenders is also enabled, legitimate traffic can get blocked. There are some threads here on the Packages sub-forum from users who have created some good Suppress Lists to try an minimize the occurrence of false positives.
The particular rules I was referring to (ET COMPROMISED and ET DROP) are part of the Emerging Threats rule set. They are totally free and require no registration. Just enable Emerging Threats Open Rules on the GLOBAL SETTINGS tab in Snort. Then download a fresh set using the UPDATE RULES tab. You can then choose some of them to compliment your Snort VRT rules on the LAN, and run some of the lists of known bad IP addresses (that's what ET COMPROMISED, ET DROP and ET CINS are) on the WAN.
Bill
-
I'm a bit confused about how the Interface tabs present the rules (or maybe I'm ignoring the principles).
Where do I setup / exclude / include the rules? I can't read along the Snort docs and the pfSense Package interface (my limitation, of course).
So, the TAb to take into consideration is the WAN Rules or the WAN Categories?
I'm asking this because the rules you mentioned (e.g. "compromised") are listed in the WAN Categories, but I thought I had to choose the rules using the WAN Rules TAB.
I hope I'm not bothering you with these questions :)
-
I'm a bit confused about how the Interface tabs present the rules (or maybe I'm ignoring the principles).
Where do I setup / exclude / include the rules? I can't read along the Snort docs and the pfSense Package interface (my limitation, of course).
So, the TAb to take into consideration is the WAN Rules or the WAN Categories?
I'm asking this because the rules you mentioned (e.g. "compromised") are listed in the WAN Categories, but I thought I had to choose the rules using the WAN Rules TAB.
I hope I'm not bothering you with these questions :)
The rules that Snort uses are really just signatures (similar to AV signatures). They tell Snort what patterns to look for when identifying malicious traffic. These rules (or signatures) are grouped into collections called rule sets. These rule sets are called Categories in the Snort package. A Category is simply a collection of rules (or signatures) that all detect similar kinds of malicious activity. So on the Categories tab you enable groups of rules when you check one of the checkboxes. Once you click a rule category and save it, the category name becomes a hyperlink on the Categories tab. You can click that hyperlink to open a pop-up window where you can view all the rules grouped into that category. Grouping rules into categories makes it easier to select rules relevant for your network. If you don't run a web server, then you have no need of all the rules for protecting a web server. You can save CPU cycles by not selecting that category of rules. Similarly, if you don't have a mail server, then you probably have no need for the SMTP rule category.
The Rules tab lets you manage the individual rules within the selected category. You select a category in the drop-down box on the Rules tab, and then all the individual rules (or signatures) assigned to that category show up in the bottom. You can then selectively enable or disable the individual rules. It is quite normal for some of the rules in a category to be disabled by default while others are enabled. The rule set creators determine which rules they default to enabled or disabled. An admin can then choose to tweak the rules to fit their specific networking needs. On the Rules tab, the small icon on the far left beside each rule indicates its current 'enabled' or 'disabled' state. A grayed-out icon means the rule is by default disabled in the category. You can click on the X icon to toggle the rule to either 'force enable' or 'force disable' (depends on what it's default state is). The icon changes color to indicate the state. It also has a pop-up tool-tip you can see if you hover your mouse over the icon for a few seconds.
If you run the Snort VRT rules (and you said you had a subscription for those), then you have an additional option available on the Categories tab. You can choose from one of three pre-set IPS Policies in a drop-down. When you enable a policy, Snort automatically selects a collection of rules from all the various Snort VRT categories that match the policy definition. The assignment of a rule to a given IPS Policy definition is done by the VRT rule creators at Snort.org. They tag each rule with special metadata to indicate which of the three IPS policies the rule is assigned to (and a given rule can be in more than one policy). When you enable an IPS Policy, then all of the Snort VRT rule categories are grayed-out since the policy selection takes precedence. You can still, though, go to the Rules tab, select the IPS Policy from the category drop-down, and manually disable any of the rules automatically added by the policy. You might do this, for example, if one of those rules was generating a lot of false positives in your environment.
One last point. There are currently three "vendors" of rules available in the Snort package: (1) Snort VRT, (2) Emerging Threats, and (3) Snort GPLv2 Community Rules. The Emerging Threats rules are divided into categories (collections of related rules) just like the Snort VRT rules are. The GPLv2 Community Rules all come in a single huge package (no grouping into categories within GPLv2). This means that you can, if you choose, run a Snort IPS policy and then combine some Emerging Threats rules (or even several categories of rules) with it. That's what I do. I use the IPS Balanced policy on my LAN and then supplement by selecting some of the Emerging Threats rule categories like ET Malware, ET Mobile Malware and ET Trojan (I'm pulling these off the top of my head at the moment and may not have the names exactly correct). By the way, as it says on the Global Settings tab, if you have a Snort VRT paid subscription, then all of the relevant GPLv2 Community Rules are in your VRT subscription package. So if you have a paid VRT subscription, you do not need to enable the GPLv2 Community Rules separately.
One of the things long on my TODO list that I have just not made time for is to update the Help files on the pfSense documentation Wiki for Snort. I also want to fix all the Help icons in the Snort package so they correctly link to the documentation Wiki.
Bill
-
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
