SURICATA question about rules

[bmeeks]

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.rules

I 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

[jpgsense251]

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

[bmeeks]

@jpgsense251:

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

[jpgsense251]

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\sdrop

There 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…

[bmeeks]

@jpgsense251:

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\sdrop

There 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

[jpgsense251]

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.

[mind12]

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

[jpgsense251]

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 selection

see screenshot

[mind12]

@jpgsense251:

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 selection

see screenshot

Thank you for your quick answer. I found it and changed it to Policy immediately. ;)

[bmeeks]

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