Suricata default rules
-
How are the default rules determined when a ruleset is enabled? For instance, I've enabled the emerging-adware_pup.rules but only half of them are enabled. How is the determination made for which ones are enabled by default and which ones aren't?
-
That is a decision made by the authors/creators of the rules. Many times rules are disabled because they tend towards false positives in many environments. Another common reason is the rule is designed to detect an uncommon threat, and thus may not actually be needed in many networks.
This is why I preach a lot in this forum about the need to really and truly understand the security exposures and associated threats that actually apply to your network environment before enabling rule categories or even individual rules. Instead, many people want to treat the IDS/IPS rules like a set of anti-virus signatures and just go through and enable them all. Then they post back here wondering (or complaining, in some cases), about all the blocks they are receiving ...
.You almost have to be the equivalent of a Black Hat hacker to effectively deploy and maintain an IDS/IPS. You must really understand how vulnerabilities are exploited, and exactly how the various IDS rules work to detect those exploits. Then you can make educated decisions about enabling rules (or not) in your network environment.
-
@bmeeks I think it's safe to say most of us wear many hats but they probably aren't black, white, or grey very often or for very long. That's why we rely on seasoned vets, such as yourself, for guidance. We use IDS for 2 main reasons; compliance and protection.
PCI, HIPPA, Alta's Pillar3, and others require logging of all attempted attacks so for that reason we run the IDS on the WAN so that it all gets logged even if the FW drops it by default. If someone is able to compromise a network from a specific IP you need to know what they've been trying and for how long and show what steps were taken and what processes are in place to mitigate the attacks. If you only run it on the LAN then you don't see any of that stuff and you only know once you've been compromised.
I am aware you advocate for putting blocking on the LAN and not the WAN, but we block on the WAN and log on the LAN. Doing that allows us to log for compliance and block for all the internal networks in one spot. Also, since we log in remotely to support the computers, blocking on the LAN wound up blocking the individual's workstation and preventing us from connecting to them. We also found that, for whatever reason, it would sometimes block users from internal resources. I know that traffic should get shunted around by the switches and not need to get to the router unless it needs to be routed but all too often I find that if the a PC can't reach the router it can't even get to local printers on the networks. Maybe it's not the most efficient way of doing it but we've found it to be effective.
And just having it on, even if not optimal, can help. We installed at an extended stay hotel, blocked on the WAN, logged on the Tenant LAN, and found a machine infected with ZeroAccess. The hotel was able to notify the Tenant with the machine so that they could get it cleared out.
I'm not going to pretend I know the rules inside and out or how they all work. I don't have any NetSec certifications. It's an area of interest for me and something I've spent more than a few hours studying over the years. I'll admit I approach it more like AV definition sets but you are certainly correct in that you can't just turn it all on and wonder why everything breaks. The app-layer and stream-events rule sets alone are enough to stop any network from communicating ever again! However, when I see the ET-Exploit or ET-Malware categories only have some rules enabled I think to myself "Why only offer protection against some of these attacks? Why not protect against them all?"
-
My reply was intended for this forum in general, and not aimed at any particular user. I will often use my answer to the questions of one poster to make a broader point to all the others who may come by to read the posts.
Another reason why you will find some rules default disabled is that they might be for old threats. In other words, for exploits in older operating systems that are no longer mainstream (maybe Windows XP, for instance). The assumption would be that most folks today would not have XP in their network, so no sense bogging down the IDS/IPS testing traffic against what would be non-existent vulnerability exploits in Windows 10, for example. This gets back to my point about knowing your network and what threats are legit, and which are not, for your network. So if you actually had Windows XP machines that were unpatched or otherwise vulnerable to some old threat, you would want to carefully examine the rules to make sure you have the correct ones enabled for the threats that matter for your network. That might very well mean force-enabling some of those default-disabled rules.
So there are many reasons why the different rules categories contain default-disabled rules. To recap some of them:
- The rule may be prone to false positives in many networks.
- The rule may protect against esoteric threats and is not generally useful in most networks.
- The rule may be looking for exploits applicable to older, out-of-support operating systems.
- The rule may be experimental in nature and not yet ready for "production" deployment.
- The rule may be more "informative" in nature as compared to "protective", and thus is considered not essential to have enabled in most environments.
The common rationale that can be gleened from the above list is that the vendors try to avoid overloading the IDS/IPS engine with too many enabled rules. It's about optimizing protection while conserving resources. A delicate balancing act to be sure. That's why a good IDS/IPS admin is a sought after, and valuable, resource at some companies!
So I'll close with a bit of hyperbole as an example.
If I have a 32-core, 1 TB RAM beast server, then I could probably enable every rule in every category and have CPU cycles and RAM to spare. But I will also have spent a ton of money on hardware (not to mention power and cooling and noise). On the other hand, perhaps if I just carefully choose which rules to enable based on the actual vulnerabilities in my network, I might find that an SG-1100 appliance is all I really need...
. So it's back to that delicate balancing act I mentioned, and that's where the great IDS/IPS admin earns their keep. So to close the circle, the reason you will find some rules default-disabled is due in large part to this balancing act I keep coming back to. -
I, as I'm sure others, greatly appreciate your efforts and help. I wrote my reply as a general explanation so that you and any others that come along can see the general use-case for why we run things the way we do. We've found that most IT companies that we encounter are unaware of compliance requirements so I thought I'd in why we do things the way we do, even if it isn't the most common use-case or config.
I vaguely remember you (maybe not you as well) mentioning that running the IDS on the physical interface hosting VLANs will run in promiscuous mode and will also capture all the VLAN traffic as well. This would mean that we could get by with just one instance of Suricata Logging instead of several, one for each VLAN. Is that accurate?
-
@stewart said in Suricata default rules:
I vaguely remember you (maybe not you as well) mentioning that running the IDS on the physical interface hosting VLANs will run in promiscuous mode and will also capture all the VLAN traffic as well. This would mean that we could get by with just one instance of Suricata Logging instead of several, one for each VLAN. Is that accurate?
Yes, that is correct for Legacy Blocking Mode (and also for non-blocking mode).
That is not the case with netmap and Inline IPS Mode, but VLANs don't work well there anyway because netmap can't see the VLAN tags (not yet, anyway -- it's a kernel limitation).
-
@bmeeks We do everything as Legacy. As I recall there was an issue with with traffic shaping when using in-line. Is that still an issue?
-
@stewart said in Suricata default rules:
@bmeeks We do everything as Legacy. As I recall there was an issue with with traffic shaping when using in-line. Is that still an issue?
Yes, again due to limitations within the kernel with the netmap device. The netmap device, when enabled, literally breaks the connection between the kernel and NIC and puts itself in the middle. This can then break certain functionality between NIC and kernel. That includes VLAN tags, traffic shaping, and even some of the traffic stats reporting. The Inline IPS Mode for both Suricata and Snort uses the netmap device to facilitate the IPS operating mode.
-
@bmeeks Cool. Again, thanks for all the effort on this!
