Using Suricata SID Mgmt
-
Sorry for the late response. Was away from home overnight.
I will start by saying there is a distinct and important difference between a rule's State and the rule's Action. You seem to be referring to the Action. Read on for some details about State and then I will discuss Action.
Let me take a second and explain something about the rules in the various Categories available from Emerging Threats and Snort. Not all rules in every category are enabled by default. In many cases, for various reasons, some rules in a category are shipped in what we call a "default disabled" state. That means those rules are commented out by having a pound sign "#" placed at the start of the line. Rules may be default disabled for various reasons, but the most common is the rule is prone to false postives in many environments. So I wanted to first dispel any myth that when you enable a category all rules in that cateory are also enabled. That's not true. Only those rules that are not "default disabled" by the author are enabled when a category is enabled.
There may be reasons that an admin wants to enable a default disabled rule. There can certainly be legitimate reasons why a default disabled rule is needed to be enabled. So you as the admin can do that in either of two ways. You can click on the rule's State column on the RULES tab and force the rule to the enabled state. This is called user-forced enable. The GID:SID of that rule is then stored in a special section of the
config.xmlconfiguration file on your firewall (specifically within the section of that file dedicated to the Snort or Suricata package). On the other hand, an admin might want to disable a default-enabled rule. For instance, perhaps the threat the rule detects is not relevent to your network and you don't want to waste CPU and RAM resources on the rule. Perhaps that particular rule exhibits false positives in your network, so again you would want to disable it (disabling a rule prevents it from even loading into the memory). Again, as with user-forced enable, you can user-forced disable a rule in the same manner using the icon under the State column on the RULES tab. The SID MGMT tab offers that regex matching feature I described earlier to make it possible to select large groups of rules, or just a single rule, or just two or three rules and change the state from enabled to disabled, or from disabled to enabled.Now let's talk about a rule's Action. This is the verb at the front of the rule text. It is always, by default, ALERT. Other possible actions are PASS, DROP, or REJECT. When using Suricata's Legacy Mode with "Block Drops Only" unchecked, then every alert causes a block of traffic for the hosts pulled from the alert. When using Legacy Mode with "Block Drops Only" checked, then you have to manually change a rule's action verb from ALERT to DROP in order to "block" with that rule when it triggers. In "Block Drops Only" mode, the ALERT action is just that -- it logs an alert but does nothing else. Inline IPS Mode is practically identical to "Block Drops Only" mode. Only rules with DROP as their action will actually block traffic. However, with Inline IPS Mode you also have the option of using REJECT as an action. With this action, traffic is still blocked, but the sending host is sent a "reject" command to let it know the traffic was blocked. The DROP action silently drops the traffic and never notifies the sending host of anything. Reject rules are sometimes handy when blocking traffic for internal hosts. It helps to tell the host the traffic is blocked up front. That way the host won't keep trying and waiting through timeouts attempting the communication over and over. Depends on the individual situation, though. DROP is by far the common action in IPS setups.
So you seem to be talking about changing a rule's Action. You do that with the dropsid and/or rejectsid options on the SID MGMT tab. You change a rule's State (whether it is even loaded into memory or not) with the enablesid and disablesid options on the SID MGMT tab.
Does the above help clear some things up?
-
Thank you for the reply Bill. I appreciate you taking time outlining the details.
So what I’m trying to do is change a rules Alert, identified by the yellow triangle icon with the white explanation mark in it, shown below:
to Drop as identified by the red thumbs down icon shown below:
I can see that the rules are Default Enabled as identified by the circled green checkmark icon as you mentioned. There are just so many of these rules that to change the Alert to Drop manually on each and every rule takes quite a bit of time, and yes it’s taken me quite a bit of time to date to complete what I have and this list keeps growing each time Suricata updates.
This is where I was hoping SID Mgmt would be able to help with this. I can see in the Interface SID Management List Assignments section each interface Suricata is running on. So I can create my own text file and name it something like dropRules.conf and add it with the green + Add button with the following lines in it which I can keep changing as rules are added with each Suricata update:
Drop the following from the rule:
ET COMPROMISED Known Compromised or Hostile Host Traffic group
1:2500000-1:2500442[sorry, I couldn't get a sharp in front of the first two lines]
I can then select the dropRules.conf file from the Drop SID List dropdown on the interface I choose to use it on. The SID State Order is a little confusing to me though: Disable, Enable or Enable, Disable...which one to pick?
-
In your case, you are only changing a rule's action, so the SID State Order is not applicable. See the word "State" in its title? That's the "state" I was referring to of enabled or disabled. You state you are changing the Action (from alert to drop), so state and thus State Order do not apply in that case. State Order only matters when you are both enabling and disabling rules (their "state", not "action"). It is important what order those files are processed so that rules wind up in the "state" you desire. When working with actions (DROP, ALERT, REJECT, or PASS), then the state order has no bearing.
And your entry in your
dropRules.conffile is correct. It will change the rule action from ALERT to DROP for the rules having SID numbers 2500000 through 2500442. -
Ohhhhhh, I see what you mean by "state" now that I see it in the rules I listed, the column with the the green circle and checkmark icon.
It's good to know that I don't have to change anything in the SID State Order dropdown and that I can just leave it as whatever default it's in.
This is going to save me a boat load of time.
I'm wondering though, what will SID Mgmt do about all of the other rules that I've changed to Drop? Will it bypass those rules and use only the rules in the dropRules.conf file or will it take all of the other rules I've dropped into account as well?
-
@newUser2pfSense said in Using Suricata SID Mgmt:
Ohhhhhh, I see what you mean by "state" now that I see it in the rules I listed, the column with the the green circle and checkmark icon.
It's good to know that I don't have to change anything in the SID State Order dropdown and that I can just leave it as whatever default it's in.
This is going to save me a boat load of time.
Yes, that green icon means a rule is "default enabled" by the creator of the rule. If you see the red X icon, that means the rule is "default disabled" by the creator of the rule meaning the rule text has the comment sign (that "#" symbol) at the beginning of the line of text so that rule is not loaded into memory by Suricata.
As a user, you can force rules to a given state. But don't confuse "state' with "action". State controls whether a rule is even loaded into memory. Action controls what the rule does when it is triggered (alert, drop traffic, send a reject response or pass the traffic).
Read that link I posted up above about how SIG MGMT works. Suricata uses both configurations (user-changed/forced and SID management conf files) to set rule actions.
-
That's fantastic to know that the other rules I've Dropped will not be overlooked.
-
@newUser2pfSense said in Using Suricata SID Mgmt:
I'm wondering though, what will SID Mgmt do about all of the other rules that I've changed to Drop? Will it bypass those rules and use only the rules in the dropRules.conf file or will it take all of the other rules I've dropped into account as well?
I suggest concentrating on not using "dropped" when talking about rules management. Most experienced admins will think you are talking about the "state", or changing a rule from enabled to disabled (like I did, initially). You should use the term "changing rule actions to DROP" to describe what you are doing. You are changing the "action" to DROP. You are NOT "dropping" the rule. You would be disabling those rules to "drop" them from the list of active rules. It is a very important distinction if you discuss this with other IDS/IPS admins.
-
Noted Bill...I think that's why initially I had trouble with the verbiage as well. I wasn't understanding. I'm glad now to know the distinction.
Again, and as always, thanks for all of your help. I definitely appreciate it.
-
@newUser2pfSense said in Using Suricata SID Mgmt:
Noted Bill...I think that's why initially I had trouble with the verbiage as well. I wasn't understanding. I'm glad now to know the distinction.
Again, and as always, thanks for all of your help. I definitely appreciate it.
You're welcome. Easy way to remember:
-
State refers to "enabled" or "disabled" and determines whether a given rule is even loaded into memory and processed by the IPS engine;
-
Action refers to what the rules does when triggered. Does it just alert, does it pass the traffic, does it drop the traffic, or does it drop and send a reject reply to the originator?
-
-
As a followup, I downloaded the Alerts to one of my interfaces to check to see if the action to Drop rules that I created in SID Mgmt actually worked.
This is what I have in my dropRules.conf file -
Drop the following from the rules:
ET COMPROMISED Known Compromised or Hostile Host Traffic group
1 thru 247
1:2500000-1:2500492[sharp in front of the first 3 lines]
From the Alerts log, this is a manual action to Drop rules line where it clearly shows it's dropped:
11/24/2020-23:17:06.276547 [Drop] [] [1:2500154:5627] ET COMPROMISED Known Compromised or Hostile Host Traffic group 78 [] [Classification: Misc Attack] [Priority: 2] {TCP} 139.59.116.115:46910 -> <my ip address:and port>From the Alerts log, this is a SID Mgmt action to Drop rules line where it clearly shows that it wasn't dropped:
11/24/2020-23:37:01.804877 [] [1:2500452:5627] ET COMPROMISED Known Compromised or Hostile Host Traffic group 227 [] [Classification: Misc Attack] [Priority: 2] {TCP} 67.205.141.165:48618 -> <my ip address:and port>[sorry, the asterisks are missing in both lines]
Here is my Interface SID Management List Assignments:
Have I done something incorrect? Or does SID Mgmt not show a Drop?
-
When you make changes on the SID MGMT tab, you need to do one of the following in order for the change to take effect. Nothing within Suricata is dynamic (as in it "just happens" without any user effort).
-
When you make a cfhange, place a check in the box under the Rebuild column for the interface you are modifying. This instructs Suricata to rebuild its internal rules file and then load the new file.
-
Go to the INTERFACES tab and physically restart Suricata on the interface you modified on the SID MGMT tab.
There is also a curently open bug on the upstream Suricata Redmine site that says rule action changes made when "live reload" is active are not honored. That could be an issue for you when you check the Rebuild checkbox as that will use the "live reload" feature of the Suricata binary. In that case, saving the SID MGMT tab changes and then going to the INTERFACES tab and cycling the affected interface should work.
All the GUI code in the pfSense package does is create the text-based
suricata.yamlconfiguration file for the binarysuricataexecutable to read. Anytime you make changes to configuration in the GUI you generally need to restart the binary for the changes to be seen. This entails going to the INTERFACES tab and restarting the binary from there. There are a couple of exceptions when "live reload" can work. One is when you manually "force" a rule and the other is when the Rebuild checkbox is clicked on the SID MGMT tab. -
-
I actually did the Rebuild on the interface thinking that Suricata would update/reload the rules. However, I didn't go to the interfaces tab and physically restart Suricata on the interface. I'll give that a try.
-
@newUser2pfSense said in Using Suricata SID Mgmt:
I actually did the Rebuild on the interface thinking that Suricata would update/reload the rules. However, I didn't go to the interfaces tab and physically restart Suricata on the interface. I'll give that a try.
One other thing to do is to check the actual active rules file to see if the SID MGMT regex is actually finding and modifying the rule or rules you want changed. You can find the file by going to the RULES tab and then choosing "Active Rules" in the drop-down there for viewing. If you have a ton of selected rules, it can take a long time for the page to load after selecting "Active Rules". You would be looking for the specific SIDs you changed and verifying the action was changed to DROP.
You can also go to the LOGS VIEW tab and select the SID Mgmt log for viewing. You will see entries in there detailing whether or not your regex identified rules for changing and how many it changed.
-
I'm currently running pfSense 2.4.5-RELEASE-p1 (amd64) and Suricata 5.0.4.
The manual action to Drop the rules are currently like this -
ET COMPROMISED Known Compromised or Hostile Host Traffic group 1
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 217
[this if from when I was manually setting the action to Drop]The SID Mgmt entry in the dropRules.conf file are collectively -
ET COMPROMISED Known Compromised or Hostile Host Traffic group 1
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 247
[1:2500000-1:2500492]So, ET COMPROMISED Known Compromised or Hostile Host Traffic group 218
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 247
the action is not shown to Drop in the Active Rules. They are still shown to Alert.In the Logs View tab, the Log File to View dropdown doesn't show a SID Mgmt log to view. The closest is a sid_changes.log which dispalys - Log file does not exist or that logging feature is not enabled.
-
sid_changes.logis the correct file. I was working from a faulty memory ...
.You must also select the proper interface in the Interface drop-down on that LOGS VIEW tab when viewing logs. It will default to the WAN when initially opened. Perhaps you were trying to find a
sid_changes.logfile for an interface which does not have any SID MGMT changes configured.If you had the correct interface selected and it says no
sid_changes.logfile exists, then you have not saved something correctly and run a rules rebuild. That log file is only created when SID MGMT changes are enabled, a valid configuration file is created and assigned to an interface, and then the interface is cycled to load the change. That's when the log file is written. -
Hmmmmm...my WAN and LAN Logs View tab look like this -
I'm not sure what I've done wrong. In SID Mgmt, I checked the Rebuild boxes and clicked Save for the interfaces and then restarted the interfaces before I checked the Logs View tab above.
-
At the very top of the SID MGMT tab is a checkbox to "Enable" that feature. I assume you placed a check there and saved it?
If no log file is available, that strongly indicates SID MGMT is not enabled for the interface. That log file is written when the rules file for an interface is created. Part of the creation of the rules file is processing SID management changes (when enabled and when rules match the regex) and any user-forced rule changes to action or state. Even if no regex matches are detected, the
sig_changes.logis still created showing zero matches when SID Managment is enabled on an interface.Trust me the process works. I have a standard test that is part of my testing suite for every new Suricata package release. It changes the ET-Scan rules to DROP via SIG MGMT.
-
Doh...Again, no one has ever accused me of being smart
.I checked the box at the top of SID Mgmt, chose the interfaces to Rebuild and Save, restarted the interfaces and then checked the Active Rules. All are now set on the action to Drop. As well, I can now view the sid_changes.log file.
Nice!!! Whew. I'm so glad this works.
-
Ok, so now the Suricata Updates are displaying "Not Downloaded".
So I chose to Force update and a half hour later, the updates are still not downloaded. In the Status > System Logs > System > General, I'm seeing -
[Suricata] There is a new set of Emerging Threats Open rules posted. Downloading emerging.rules.tar.gz...
[Suricata] Emerging Threats Open rules file update downloaded successfully.
[Suricata] There is a new set of Snort rules posted. Downloading snortrules-snapshot-29151.tar.gz...The Snort rules is where it looks to have stopped.
Interestingly though, more than a half hour later, the updates still appear to be downloading -
Not sure if this is normal or not.
-
So a hard restart of pfSense resolved the update issue. I think I'm out of the weeds now.
Thanks Bill.
