Snort Rules
-
I am running snort on my network appliance. This is currently how it is configured. Would there be redundancy if enabling Snort rules AND ET rules? Would I be able to enable all listed here, or would there be conflicts?
-
For your question, the answer is somewhat mixed. You don't state which type of Snort Subscriber Rules you are using: the free registered user version, or the paid version. The difference (besides free versus $29.99/year for personal use) is the age of the rules. The rules in the free version are at least 30 days behind the paid version. Meaning that if a new threat comes out tomorrow and Snort creates a rule to detect it, that rule goes immediately into the paid version of the rules, but it won't show up in the free version of the rules until 30 days after it was placed in the paid version. So one of the things you give up with "free" is protection against newly identified threats.
The Emerging Threats rules work the same way. The free version (ET-Open rules) are at least 30 days older than the paid ET-Pro version. And even more worrisome with ET rules is the fact that not all ET-Pro rules make it over to the free version. Their free version is always only a subset of their more expansive paid version rules. Unfortunately, the paid ET-Pro rules are incredibly expensive compared to the Snort rules (like almost $600 or so per year versus $30 per year).
So whether or not it's good to run both Snort rules and ET rules together is a hard question to answer definitively. If you have lots of RAM to spare on the firewall, along with idle CPU time, then there is no harm in enabling both sets of rules. There is the odd chance one set of rules will detect some particular threat that the other set of rules missed. Not likely, but not impossible either. That's about the best answer I can give you.
Many folks do run at least some of both sets. My favorite setup is to use the Snort rules and configure the "IPS-Policy Connected" on the CATEGORIES tab. That policy automatically selects a good set of rules from the Snort list that detects major (and most likely to be encountered) threats, while at the same time not being too prone to false positives.
I then supplement that with a subset of the ET-Open categories like emerging-scan, emerging-malware and a couple of other similar ones that I don't recall at the moment off the top of my head. I use the paid Snort rules.
-
@bmeeks I'm actually noticing now that I can't check any of the rows in the middle two columns. I have my oinkmaster code entered. Why would the checkboxes be disabled?
-
If you have an IPS Policy selected, it overrides any manual selection of Snort Subscriber Rules. The selected policy is 100% in control, thus the Snort checkboxes are greyed-out on the CATEGORIES tab.
-
Is there any way to manage the rules in this mode (disabling, or changing to alert only for certain rules)?
I've been reviewing this document: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions which has been helpful.
I notice that when I set the IPS Policy Selection to "Security", I don't see any dropped or rejected traffic under the Alerts tab. I am trying to test if IPS mode is working. All I see are Alerts.
Also, when I set it to max-detect, the Snort interface fails to start. If I do Security or lower, it starts just fine. Why would selecting this mode cause it to fail to start?
BTW, I am using the free subscription of Snort rules.
-
I assume, based on the screenshot you posted, that you have a NIC that supports netmap operation and thus Inline IPS Mode blocking (or dropping). Otherwise, the Drop SID List and Reject SID List drop-downs would be grayed-out.
All the rules vendors ship their rules set for ALERT by default. The Snort rules that have IPS policy tags in them include a suggested alternative action as well. That alternative action is usually DROP. But depending on the policy (Connectivity, Balanced or Security, for example), a given rule might have IPS Policy tags for all three policies, but be set for ALERT in some policies and DROP in others. So over on the CATEGORIES tab, where you selected the IPS Policy to use, there is another choice in that same section of the page called IPS Policy Mode where you choose how the policy is enforced. When that is set to "Policy", then the SID MGMT feature will take the hint included with the metadata associated with the policy name and alter the rule's action accordingly. So it will change the action of some rules from ALERT to DROP. When set to "Alert", then the rules retain their default action of ALERT no matter what the policy hint in the metadata says.
So to your question about changing rules to ALERT. Generally you don't need to do that because they are all ALERT by default anyway. If you are talking specifically about IPS Policy selected rules, the action of a given rule is determined by the IPS Policy metadata hint AND the setting of the IPS Policy Mode selection described above. But if there is a case where the IPS Policy hint says DROP for the rule's action, but you want that rule (and only that rule) to be ALERT, then you have to do that on the RULES tab. Select IPS Policy in the Category drop-down, then in the list of rules that will populate below click the Action icon to bring up a modal dialog where you can force override the rule's action.
On the SID MGMT tab you can enable or disable rules, and you can change rule actions from ALERT to DROP or REJECT, but you can't change an IPS Policy action on the SID MGMT tab. To do that, you need to go to the RULES tab as described above.
Odds are that choosing Max-Detect as the policy activated rules that need a preprocessor enabled that is not enabled by default. Check the pfSense system log for Snort messages. It is pretty good about logging reasons for not being able to start.
Lastly, for rules to "fire", it is very important that the $HOME_NET and $EXTERNAL_NET variables are set correctly as almost all the rules use these to limit alerts. These variables, and their impact on how traffic is evaluated against the rule signatures, can trip folks up. For example, if you test from the LAN side trying to trigger a rule, but the rule is testing for traffic coming from $EXTERNAL_NET into $HOME_NET (which most do), then the rule won't trigger because the test traffic is coming from the LAN address space (which is defined by default as $HOME_NET) and not from $EXTERNAL_NET.
-
That is correct. My interfaces are showing up as igbx.
I do have IPS Policy Mode set to Policy. As for those two variables, home_net includes my internal subnet and my external IP. For external_net, I see it's configured for NOT external IP and NOT internal IP. In the Alerts tab though, I still don't see any traffic that is being dropped. -
@droidus said in Snort Rules:
That is correct. My interfaces are showing up as igbx.
I do have IPS Policy Mode set to Policy. As for those two variables, home_net includes my internal subnet and my external IP. For external_net, I see it's configured for NOT external IP and NOT internal IP. In the Alerts tab though, I still don't see any traffic that is being dropped.Are you positive that your interface is seeing traffic that would match the rules? Dropped traffic will be shown in red text on the ALERTS tab. When using Inline IPS Mode, the BLOCKS tab is not relevant. No dropped traffic will ever show up there.
Do you have Snort running on the LAN, WAN or both? If LAN, remember your firewall is going to block probably all unsolicited inbound connections. Thus Snort would never see them.
Finally, when you make changes to things on the SID MGMT tab and other places, you usually need to restart Snort on the affected interface as settings are read from the configuration file only at startup. Snort is not a dynamic software package. It reads configuration on startup.
-
I can't say for sure. I would think with Security IPS Policy Selection, there would be traffic being dropped.
I am running Snort on my LAN. I restarted the service again. In the alerts, I filter by Reject and Drop, and I don't see anything. -
@droidus said in Snort Rules:
I can't say for sure. I would think with Security IPS Policy Selection, there would be traffic being dropped.
I am running Snort on my LAN. I restarted the service again. In the alerts, I filter by Reject and Drop, and I don't see anything.Well, that actually depends entirely on the traffic. And that, in turn, is dependent on exactly what the host machines on the LAN are doing. Routine things like checking for updates or talking to web sites are not likely to generate drops. You typically only want to drop truly malicious stuff. So the IPS Policy rules are written with that in mind. Sure, the "IPS Security" policy is going to have more rules in it, and more of those rules will have the DROP metadata hint. But the traffic those rules are looking for (including the $HOME_NET and $EXTERNAL_NET directions, ports and IP networks) still has to match up.
If you have the means, you can configure something like a Kali Linux box on the WAN side and use it to attempt scans. One problem with that, is if your WAN rules are blocking, then Snort on the LAN side will never see the scan. You can do
nmapscans from the LAN into say the firewall's LAN IP, but the rules won't fire then unless you edit them to change the source from $EXTERNAL_NET to any. Most rules are written assuming traffic flows this way:$EXTERNAL_NET --> $HOME_NETwhich is interpreted to mean traffic from an IP address that is not in your LAN space (i.e, some Internet address) destined to an IP that is defined in $HOME_NET (by default, that's your local networks and your WAN external public IP).
So if you were to do an
nmapscan of your firewall's LAN IP from some host on the LAN, the rules would not trigger because the source IP of the scan traffic would be $HOME_NET and not $EXTERNAL_NET. -
To maybe make you feel better, I run Snort on my LAN with the IPS Balanced policy along with some of those ET-Open categories I mentioned earlier. I see maybe one or two DROPs per month in my logs. Ironically, if you see lots of DROPs, that really should make you quite nervous about the overall security of your network. Because that would mean a lot of your LAN hosts either are, or were, visiting questionable sites or doing questionable things (and thus may be infected with malware of some sort).
Edit: some additional info ... I mentioned in one of my earlier posts above that my favorite policy was "IPS Policy Connected". That's the policy I recommend to all users new to administering an IDS/IPS. So that's the context of "favorite" in my earlier post. Once you gain experience with the IDS/IPS, you can move to something like "IPS Policy Balanced". I don't suggest anyone go beyond that unless you are protecting military secrets or access to all the UFOs stored at Area 51 ...
.
