clarification needed on direction of rules and usefulness
-
Hello,
I need clarification on if i should care about the direction of the flow within the rules. For example, in the snort_snort3-file-office.rules category I see mostly $EXTERNAL_NET to $HOME_NET rules. The category is enabled on my internal DMZ.
Does it make sense to enable this rule if the source is the WAN?
Is it ok to enable rules where mostly the rules are for $EXTERNAL_NET?Additionally, I see the Dports are mostly HTTP or Port 25. I have no plans on implementing a MITM proxy at this time so is it safe to say that although the rules will be acted on clear-text traffic, I shouldn't expect much in the help of TLS communications using heuristics (similar technique used by palo alto)?
Lastly, For the categories that such as Ciarmy Rules, that are basically blocking IPs, if I already have PFblockerNG deployed, are these IPS rules redundant and therefore offer no benefit? I imagine there is quite a bit of overlap between pfblocker and suricata here.
-
It sounds like, from your questions, that you are very new to administering an IDS/IPS. A little Google research on the side might prove helpful in understanding the importance of the HOME_NET and EXTERNAL_NET definitions. But here is a quick and dirty overview.
The HOME_NET variable should contain all of your protected networks. That means the IP addresses/subnets that you want the IDS/IPS to protect. EXTERNAL_NET should contain all the "bad guys" you want to either keep out, or else they are untrusted so you want to inspect everything they send into your networks. Most of the IDS/IPS rules are written with these assumptions: (1) HOME_NET contains the networks I want to protect; and (2) EXTERNAL_NET contains untrusted or known hostile networks.
Typically you first populate HOME_NET with all of your internal networks. That would include your LAN and likely the DMZ. The DMZ should be there because presumably you have servers or devices in there which are communicating with untrusted devices on the Internet, so you want them protected.
Once HOME_NET is populated, the most common method of defining EXTERNAL_NET is
!HOME_NET
, which literally means "everything not included in HOME_NET".The direction of traffic is critical when it is being evaluated. As you mentioned, the vast majority of the rules have $HOME_NET and $EXTERNAL_NET defined as either the source or destination of the traffic. If a rule is looking from something "evil" coming from the Internet, the rule will use $EXTERNAL_NET --> $HOME_NET to mean it is inspecting flows from the Internet into your local networks. If the rule is instead looking for something already inside your network "phoning home", then the flow is likely defined as $HOME_NET --> $EXTERNAL_NET. This means traffic flowing from your protected networks out to the Internet.
Lastly, encryption is rapidly resulting in the almost complete neutering of IDS/IPS technology unless MITM proxying is configured. The IDS/IPS cannot peer into encrypted traffic passing through the firewall, so HTTPS, TLS and stuff like DoT cannot be adequately inspected.
-
@bmeeks thanks for the feedback. Sorry if my question alluded to me being new to IDSs but no I’m not. I should’ve been more explicit in my question. So dealing with commercial firewalls there typically isn’t a HOME or EXTERNAL concept. It’s generally pattern matching irrespective of direction. So when I’m peering into the Suricata rules and I see source is external does that mean if I have that rule enabled on my LAN the rule is pointless OR is it looking at it from the perspective of flowing through WAN and hitting LAN and and then the rule is evaluated with source still being external. I’m trying to understand the usefulness of a rule applied to LAN if most of it is evaluating EXTERNAL.
I agree in concept with MITM and IDS but again I think from the perspective of commercial firewalls having to break into TLS flows is not entirely needed due to heuristics. I could be wrong. -
@michmoor said in clarification needed on direction of rules and usefulness:
OR is it looking at it from the perspective of flowing through WAN and hitting LAN and and then the rule is evaluated with source still being external
Yes that.
Running Snort/Suricata on WAN is "outside the firewall" so will scan packets the firewall would drop. So generally you want it on LAN, and then enable rules as you wish.
If the rule is designed for, say, a web server, then it isn't going to trigger if there aren't any ports open to the Internet. (external = Internet, home = web server)
For the categories that such as Ciarmy Rules, that are basically blocking IPs, if I already have PFblockerNG deployed, are these IPS rules redundant
Yes, and yes there are several rulesets that overlap. I set them in pfBlocker and then let the firewall block them, instead of pattern matching in IDS. Perhaps it's a wash, I don't know but it seemed more logical to me to do it that way. :)
-
@michmoor said in clarification needed on direction of rules and usefulness:
@bmeeks thanks for the feedback. Sorry if my question alluded to me being new to IDSs but no I’m not. I should’ve been more explicit in my question. So dealing with commercial firewalls there typically isn’t a HOME or EXTERNAL concept. It’s generally pattern matching irrespective of direction. So when I’m peering into the Suricata rules and I see source is external does that mean if I have that rule enabled on my LAN the rule is pointless OR is it looking at it from the perspective of flowing through WAN and hitting LAN and and then the rule is evaluated with source still being external. I’m trying to understand the usefulness of a rule applied to LAN if most of it is evaluating EXTERNAL.
I agree in concept with MITM and IDS but again I think from the perspective of commercial firewalls having to break into TLS flows is not entirely needed due to heuristics. I could be wrong.You are not properly understanding the role of the two variables in IDS/IPS. Don't confuse them with interfaces on a firewall. They are not the same concept. EXTERNAL_NET is not a "place" or an "interface" or a "direction", but instead is an IP address range (several, actually). So it does not mean the external interface on the firewall. Instead, it means IP addresses that are not within your protected networks. Notice the variable is EXTERNAL_NET (which really means "external networks", where "external" means IP addresses that are not part of your protected networks behind the firewall).
Where you run the IDS/IPS has no bearing on the EXTERNAL_NET and HOME_NET settings. Those variables help the IDS/IPS identify the source and destination of the traffic based on IP address ranges.
So here is a really simple hypothetical example just using RFC1918 addresses for illustration.
My firewall's WAN IP is 172.16.0.1 and my LAN behind the firewall is 192.168.0.0/24. I also have a DMZ in 192.168.1.0/24.
Here is what HOME_NET looks like in Suricata: [ 192.168.0.0/24, 192.168.1.0/24, 172.16.0.1/32 ]. These represent my "protected networks".
And here is what EXTERNAL_NET looks like: [ !192.168.0.0/24, !192.168.1.0/24, !172.16.0.1/32 ]. This represents a huge address space of "potential bad guys" as a lot of address space meets that definition.
So when I have a rule header like this:
$HOME_NET any -> $EXTERNAL_NET any
, that limits the rule to only triggering when an IP address defined in the HOME_NET variable is the source IP, and the destination IP is any IP address that is NOT defined in the HOME_NET variable (in other words, is in EXTERNAL_NET).So this traffic would trigger the rule:
192.168.0.23 any -> 8.8.8.8
because 192.168.0.23 is an IP address defined in the HOME_NET variables list of subnets, and 8.8.8.8 is an IP address that is NOT defined within HOME_NET, and thus it matches the definition of EXTERNAL_NET (which is actually defined as !HOME_NET). In my example I put the actual IP definitions there, but it is perfectly acceptable to define EXTERNAL_NET as [ !$HOME_NET ].Conversely, this traffic would NOT trigger the same rule:
8.8.8.8 any -> 192.168.0.23
because 8.8.8.8 is not an IP address defined in HOME_NET, so the very first condition of the rule (an IP defined in HOME_NET is the source) is not met.Typically the WAN public IP is also defined in HOME_NET (just the interface IP - not the entire subnet). But if the WAN interface IP is not defined in HOME_NET, and you are using NAT, because Suricata on pfSense runs outside the firewall engine and sees traffic before NAT is undone, some rules might not trigger if HOME_NET was the source or destination and HOME_NET did not contain the WAN interface IP.
The Suricata package on pfSense automatically populates the HOME_NET and EXTERNAL_NET variables for you with default values based on the assigned IP ranges on the firewall interfaces. You can see what the content of each variable is by going to the INTERFACES tab, clicking to edit an interface, and then scrolling down and clicking the View button beside the HOME_NET and EXTERNAL_NET drop-down selectors.
-
@bmeeks Understood. In my mind, because the firewall is stateful I was thinking that the rules although are evaluated from EXTERNAL to INTERNAL, there was some value of having the rule applied on the internal lan as the firewall would see the return traffic.
So are you saying it operates from a purely stateless way, rule evaluated from source to destination (external to internal) and that's it. There needs to be a rule matching from HOME to External?
Lastly, from your standpoint, PFblockerNG and some of the ET rule sets have IP blocking. I assume there is overlap. Does it matter if the suricata rules are enabled for those IPs as well? Assuming there is no resource constraint on the firewall.
-
@michmoor said in clarification needed on direction of rules and usefulness:
rule evaluated from source to destination (external to internal) and that's it. There needs to be a rule matching from HOME to External?
It depends on the rule, for example a malicious HTTP request wouldn't flow from the web server to the client, the "browser"/attacker sends it to the web server.
-
@steveits Gotcha. Ok makes sense to me.
-
@michmoor said in clarification needed on direction of rules and usefulness:
@bmeeks Understood. In my mind, because the firewall is stateful I was thinking that the rules although are evaluated from EXTERNAL to INTERNAL, there was some value of having the rule applied on the internal lan as the firewall would see the return traffic.
So are you saying it operates from a purely stateless way, rule evaluated from source to destination (external to internal) and that's it. There needs to be a rule matching from HOME to External?
Lastly, from your standpoint, PFblockerNG and some of the ET rule sets have IP blocking. I assume there is overlap. Does it matter if the suricata rules are enabled for those IPs as well? Assuming there is no resource constraint on the firewall.
I am not understanding why you bring in stateful connections and rules. It seems to me you are confusing the IDS/IPS with the firewall. They are not the same at all! In fact, most commercial enterprises run the IDS/IPS on a completely separate box and not on the firewall.
The IDS/IPS (Suricata in your case), is totally ignorant of firewall states and even firewall rules. It simply evaluates packets as they flow across the physical interface Suricata is monitoring. And it is only looking at the IP header info in the packet to determine how far to evaluate that packet against the Suricata rules (not the firewall rules, the firewall rules are totally irrelevant to Suricata).
Suricata, especially when running in IPS mode, does not interact with the firewall engine at all. Not one bit. Actually Suricata sits out in front of the firewall. Here are two diagrams that show Suricata lives "outside", on the NIC-side of the firewall and thus sees traffic before the firewall rules have been applied.
In terms of your pfBlocker question, if you use only simple IP lists in Suricata, then there would be perhaps 100% overlap between what it does and what pfBlocker does. But most folks would not do that. If you use pfBlocker, then you might apply other rules in Suricata that are not simple IP lists. But as we discussed much earlier in this thread, encryption severely hinders the ability of Suricata or any IDS/IPS package to peer into the packet payload.