Suricata true inline IPS mode coming with pfSense 2.3 – here is a preview
-
I can only hope that PFsense 2.4 will have a working Suricata IPS. Waiting a long time for this feature.
What's the problem with this version? My virtual machine setup is working fine in bridged mode with inline Suricata configuration.
-
Crashes the NIC's for me with 2.3.2. I have 5 igb interfaces. If I enable inline IPS, PDFsense freezes. Now, I have setup another box with the same NIC's using 2.4 dev version and that is working so far. Problem with that version is there is no pass list feature so Suricata is useless in production.
-
Would someone be willing to help me with the rules?
i would like to use inline mode and from my understanding i can add the rules to dropsid in this manner:# PCRE IPS Policy DROPS |
–---------------
pcre:pcre:security-ips\s*drop
Category DROPS
GPLv2_community
emerging-scan
emerging-activex
emerging-attack_response
emerging-botcc.portgrouped
emerging-botccs
emerging-chat
emerging-ciarmyNow from my understanding this will replace "alert" in front with "drop" ? My question is how can I take the bistream:noalert lines and make them stay as "alert" instead of "drop" ? I am used to the legacy mode with pcap where I can load the rules so these changes are a bit overwhelming for user like me. Any help would be really appreciated, thanks!
-
Crashes the NIC's for me with 2.3.2. I have 5 igb interfaces. If I enable inline IPS, PDFsense freezes. Now, I have setup another box with the same NIC's using 2.4 dev version and that is working so far. Problem with that version is there is no pass list feature so Suricata is useless in production.
You must use IP REPUTATION at the moment to implement a pass list (whitelisting) feature with inline mode. This is because the way blocking works is fundamentally different with inline mode. The Legacy Mode of Suricata (which by the way is the same technology Snort is using) works off of a custom alert plugin I wrote for the Suricata binary called alert_pf. That plugin gets a copy of every single Suricata alert and inserts the offender's IP address from the alert data into the snort2c table in the pf engine in pfSense. During this process the custom alert module checks the IP address against an in-memory pass list and skips inserting the IP into the snort2c table for any addresses on the pass list.
Inline mode, on the other hand, uses no custom code at all. It instead uses the new native netmap interface feature within Suricata. When you use inline IPS mode, my custom module and its pass list functionality are never even loaded and activated by the Suricata binary. That entire chain is not present, thus the pass list can't work. Even if the chain were loaded, it would not matter because the netmap mode stuff happens before the custom module ever sees the alert packet.
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.
Oh…and the crashing problem is almost certainly due to issues with specific NIC drivers and netmap. It is also true that the first couple of releases of Suricata with the netmap inline mode had some internal problems on FreeBSD. The folks on the Suricata side worked those out in subsequent releases. One or more of those bugs could be biting you if you are using the 3.0.x Suricata binary. The 3.1.2 version of Suricata (that's the binary version) that is available with the pfSense 2.4-BETA snapshots has all of those netmap fixes.
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
-
Would someone be willing to help me with the rules?
i would like to use inline mode and from my understanding i can add the rules to dropsid in this manner:# PCRE IPS Policy DROPS |
–---------------
pcre:pcre:security-ips\s*drop
Category DROPS
GPLv2_community
emerging-scan
emerging-activex
emerging-attack_response
emerging-botcc.portgrouped
emerging-botccs
emerging-chat
emerging-ciarmyNow from my understanding this will replace "alert" in front with "drop" ? My question is how can I take the bistream:noalert lines and make them stay as "alert" instead of "drop" ? I am used to the legacy mode with pcap where I can load the rules so these changes are a bit overwhelming for user like me. Any help would be really appreciated, thanks!
I don't fully understand your question about "bistream:noalert". Are you saying that phrase in those rules is getting changed to "bistream:drop"? That should not be happening.
Bill
-
Would someone be willing to help me with the rules?
i would like to use inline mode and from my understanding i can add the rules to dropsid in this manner:# PCRE IPS Policy DROPS |
–---------------
pcre:pcre:security-ips\s*drop
Category DROPS
GPLv2_community
emerging-scan
emerging-activex
emerging-attack_response
emerging-botcc.portgrouped
emerging-botccs
emerging-chat
emerging-ciarmyNow from my understanding this will replace "alert" in front with "drop" ? My question is how can I take the bistream:noalert lines and make them stay as "alert" instead of "drop" ? I am used to the legacy mode with pcap where I can load the rules so these changes are a bit overwhelming for user like me. Any help would be really appreciated, thanks!
I don't fully understand your question about "bistream:noalert". Are you saying that phrase in those rules is getting changed to "bistream:drop"? That should not be happening.
Bill
I am trying to add all those lists to be dropped but I do not want every rule inside to be dropped.
example:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET ACTIVEX winhlp32 ActiveX control attack, phase 1"; flowbits:noalert; flow: to_client,established; file_data; content:"|3C|OBJECT"; nocase; distance:0; content:"application/x-oleobject"; nocase; within: 64; content:"codebase="; nocase; distance:0; content:"hhctrl.ocx"; nocase; within:15; flowbits:set,winhlp32; reference:url,doc.emergingthreats.net/bin/view/Main/2001622; classtype:web-application-attack; sid:2001622; rev:14; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, tag ActiveX, signature_severity Major, created_at 2010_07_30, updated_at 2016_07_01;)I would not want this rule to be changed to drop I would want to keep it as alert, would I need to manually select every rule like this from all the lists and add them to modify? I hope this makes more sense, sorry if it does not, I've been asking for help in various places and trying to research but I have not been able to figure it all out. Best advice I received was to manually edit the files from "alert" to "drop" and keep the "bitstream:noalert" as "alert" and not "drop", but this would be ridiculous amount of work that becomes null when an updated list comes out. (I'm not capable of making a complex script to do all the editing"
-
Would someone be willing to help me with the rules?
i would like to use inline mode and from my understanding i can add the rules to dropsid in this manner:# PCRE IPS Policy DROPS |
–---------------
pcre:pcre:security-ips\s*drop
Category DROPS
GPLv2_community
emerging-scan
emerging-activex
emerging-attack_response
emerging-botcc.portgrouped
emerging-botccs
emerging-chat
emerging-ciarmyNow from my understanding this will replace "alert" in front with "drop" ? My question is how can I take the bistream:noalert lines and make them stay as "alert" instead of "drop" ? I am used to the legacy mode with pcap where I can load the rules so these changes are a bit overwhelming for user like me. Any help would be really appreciated, thanks!
I don't fully understand your question about "bistream:noalert". Are you saying that phrase in those rules is getting changed to "bistream:drop"? That should not be happening.
Bill
I am trying to add all those lists to be dropped but I do not want every rule inside to be dropped.
example:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET ACTIVEX winhlp32 ActiveX control attack, phase 1"; flowbits:noalert; flow: to_client,established; file_data; content:"|3C|OBJECT"; nocase; distance:0; content:"application/x-oleobject"; nocase; within: 64; content:"codebase="; nocase; distance:0; content:"hhctrl.ocx"; nocase; within:15; flowbits:set,winhlp32; reference:url,doc.emergingthreats.net/bin/view/Main/2001622; classtype:web-application-attack; sid:2001622; rev:14; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, tag ActiveX, signature_severity Major, created_at 2010_07_30, updated_at 2016_07_01;)I would not want this rule to be changed to drop I would want to keep it as alert, would I need to manually select every rule like this from all the lists and add them to modify? I hope this makes more sense, sorry if it does not, I've been asking for help in various places and trying to research but I have not been able to figure it all out. Best advice I received was to manually edit the files from "alert" to "drop" and keep the "bitstream:noalert" as "alert" and not "drop", but this would be ridiculous amount of work that becomes null when an updated list comes out. (I'm not capable of making a complex script to do all the editing"
OK, I think I understand now. At the moment there is no way to do this within the GUI, but I just added some new functionality in an update I made this weekend. That update pull request is posted now for the pfSense developers to review and merge. The new functionality allows you to force individual SIDs to always be Alert (or always be Drop). Here is a link to that thread: https://forum.pfsense.org/index.php?topic=123976.msg684653#msg684653.
Bill
-
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 i340Do you have any idease how to solve this issue?
-
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?
-
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.
-
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.
-
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" -
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
-
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.
-
well…i have nothing there...yet.
btw is there a recommanded setup (based on a hardware table) for the Detection Engine settings? -
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*dropNext, 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*dropBill -
already started to see activities in logs.
thank you -
already started to see activities in logs.
thank youYou 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
-
[
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..
-
[
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
