Suricata true inline IPS mode coming with pfSense 2.3 – here is a preview
-
Here are some alerts (drops) I generated by using the dropsid.conf file described above on a test machine and then scanning the machine with nmap. The dropsid file altered all of the Emerging-Scan rules to be DROP instead of ALERT. The nmap scan I used caused hits on both the ET-Scan and ET-Policy rules. Only the ET-Scan rules were configured to drop. Those are shown in red by the new IPS mode. So the red rules resulted in blocked traffic while the other rules just produced alerts without blocking the traffic.
In the following screenshots the 192.168.10.12 address was my Kali Linux malicious scanner (running nmap scans) and 192.168.10.118 was the pfSense 2.3-BETA virtual machine I was scanning.
Bill
-
You can also filter the ALERTS tab and show only the alerts that resulted in packet drops. Here is a screenshot of the ALERTS tab filtering for just the DROPs.
Bill
-
The new Suricata package should be out soon. Remember, though, that it will only be available for pfSense 2.3 and newer. I welcome any feedback or suggestions for improvement.
Bill
-
Very good news. Cant wait !
+1
F.
-
The pull request has been posted for review and approval. Here is the link: https://github.com/pfsense/FreeBSD-ports/pull/76
Bill
-
Hi bmeeks,
About Logs View, I can view alerts.log,http.log and suricata.log, but others disappear. I have wrong setting?
-
Hi bmeeks,
About Logs View, I can view alerts.log,http.log and suricata.log, but others disappear. I have wrong setting?
You can only view logs which have been specifically enabled on the INTERFACE SETTINGS tab for the interface. The alerts.log and http.log are enabled by default unless the user unchecks them on that page. The suricata.log is the "system log" for the Suricata binary, so it is always populated.
To see data in the other choices on the LOGS VIEW tab you must enable the log on the INTERFACE SETTINGS tab. Most are disabled by default because they generate a lot of text and can really chew up disk space on busy networks.
Bill
-
Hi,
I enable SID File, add emerging-scan, But interface categories show emerging-shellcode.rules (auto-enabled by SID Mgmt conf files).
-
Hi,
I enable SID File, add emerging-scan, But interface categories show emerging-shellcode.rules (auto-enabled by SID Mgmt conf files).
I will check on this. I am working on a bug fix release now. There are still some GUI issues left over from the Bootstrap conversion.
Update: I checked and found that I got this part of the code wrong with the new dropsid functionality. Working on the fix and will post an updated package soon.
Bill
-
Because I don't know relationship between categories and SID Mgmt, so I made a test. If I enable emerging-scan.rules from categories, use "Disable SID File" for A sid, then use "Drop SID File" for A sid, I found alerts dropped include A sid, so it means "Drop SID File" override categories and other sid file setting, right?
If I add emerging-scan to "Drop SID File", all emerging-scan traffic (include default disable from categories) dropped. That's right?
Thanks!
-
awesome work bmeeks. i think this is a very important enhancement for the overall pfsense project.
i think that it would be nice if it were possible to configure the action alert/drop directly in the "Rules" section. -
Because I don't know relationship between categories and SID Mgmt, so I made a test. If I enable emerging-scan.rules from categories, use "Disable SID File" for A sid, then use "Drop SID File" for A sid, I found alerts dropped include A sid, so it means "Drop SID File" override categories and other sid file setting, right?
If I add emerging-scan to "Drop SID File", all emerging-scan traffic (include default disable from categories) dropped. That's right?
Thanks!
The behavior you document is the result of errors in the way I implemented the logic. A fix is coming. See the full explanation below.
When I looked into the new "Drop SID" stuff I realized that in the rush to get it completed I had not thoroughly thought through all the logic. I found several issues. I have them fixed in the patch I'm working on now. Should be posting it in a day or two at the latest. I have one more thing with XMLRPC Sync I may try and sneak in. If that fix is going to take too long, then I will post what I've fixed so far.
Here is how the "Drop SID" logic will work in the corrected version coming out soon. Understanding the sequence of events for the whole SID management piece will help. I also hope describing the logic here will help others check my thought process.
1. First the two enablesid and disablesid files are processed. The order in which these are processed (in other words, which is run first) is set on the SID MGMT tab in a drop-down for the interface. These two files choose the rules that will be used. There are a number of ways to include rules in the enforcing set: (a) by giving category names, (b) by using SID numbers or ranges and
using PCRE to select matching rules.2. Next the modifysid and dropsid files are processed. They are fed the collection of rules selected in the first step by the enablesid and disablesid files. The modifysid file will alter the actual contents of the rule using PCRE. The dropsid file will change the rule action from whatever it is to DROP for rules that the terms in the dropsid file match in the enabled rules list. Neither the modifysid nor the dropsid files will change the state (enabled or disabled) for any rules! This is key to remember. All dropsid selectors will do is change the rule action keyword. It won't "turn on" nor "turn off" the rule.
All of the activity above happens on an in-memory array that is constructed as the configuration for an interface is being generated. At the end of the process, all enabled rules with any modifysid and dropsid modifications are written to a file called suricata.rules in the application sub-directory for the specific interface. That suricata.rules file, along with the custom.rules and flowbit-required.rules files, contains the active rule set to be used for the interface. Only enabled rules will be in those files. It makes no sense to include disabled rules there. They would just take up space for nothing (they are commented out, or disabled, anyway).
The new patch adds some additional functionality on the RULES tab to help you see what actually is in the enforcing rules. When a rule has been selected and is managed by a SID MGMT file (meaning the SID matched one of the selectors in the SID MGMT conf files), up to two icons will be shown beside the rule. If the rule was forced ON or forced OFF by SID MGMT, then an icon is shown for that state modification. If the rule's content or action keyword has been changed by SID MGMT (via modifysid or dropsid), then a second icon is shown to indicate this modification. Clicking on the SID number displayed or double-clicking on the row displaying the rule results in a Bootstrap Modal dialog opening where the modified contents of the rule are displayed. This lets you see the actual impact, in the rule, of your SID MGMT modifications.
On the CATEGORIES tab, things are pretty much like they have always been. There, one of two different icons is displayed by a Category Name when that category was either "turned on" or "turned off" by selectors in the enablesid or disablesid files on the SID MGMT tab.
Bill
-
@Giuanìn:
awesome work bmeeks. i think this is a very important enhancement for the overall pfsense project.
i think that it would be nice if it were possible to configure the action alert/drop directly in the "Rules" section.I agree that would be a nice enhancement. Let me think about how best to implement it. This change probably won't make it into the next bug fix update because I want to get that one out quickly. Thank you for the suggestion!
Bill
-
Bill,
I appreciate your detail explanation. Thanks for your help :)
-
@Giuanìn:
awesome work bmeeks. i think this is a very important enhancement for the overall pfsense project.
i think that it would be nice if it were possible to configure the action alert/drop directly in the "Rules" section.+10000
-
I have posted the pull request containing the latest bug fixes. After review by the pfSense developers, it will be merged and then show up as an update on the System > Packages > Installed Packages tab for pfSense 2.3-BETA users.
Here is a link to the pull request with a list of the fixes: https://github.com/pfsense/FreeBSD-ports/pull/84
Bill
-
Hi Bill,
I test 3.0_1, found below.
1. Enable emerging-scan.rules from categories, and disable sid A from SID Mgmt, It not show "Auto-disabled by SID Mgmt" from rules.
2. Add emerging-scan to enablesid.conf, Categories show emerging-scada.rules and emerging-scan.rules. But Add emerging-scan.rules, It correct.
3.Add emerging-scan.rules to disable.conf and enablesid.conf, Whether I use "disable,enable" or "enable,disable" to State Order, It show "Category is auto-disabled by SID Mgmt conf files".
4.IP Lists, It missing -> http://emergingthreats.net/products/iqrisk-rep-list/
5.Auto-enable rules required for checked flowbits, Default is Checked, but not checked.
Could you check it please?
-
Hi Bill,
I test 3.0_1, found below.
1. Enable emerging-scan.rules from categories, and disable sid A from SID Mgmt, It not show "Auto-disabled by SID Mgmt" from rules.
2. Add emerging-scan to enablesid.conf, Categories show emerging-scada.rules and emerging-scan.rules. But Add emerging-scan.rules, It correct.
3.Add emerging-scan.rules to disable.conf and enablesid.conf, Whether I use "disable,enable" or "enable,disable" to State Order, It show "Category is auto-disabled by SID Mgmt conf files".
4.IP Lists, It missing -> http://emergingthreats.net/products/iqrisk-rep-list/
5.Auto-enable rules required for checked flowbits, Default is Checked, but not checked.
Could you check it please?
I am looking into this. I did some testing using another set of conditions over the weekend and it seemed to work. This morning, however, I was able to reproduce your issue.
UPDATE: I found the problem with auto-management icons. It is a cosmetic display issue only, so the rules are actually being managed as defined in the SID MGMT files. I will post the fix for the display problem soon. Working on a couple of other user-reported issues as well. The IQRisk download problem is also identified and will be fixed. That one was a failure to declare a variable as global when used in a function call.
Bill
-
Look for an update soon that addresses the user-reported bugs above. The pull request is here: https://github.com/pfsense/FreeBSD-ports/pull/85.
Bill
-
I use SID State Order(disable,enable), add emerging-scan.rules to disablesid.conf and add sid A to enablesid.conf, I didn't see any enable rules. Sid A is also not in XXX/rules/suricata.rules :)
I use pcre:xxxxx, It can be selected, but use pcre:"xxxxx", It can't.
By the way, Is it possiable for drop all match rules traffic? Do you have any suggestions?
Thanks!
