SURICATA question about rules
-
New to pfsense (2.3.3-RELEASE-p1 (amd64) ) and suricata (3.1.2_2), so please, help me
I installed suricata with ETOpen and SnortVRT rules enabled
I started with enabling IPS on the WAN interface, enabled some emerging rules, and managed to get some drops on the WAN traffic, using dropsid-wan.conf and disabledsid-wan.conf (I disabled suricata stream 1:2210000-1:2219999 as recommended in some topics)I than enabled IPS on a single LAN adapter (I've got three LAN ports), to check if there where any alerts
I looked at the content of the emerging-activex.rules, I don't seem to be able to view the content of a rule set, unless I activate it - may be I just haven't found the correct way to "preview the content"
In the emerging-activex.rules the source is almost always $EXTERNAL_NET, the destination is almost always $HOME_NET, there seems to be only one exception to this in the emerging-activex.rules.
My question: Looking at the source and destination fields, it seems (but I maybe wrong) pointless to activate the emerging-activex.rules on the LAN interface (apart from the one exception in that rule set), because the destination is $HOME_NET. I feel this rule set is only useful on the WAN (source $EXTERNAL_NET).
Is my assumption correct?
Thank you for your time and effort.
-
At the moment you must "activate" a rule set category in order to open it for viewing on the RULES tab (or by clicking the resulting hyperlink on the CATEGORIES tab). That is a holdover from the original Snort package on pfSense, and I kept that behavior when I took over maintainer duties for Snort quite some time back. When I created the Suricata package, it was essentially a copy-paste job from Snort PHP code with just some edits along the way. So that same behavior of needing to first enable a category before you can view it came over to Suricata. I will put an item on my future feature list to let you view categories without enabling them first.
As for $HOME_NET versus $EXTERNAL_NET, they still work on the LAN. You still have the concept of "HOME" and "EXTERNAL" on the LAN side of the firewall. I run a number of Snort VRT and ET-Open categories on my LAN and get alerts just fine, including those ActiveX ones. It may help you understand HOME and EXTERNAL better to think of them as "protected" and "the enemy". HOME_NET is all of your protected networks (your LAN usually), while EXTERNAL is defined by default as !HOME (meaning everything not in HOME_NET and is thus assumed to be the enemy). So assume an external web site like Google DNS at 8.8.8.8 sent a whacky packet to your LAN host at 192.168.0.3. The rule should fire and show 8.8.8.8 as the EXTERNAL_NET source and 192.168.0.3 as the HOME_NET destination.
Now if you instead had those rules on the WAN side, the rule would still fire but the HOME_NET IP address would be the external public-facing IP of the firewall and not your 192.168.0.3 internal host. This is because Suricata (and Snort) sees traffic before the NAT rules are applied on the WAN side. On the LAN side, it sees the native traffic after NAT has been "undone". So a lot of folks run their biggest rule sets on the LAN side so that they can easily find offending or impacted LAN hosts. On the LAN side the IP addresses will be "normal". On the WAN side everything that is "local" will show up in the alerts as the external IP of the firewall, so tracking down the impacted LAN host is quite a chore.
Bill
-
Thank you for this. Some follow up questions…
1. How do you decide where to use a specific rule set (LAN, WAN or both)?
2. I'm also using the ETOpen and SnortVRT rules, IPS inline mode. Would you be willing to list the rule sets you run on LAN and WAN?
I'm not really sure what rules to enable (but fairly convinced it is a bad idea to activate them all), The forum topics aren't very helpful for this choice. I looked at https://forum.pfsense.org/index.php?topic=121056.0 (third entry), but not really sure this is the way to go, since there is no motivation for the selection.
<edit>I just found this:
https://raw.githubusercontent.com/jflsakfja/suricata-rules/master/list.txt
does this make any sense?</edit>3. Would there be a reason to activate a rule set and NOT add this rule set to dropsid.conf (apart from initial evaluation of the impact)?
4. As I mentioned before, I'm new to all of this, and having a hard time to understand the "flowbits" concept (and the performance impact), so I haven't checked the option. Is it recommended to enable this option? Would you recommend to enable it on WAN and LAN?
Thank you for your time and effort.
-
For your Flowbits comment/question, I recommend you read a couple of replies I posted in a different thread. Here is a link to the first comment, and my other comment is a post or two down in the same thread: https://forum.pfsense.org/index.php?topic=95881.msg710990#msg710990. You most definitely want to enable the autoflowbits option! Without their dependent flowbit rules being enabled, some other flowbit-dependent rules will not trigger even when enabled.
As for running rules on the WAN or LAN, for home users or corporate users with NAT enabled and no public facing services (no ports open/forwarded), I would suggest running all the rules on the LAN. That way your alerts/drops will show the native LAN host IP addresses instead of showing everything local as being the WAN external IP. Now if you have public facing services such as a web server, mail server, etc., then I would put the rules designed to protect those hosts on the WAN. If the public facing stuff is in a DMZ, then you could put the rules on that interface instead of the WAN.
@jflsakfja's list of Suricata rules can be a good starting place. I personally still run Snort on my home LAN. I have the Snort VRT IPS Balanced policy enabled on my LAN along with these ET-Open rule sets:
emerging-botcc.rules
emerging-malware.rules
emerging-mobile_malware.rules
emerging-trojan.rulesI mentioned in my first post in this thread that I ran the emerging-activex rules. I did run the emerging-activex rules in the past, but since my switch to Chrome and away from Internet Explorer, I disabled those rules. I had forgotten about disabling them until I went to get my list of categories for this post. I live a somewhat boring Internet life… :(. There is only my wife and me using computers, and the sites we visit are generally benign and safe. I don't run torrents, don't play games and don't surf the dark web. So I see maybe one or two alerts per quarter on my LAN (literally!). Just so I can see Snort doing something, I enabled the emerging-ciarmy and emerging-dshield rules on my WAN just because they frequently trigger (they are just long lists of known bad-actor IP addresses). I use them just to have some alerts in my logs in all truthfulness (since I get so few on my LAN side). The most frequent alerts on the WAN from those rules are scanners probing for open SSH and MS-RDP ports.
There can be valid reasons for alerting on traffic as opposed to dropping it. Some rules, if triggering frequently, might indicate someone trying to find a way in or it may reveal a misconfigured device on your LAN. And then some rule categories are mainly just noise and fill the alert log up with stuff. The Stream alerts are notorious for this in Suricata, and the HTTP_INSPECT alerts do the same over in Snort.
Bill
-
Thank you very much for your answers, very helpful…
One of the pfsense adapters is a build in WIFI adapter (I bought a Mini pc 4 * lan qotom-q190g4 with celeron j1900 quad core 4 +WIFI). Any specific considerations for the WIFI interface?
You say you have "Snort VRT IPS Balanced policy enabled".
Does this also imply pcre:pcre:balanced-ips\s*drop in dropsid.conf (and is this the correct syntax)?Of topic: when can we expect suricata with hyperscan in the packages for pfsense (stable)? It seems very interesting.
Thanks again for your time and effort
-
Thank you very much for your answers, very helpful…
One of the pfsense adapters is a build in WIFI adapter (I bought a Mini pc 4 * lan qotom-q190g4 with celeron j1900 quad core 4 +WIFI). Any specific considerations for the WIFI interface?
You say you have "Snort VRT IPS Balanced policy enabled".
Does this also imply pcre:pcre:balanced-ips\s*drop in dropsid.conf (and is this the correct syntax)?Of topic: when can we expect suricata with hyperscan in the packages for pfsense (stable)? It seems very interesting.
Thanks again for your time and effort
If the WIFI adapter is a separate subnet or VLAN (and I assume it probably is), then you could run maybe mobile device rules there. Really doesn't matter. It could just be a duplicate of what's on your LAN.
"Yes" on the dropdsid.conf setting if I had Suricata, but Snort does not offer inline IPS mode so no need to use DROP actions. In Snort (and Suricata when using Legacy Mode blocking) any alert also generates a block, so no abililty to tailor rules with some alerting and others dropping. All alerts "block" in Legacy Mode and when using Snort. Inline IPS mode with Suricata is the best when you have fully supported NICs.
To be honest I would have thought the new hyperscan package was already in pfSense stable. I have not checked lately. I know the plan was for the pfSense developer team to release soon after it went public in the 2.4-BETA snapshots. I can send an email to the team to see what the holdup is.
P.S. – one way to gain some insight into how flowbits work and why they are critical is to search your rules for the option keywords "flowbits: isset" and "flowbits: set". There are also "unset", "isnotset" and "setx" options. You can grep the rules files to find the strings. The "set" keyword is used to set particular flowbits when a condition specified in the rule is true. Other rules will come along and check the status of those flowbits by using the "isset" option keyword. For these types of rules, they will fire only when the corresponding flowbit is set. Another way to think of flowbits is as bit flags. They provide a mechanism for saving "state" across a series of rules that are processing a packet stream.
Bill
-
Once again, thank you so much for your insight.
I've implemented your configuration (but haven't configured dropsid.conf yet - awaiting the alerts first…)
One final question about something that isn't quite clear to me (newbie)
I'm running IPS inline mode, balanced as you indicated (used connectivity before). The help text explains the different settings perfectly.
There seem to be 4 choices:
- connectivity
- balanced
- security
- maximum detection
I suppose the setting in dropsid.conf must match this setting, are these correct?
for connectivity: pcre:pcre:connectivity-ips\sdrop
for balanced: pcre:pcre:balanced-ips\sdrop
for security: pcre:pcre:security-ips\sdrop
for maximum detection: pcre:pcre:maximum detection-ips\sdropThere is a space in the last one, is this (and the others correct)? I found some other examples on the forum (different names) and not quite sure what to use.
P.S. IPS inline mode even seems to work on the build in WIFI adapter (alert only for now).
thanks again…
-
Once again, thank you so much for your insight.
I've implemented your configuration (but haven't configured dropsid.conf yet - awaiting the alerts first…)
One final question about something that isn't quite clear to me (newbie)
I'm running IPS inline mode, balanced as you indicated (used connectivity before). The help text explains the different settings perfectly.
There seem to be 4 choices:
- connectivity
- balanced
- security
- maximum detection
I suppose the setting in dropsid.conf must match this setting, are these correct?
for connectivity: pcre:pcre:connectivity-ips\sdrop
for balanced: pcre:pcre:balanced-ips\sdrop
for security: pcre:pcre:security-ips\sdrop
for maximum detection: pcre:pcre:maximum detection-ips\sdropThere is a space in the last one, is this (and the others correct)? I found some other examples on the forum (different names) and not quite sure what to use.
P.S. IPS inline mode even seems to work on the build in WIFI adapter (alert only for now).
thanks again…
You don't really have to put the IPS Policy stuff in dropsid.conf. No harm in doing it, but there is a drop-down option on the CATEGORIES tab that should appear when you enable an IPS Policy. That option lets you choose "Alert" or "Policy" for the rule action of IPS Policy rules. The Snort VRT folks add a suggested IPS action (alert or drop) for each rule tagged as part of an IPS Policy. The same rule may have an "alert" action in say the "Connectivity" policy and a "drop" action in the "Balanced" or "Security" polices. It varies rule-to-rule, and the suggested action is provided by the VRT rule authors when they create the rule and assign it to the various policy categories.
So I added the new IPS Policy Mode choice to the GUI in the recent past. When you choose "Policy" for the option, then Suricata will automatically set the rule action to that suggested by the VRT rule authors based on the selected policy. In other words, it automatically will do the equivalent of configuring the dropsid.conf stuff for the VRT Policy rules behind the scenes. It won't actually change the dropsid.conf file. Instead, it alters the rule actions as it builds the common rule set file for the interface (the suricata.rules file). Now you do need to have dropsid.conf configured for other non-IPS policy rules if you want to have them drop traffic.
I recommend using the IPS Policy Mode option set to "Policy". That way each IPS Policy rule will use the suggested action provided by the rule authors. Some less critcal rules or those that may frequently false positive will simply alert, and the more important/bad stuff will drop.
Bill
-
Thank you Bill, for your answers, time and effort.
There is lots of misleading information out there, I'm glad you took the time to clarify most of my newbie questions.
Looking forward to new features on upcoming releases of suricata.
Thanks again.
-
Hi,
great topic guys. May I ask where is the IPS Policy Mode setting in the GUI?
I use Suricata Inline 3.1.2_2.Thanks
mind12 -
services / suricata / interfaces
edit an interface (the setting can be changed for every interface)
tab xxx Categories (replace xxx with the inteface name)
section Snort IPS Policy selectionsee screenshot
-
services / suricata / interfaces
edit an interface (the setting can be changed for every interface)
tab xxx Categories (replace xxx with the inteface name)
section Snort IPS Policy selectionsee screenshot
Thank you for your quick answer. I found it and changed it to Policy immediately. ;)
-
Just a quick note about the IPS Policy Mode option: it will only appear when using Inline IPS Mode and when the VRT IPS Policy option is enabled. The option is hidden when using Legacy Mode on the interface because there is no ability to distinguish between "alert" or "drop" in Legacy Mode. Furthermore, the option will target only Snort VRT IPS Policy rules. The Snort VRT rules have extra metadata in them that tags a rule as belonging to a particular policy set as well as providing a suggested action (drop or alert). The Emerging Threats rules lack this IPS policy metadata and thus can't be managed using the IPS Policy options.
Bill
