Suricata true inline IPS mode coming with pfSense 2.3 – here is a preview
-
Not the first time I have seen that reply about a SIEM… one has nothing to do with the other. Wanting Suricata working in inline mode on my firewall is completely unrelated to a SIEM and is definitely not relegated to "toy" status in the absense of a SIEM. I'd love to have a serious discussion (off of the forum if necessary to reduce clutter) about this as I am not trying to throw rocks or start a flame war. I just don't grok the relationship between running Suricata in inline mode and having or not having a SIEM.
-
Lately, when I ask for status on Inline Suricata, the thread gets deleted. What's up with that? I thought this was a community forum.
I will attempt more questions
Is it in testing?
Yes, of course. https://forum.pfsense.org/index.php?topic=118541.msg656395#msg656395
How is the testing going?
Are you helping?
What are the issues?
Take a look in that thread, or the FreeBSD bug tracker, below. There are a number of reasons why this software hasn't merged into FreeBSD as yet.
Why is PFsense so far behind in Suricata updates?
So far behind what?
Suricata 3.1.2 was released on 7 September: https://suricata-ids.org/2016/09/07/suricata-3-1-2-released/
At the moment 3.1.1 and Hyperscan are still pending in the FreeBSD bug tracker.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490As is Suricata 3.1.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212815As you can see by looking at that, Herr Fitchitis is hard at work to make both happen. Given this, I don't see how any additional effort on our part would make it happen any sooner.
How many people are working on it?
Which part?
Are you helping?Do you need testers, or help?
We always need testers. Thank you.
Is there an ETA?
No.
Should I move on?
You're welcome to stay and you're welcome to contribute.
As with most things, this is your choice, not mine.
-
Not the first time I have seen that reply about a SIEM… one has nothing to do with the other. Wanting Suricata working in inline mode on my firewall is completely unrelated to a SIEM and is definitely not relegated to "toy" status in the absense of a SIEM. I'd love to have a serious discussion (off of the forum if necessary to reduce clutter) about this as I am not trying to throw rocks or start a flame war. I just don't grok the relationship between running Suricata in inline mode and having or not having a SIEM.
An IPS responds to known threats. IDS has a different task set. It must identify a large number of threats, including:
Security policy violations, such as systems or users who are running applications against policy.
Infections, such as viruses or Trojan horses that have partial or full control of internal systems, using them to spread infection and attack other systems.
Information leakage, such as systems running spyware and key loggers, as well as accidental information leakage by valid users.
Configuration errors, such as applications or systems with incorrect security settings or performance-killing network misconfiguration, as well as misconfigured firewalls where the rule set does not match policy.
Unauthorized clients and servers including network-threatening server applications such as DHCP or DNS service, along with unauthorized applications such as network scanning tools or unsecured remote desktop.
Doing these without an SIEM is nearly impossible.
-
Right! These are two different tasks. I'm not interested in my firewall telling me all this stuff, at least not my Internet facing firewall. I want it to guard my perimeter and drop bad traffic, but not interfere with my users' legitimate connectivity. Hence, I want Suricata to run as an IPS on my external firewall, preferrably without the pain of unintentionally blocking valid sites and traffic because of a mangled packet somewhere.
I am exploring internal sensors and SIEM solutions, potentially using Suricata, wherein I will look for all those other things, but the lack of this capability does not lessen the effectiveness of my perimeter firewall.
They perform two distinct tasks.
Any further debate can move to another thread or offline, I don't want to take this thread off the rails.
Thanks for the input, I do like it whether I agree with all of it or not! :)
-
Thanks jwt, glad to see some activity here. That's all I asked for.
As for helping, I am willing to do what I can but not sure how to go about it. I am not a coder so I can't help there, but I have many different platforms here to test on. Every time I test inline IPS, I do post my results. Maybe I am doing that in the wrong place.
OK 3.1.2 Suricata is in FreeBSD bug tracking phase. Just noticed a new release to 3.0.9. Will try that one soon. I am not even sure Suricata is the reason for inline IPS not working, may be netmap, or something else.
But one question remains. Where can I look at testing results from using Inline IPS. I saw one report and it froze their system. That's essentially what happened every time I tried it. Does anyone have it working, even partially?
I agree with dhboyd26 SIEM is just another device which just collects security data. Not sure how that applies here. I already know where my problems are.
In my opinion true inline IPS turns PFsense from a 'toy' to a full blown security appliance. That's why I am surprised as to its priority. It seems to be working with other firewall software using FreeBSD and Suricata.
Here is the #1 reason I need this, there are others. I run multiple mail servers and receive constant hits from spammers that change their IP with every hit. Snort catches these but the first one always passes, then the spammer sends the same email with a different IP seconds after the previous one and snort sees it as a new hit. This happens thousands of times a day filling logs and using bandwidth. My spam detection system is almost constantly checking and blocking these, but in doing so takes much time going through all the checks. I need a way to block these before they get to the spam engine. Inline IPS would do this using my custom rules. You would think these spammers would run out of IP's, but apparently not. If anyone has any ideas or other ways to prevent these multiple IP spams, please let me know. Pfblocker is not a solution because these all come from within allowed countries.
I had a thread which stated this problem before and the answer was to use Inline IPS. I have been waiting for it ever since. That was over six months ago when this thread started.
-
Here is the #1 reason I need this, there are others. I run multiple mail servers and receive constant hits from spammers that change their IP with every hit. Snort catches these but the first one always passes, then the spammer sends the same email with a different IP seconds after the previous one and snort sees it as a new hit. This happens thousands of times a day filling logs and using bandwidth. My spam detection system is almost constantly checking and blocking these, but in doing so takes much time going through all the checks. I need a way to block these before they get to the spam engine. Inline IPS would do this using my custom rules. You would think these spammers would run out of IP's, but apparently not. If anyone has any ideas or other ways to prevent these multiple IP spams, please let me know.
Pfblocker is not a solution because these all come from within allowed countries.
Hi dcol,
What Snort rules were reporting on these spam attacks? Maybe those rules can be modified to be more effective…
You best mitigation against spam is to have the mail server use DNSRBLs like Spamhaus Zen… That one service alone will block 90% of your spam...
https://www.spamhaus.org/
There are several others that can be added, depending on what Mail Server you use...
pfBlockerNG, is more than a GeoIP blocker.. You can add other Mail specific Blocklists to help reduce spam...
-
I already use Xeams, which is an incredible spam blocker. I don't have an issue with blocking, my issue is bandwidth. By the time all the spam checks are done, a lot of time is wasted. I want to block these at the source, before they get to the spam engine.
Here is an example of one of my snort rules. This one blocks a spammer TLD.
alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP .top Bad TLD"; threshold: type limit, track by_src, count 1, seconds 60; content:".top>"; nocase; classtype:unsuccessful-user; sid:9000031; rev:2;)Maybe change the alert to drop? Problem with that is the packets have already passed to the spam engine. Drop is useless without Inline IPS because the spammer is already in the system.
I am not an expert, so if anyone knows how to block a TLD from getting to the email server, I am all ears. Tried PFblocker and that doesn't detect the TLD at all. Not sure it would drop the connection anyway.
-
No answer to my question?
Seems no one has any other way to do this. That's why we need Inline IPS. IMO Pfsense is not a complete firewall until it can block all unwanted traffic before it gets to your server. -
How to donate suricata with pfSense?
Maybe it helps …
-
3.1.2 has hit freshports.
https://www.freshports.org/security/suricata
I assume with pfsense 2.4 ramping up we will get something once it's final and we can hope 3.2 is out on freshports and have that instead :)
-
I can only hope that PFsense 2.4 will have a working Suricata IPS. Waiting a long time for this feature.
-
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?
