Suricata true inline IPS mode coming with pfSense 2.3 – here is a preview

padpn

Hello!

After enabling suricata in Inline mode it drop all outgoing traffic on interface.

I'm runnung pfSense 2.3.3-RELEASE-p1 and suricata 3.1.2_2
My ethernet adapter is intel i340

Do you have any idease how to solve this issue?

pfBasic

Good question, as that is a supported NIC:

netmap natively supports the following devices:

On FreeBSD: em(4), igb(4), ixgbe(4), lem(4), re(4).

The igb driver provides support for PCI Express Gigabit Ethernet adapters
based on the Intel 82575, 82576, 82580, i21x and i35x Ethernet controller
chips.

So long as you are using pfSense 2.3+ & have the latest update applied to suricata, this should be working. But it didn't for me either on a PRO/1000.

I have the same NIC so would be interested in hearing the answer to this as well.

I previously had a PRO/1000 (also supported) and had the same issue in inline mode.

Inline seems pretty flaky right now, but maybe this is just a user error thing that could be fixed?

werkkrew

Just wanted to also report that on pfSense 2.3.3-RELEASE-p1 with Suricata 3.1.2_2 on an Intel 82571EB Gigabit Ethernet Controller, enabling Inline IPS seems to crash the NIC.

As soon as I enable inline IPS the nic starts flapping and Unbound goes down, CPU spikes to about 80% and nothing works on the interface IPS is enabled on until I disable it.

snadsnad

Is there any way to remove a single host that has been blocked? So far I've only been able to remove blocks by restarting the interface in Suricata, which removes all hosts of course and seems a little bit much to accomplish something like this.

That being said, this looks pretty promising as I've been looking for some kind of free/open source inline IPS with a usable GUI. Thanks for putting this together.

n3by

Removing a blocked host it is very easy:
Suricata - Alerts: at host IP is a little X - if you hold your mouse over X you will have a message: "Remove host from Blocked Table"
Suricata - Blocked Hosts at Remove colomn X "Delete host from Blocked Table"

nikkon

Hi all,

I just switched from legacy mode to Inline mode and aparently nothing happens.
interface is an intel 82574L Gigabit Network Connection
i got no alerts or blocs and nothing in logs.
It might be something wrong set in the SID Mgmt. is there any step by step how to for the inline mode setup?
dropsid.conf has onnly 2 lines:

Category DROPS

emerging-scan

# PCRE IPS Policy DROPS |

–---------------

pcre:pcre:security-ips\s*drop

Thanks

pfBasic

@nikkon:

Hi all,

I just switched from legacy mode to Inline mode and aparently nothing happens.
interface is an intel 82574L Gigabit Network Connection
i got no alerts or blocs and nothing in logs.
It might be something wrong set in the SID Mgmt. is there any step by step how to for the inline mode setup?
dropsid.conf has onnly 2 lines:

Category DROPS

emerging-scan

# PCRE IPS Policy DROPS |

–---------------

pcre:pcre:security-ips\s*drop

Thanks

It looks like you got inline mine working as it should. Alerts will show up in firewall logs now. You don't have a block list or use the snort2c table anymore.

nikkon

well…i have nothing there...yet.
btw is there a recommanded setup (based on a hardware table) for the Detection Engine settings?

bmeeks

@nikkon:

Hi all,

I just switched from legacy mode to Inline mode and aparently nothing happens.
interface is an intel 82574L Gigabit Network Connection
i got no alerts or blocs and nothing in logs.
It might be something wrong set in the SID Mgmt. is there any step by step how to for the inline mode setup?
dropsid.conf has onnly 2 lines:

Category DROPS

emerging-scan

# PCRE IPS Policy DROPS |

–---------------

pcre:pcre:security-ips\s*drop

Thanks

First, remove this entire line from your dropsid.conf and save the change –


pcre:pcre:security-ips\s*drop

Next, go to the CATEGORIES tab and select either the Snort VRT IPS Policy "Connectivity" or "Balanced" (this assumes you have an Oinkmaster code and have the Snort VRT rules enabled). In the same page section where you select the IPS policy, change the IPS Policy Mode drop-down to say "Policy". Save the change.

Finally, restart Suricata on the interface.

By choosing an IPS Policy and setting the IPS Policy Mode to "Policy", two useful things occur for beginners.

(1) a set of Snort VRT rules is automatically selected for you based on the chosen policy
(2) the action for those rules is set according to the recommendation in the metadata published with each VRT rule. Most will be DROP, but some will be ALERT.

If you don't have an active Oinkmaster code and don't have the Snort rules download enabled, then the line```
pcre:pcre:security-ips\s*drop


Bill

nikkon

already started to see activities in logs.
thank you

bmeeks

@nikkon:

already started to see activities in logs.
thank you

You are welcome. I suggest using "Connectivity" initially and then moving over to "Balanced". It is your call, though. The "Connectivity" policy protects from most of the really bad stuff and is the least likely policy to generate false positives. False positives are benign traffic that just happens to either match, or gets mis-identified as matching, malicious traffic. "Balanced" will protect from more stuff, but it is more prone to false positives. "Security" protects from darn near everything, but does so at the expense of a significant increase in false positives. Researching false positive alerts and identifying and suppressing the alerts from those rules is a tedious job for an IDS/IPS admin. I personally run "Balanced" on my home firewall, but I started with "Connectivity" to protect me while I gained experience with using an IDS/IPS and seeing what kinds of alerts happened in my environment.

Bill

occamsrazor

@bmeeks:

[
You are welcome. I suggest using "Connectivity" initially and then moving over to "Balanced". It is your call, though. The "Connectivity" policy protects from most of the really bad stuff and is the least likely policy to generate false positives. False positives are benign traffic that just happens to either match, or gets mis-identified as matching, malicious traffic. "Balanced" will protect from more stuff, but it is more prone to false positives. "Security" protects from darn near everything, but does so at the expense of a significant increase in false positives. Researching false positive alerts and identifying and suppressing the alerts from those rules is a tedious job for an IDS/IPS admin. I personally run "Balanced" on my home firewall, but I started with "Connectivity" to protect me while I gained experience with using an IDS/IPS and seeing what kinds of alerts happened in my environment.

Bill
[/quote]

This only applies to the Snort VRT rules… right? Am I right in saying there is no "automatic" way to limit false positives and control the ETOpen rules (except totally manually)? I'm a newbie, thanks..

bmeeks

@occamsrazor:

@bmeeks:

[
You are welcome. I suggest using "Connectivity" initially and then moving over to "Balanced". It is your call, though. The "Connectivity" policy protects from most of the really bad stuff and is the least likely policy to generate false positives. False positives are benign traffic that just happens to either match, or gets mis-identified as matching, malicious traffic. "Balanced" will protect from more stuff, but it is more prone to false positives. "Security" protects from darn near everything, but does so at the expense of a significant increase in false positives. Researching false positive alerts and identifying and suppressing the alerts from those rules is a tedious job for an IDS/IPS admin. I personally run "Balanced" on my home firewall, but I started with "Connectivity" to protect me while I gained experience with using an IDS/IPS and seeing what kinds of alerts happened in my environment.

Bill
[/quote]

This only applies to the Snort VRT rules… right? Am I right in saying there is no "automatic" way to limit false positives and control the ETOpen rules (except totally manually)? I'm a newbie, thanks..

Correct. The Emerging Threats rules do not contain the policy metadata tagging that the Snort VRT rules do. So that means you can't select a "policy" for auto-selection of rules when using Emerging Threats. Only the Snort VRT rules can be used with a policy.

And for the sake of noobs that may be looking at this thread –

The "IPS Policy" I keep talking about is not created by the GUI of pfSense. That is something that is actually added to the rule signatures by the rule authors. Currently only the Snort VRT (Vulnerability Research Team) does this. They literally add some extra text and keywords into their signatures that identify which of the three standard IPS policies the rules are to be associated with. A given rule can have metadata strings associating it with one, two or all three IPS policies. In addition, the suggested rule action (ALERT or DROP) can be different for the policy choices. For example, a given rule may "alert" when used in the "Connectivity" policy but "drop" when used in the "Security" policy. Which policy action is recommended by the rule authors is governed by the frequency of false positives (or the potential of them). So all the pfSense GUI code for Suricata (or Snort) does is search the VRT rules to find all having a policy metadata string matching the IPS policy chosen (security, balanced or connectivity).

Bill

nikkon

thx for the hint bmeeks
I was using the Balanced option so far.

Previously I saw that dropsid.conf can be easily customized. I assume we can add drops based on categories(Ruleset: ET Open Rules). Is there a recommended list? I use those now:

btw : my question still remains: How much can i push the Max Pending Packets value keeping in mind i only have 8Gb Ram and without impacting overall performance?
now I use 3072 and ram usage is @ 40% of 8130 MiB

Thanks

newyork10023

Paraphrasing, you wrote:

You must use IP REPUTATION at the moment to implement a pass list (whitelisting) feature with inline mode.

Suricata does have an IP Reputation module, and that feature is exposed in the GUI package for pfSense. You will need to manually create a "whitelist" of IP addresses you want to never block and add that list to the IP REP tab. There are options on that tab for how to treat the list you create (whitelist or blacklist). You can also create custom PASS rules and use those if you are fluent in writing Suricata rules. That's the best I can offer at the moment.

I will look into how easy it might be to automate that process and somewhat integrate it into the existing Pass List code used in Legacy Mode.

EDIT: scratch part of what I said about using IP REPUTATION. That will only work on Snort. Sorry I confused the two in my head when posting originally. The only solution I can see to implement a Pass List with Suricata using inline IPS mode is to implement PASS rules. I believe I can make that automatically happen within the GUI code. I'm working on a solution to include in an upcoming package update. -Bill

I would like to point out the following.

1) I can find no detailed explanation in the documentation on either the pfSense or the Suricata websites as to how to use the IP Reputation list feature. The syntax is outlined, but not how to use IP Reputation in a rule to achieve any purpose. In any event, although repeatedly told this is required to "whitelist" addresses that would otherwise be dropped by a rule, we are now told this won't work at all.

2) My understanding from my reading of what there is to learn about IP Reputation (or is it Pass lists?) lists, any Aliases used can't include FQDN. This is a very serious limitation.

3) It is unclear whether the use of Suppress lists will "whilelist" an address that is dropped by a rule. My testing would seem to indicate that Suppress simply prevents the Alert logging while the address is still blocked due to the rule.

4) It is unclear whether Suricata in IPS mode blocks addresses for a period of time as specified in Services -> Suricata -> Global Settings -> General Settings –>Remove Blocked Hosts Interval or if the block is only for the specific (instantaneous) traffic only. At issue is that, without the Block list page, and with the Alert page continuing to fill, it is no easy feat to find what traffic has been blocked-- let alone take any action to prevent it in the future.

5) We are told using Pass lists won't work either.

6) In an explanation of the Enable/Disable vs Disable/Enable toggle with SID Management, you wrote, "The logic excludes based on the largest net. So if you disable a category by putting it in the disablesid.conf file, then none of that category's rules can be used. Enabling individual SIDs from an excluded category in the enablesid.conf file is not possible (because the whole category has been excluded). It would be better to use SID ranges from the category in the two files and work out a solution that way. The biggest "excluding" statement wins between the two files (enablesid and disablesid)." Is this explanation right? I'm sorry, but the list of rules is chosen based on a vote of who gets the most votes? (Do the Russians get to "vote" as well?) Surely, if the order is Disable/Enable, and you disable a category then enable a particular rule in the category, that rule is enabled, no?!

You conclude (after correcting the longstanding misinformation that IP Reputation lists, which are undocumented anyway, are the only supported/possible way to not drop traffic otherwise dropped by a rule) only "those ... fluent in writing Suricata rules" will have any means to solve the issue ("That's the best I can offer at the moment"). You go on to write, "The only solution I can see to implement a Pass List with Suricata using inline IPS mode is to implement PASS rules. I believe I can make that automatically happen within the GUI code. I'm working on a solution to include in an upcoming package update."

That was January 13, 2017, 08:18:29 am.

Do we have a solution for those of us who are not "fluent in writing Suricata rules"? Could you clarify the current state of affairs with respect to Suppress lists, Pass Lists, SID Management Enable/Disable ordering, IP Reputation lists and any GUI implementation of "Pass List" functionality.

Thank you.

EDIT: I must assume I am now "fluent in writing Suricata rules", as I have solved the issue (in a simple case). Using SID Management with Modify rules, I was able to modify a rule's Destination to exclude a sequence of IP addresses. I was temporarily setback by the examples in the Suricata documentation which included spaces between the addresses (when creating Aliases), but, at least with rules, there can be no spaces. ESET Cyber Security Pro can now send "Outgoing Basic Auth Base64 HTTP Password detected unencrypted" to its update servers unhindered.

newyork10023

If I may request (some) feature(s):

– on the Suricata -> Interfaces -> select to edit (e.g., WAN) -> WAN Rules page, the footer "Category Rules Summary" would be nice to (also) have available to view at the top of the page

-- that the "Rules View Filter" section always be open (or that the option to always be open can be configured)

-- that selection boxes be available for all the various SID Management categories (i.e., Default Enabled, Enabled by user, Auto-enabled by SID Mgmt, Rule action is alert. Action and/or content modified by SID Mgmt, Default Disabled, Disabled by user, Auto-disabled by SID Mgmt, and Rule action is drop).

-- that the columns on the page be sortable by clicking on the header.

-- that a Category "ALL" be available to see ALL rules and their actions.

-- that Source and Destination be Editable fields to solve the previously mentioned issue with "whitelisting". If implemented, thorough documentation/help/how to information be available right there for those of us who are not Suricata rule experts but need rules to work nonetheless. Clearly, the original rule needs to be maintained, with custom edits that can be saved and reused, including aliases and their logic (i.e., NOT/AND/OR).

-- that clicking on a SID to view rule show both the original and active rule (and not as a javascript pop-up).

Easier navigation in the Suricata menus would be appreciated: the requirement to choose Edit on the Interface, so that all pages within can be viewed up front needs to be eliminated and all pages flattened so they can be viewed initially.

In the Suricata menus (and in pfSense itself) it would be helpful to have an easy way to move between frequently accessed pages. For example, a Start Page with Icons to open frequently used pages either below the Icons in a frame (keeping the Icons available) or in a separate tab (such that if re-clicking on the Start Page icon will re-open the existing tabbed page). Even just having Icons on every page with links to open (in an existing tab if possible) frequently accessed pages (e.g., Dashboard, the various pages of Logs, Interface pages, Rules pages, etc., etc.

newyork10023

Last question, it appears that Snort is still not capable of inline mode (with pfSense), true?

Uranus

Good day.
PFsenes 2.3.4-RELEASE-p1 (amd64) FreeBSD 10.3-RELEASE-p19
I have a I350-T4 network card installed.
As I understand the drivers for this network card do not support a Netmap (At least in the current release PFsense), because when switch to the inline mode, I stop showing alerts?!
Sorry for my bad english.

bmeeks

@newyork10023:

Last question, it appears that Snort is still not capable of inline mode (with pfSense), true?

Correct, Snort cannot do inline IPS mode on pfSense. Snort implements Netmap, but only through its DAQ module. And the way DAQ implements it is quite different from the way Suricata does. Snort's DAQ requires you to actually dedicate two real network interfaces to the Netmap tunnel. One is "IN" and the other is "OUT". The DAQ takes incoming traffic on the IN and sends it to Snort. Snort either drops it if bad, or sends it back to DAQ if OK. DAQ then sends what it gets from Snort out the OUT interface. It is meant to really run as a completely separate appliance sitting in series with the protected networks. You can't route any traffic between the interfaces either. They are just two ends of the same pipe in a manner of speaking.

Suricata implements Netmap natively (without needing DAQ), and does so in a manner more conducive to IPS mode operation within a firewall. You don't have to use two real interfaces. You specify the real interface where you want Netmap to operate, and then to connect to the OS kernel stack you specify the same interface name but with a plus ("+") at the end. Suricata's Netmap can insert itself between the kernel stack and the NIC driver. Snort's DAQ can't do this.

Bill

bmeeks

@Uranus:

Good day.
PFsenes 2.3.4-RELEASE-p1 (amd64) FreeBSD 10.3-RELEASE-p19
I have a I350-T4 network card installed.
As I understand the drivers for this network card do not support a Netmap (At least in the current release PFsense), because when switch to the inline mode, I stop showing alerts?!
Sorry for my bad english.

Probably true. I don't have a list of exactly which drivers fully support Netmap. I know there are several out there that work great, and some that work in a buggy fashion, and then some that don't work at all. If you have trouble with Inline IPS mode in Suricata with your NIC hardware, you either have to change the NIC to one that is supported or switch to Legacy Mode blocking and abandon Inline IPS.

You could try posting an open question to Suricata users here on the forum to see who is successfully using Inline IPS mode and with which type of network card.

Bill