Using Suricata SID Mgmt
-
I've been using Suricata for a while now but I've never used SID Mgmt. I typically go into a Suricata interface and drop rules manually. The hard part is when you have quite a few that you would like to drop, it takes a bit of time to manually complete this action. For instance, I have manually dropped the following:
ET COMPROMISED Known Compromised or Hostile Host Traffic group 1
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 217If I wanted to drop all of these rules, how would I do this in SID Mgmt? I've not been able to find any examples or explanations. I've read the text within the dropsid-sample.conf file but it wasn't clear to me how I could do this. In SID Mgmt, I can see the listed interfaces, the SID State Order, Enable SID List, Disable SID List, Modify SID List, Drop SID List and Reject SID List. Would anyone be able to provide directions on how I could do this? Thank you.
-
First, the dropsid list is NOT what you want (I don't think). You want the disablesid list because you want to not use specific rules. The dropsid list is for modifying a rule's action when using either Inline IPS Mode or Legacy Mode with the "block DROPS only" option enabled.
SID MGMT works by using Perl Regular Expression matching (regex) to match rules for processing. The easiest way is to use a range of GID:SID values if the rules you want to enable or disable are in consecutive order. There are examples of SID ranges in the enablesid.conf and disablesid.conf sample files.
The fields listed at the bottom where you choose SID State Order, Enable SID List and Disable SID List are used to set which SID managment configuration files will be used with which interface. For your requirement, it sounds like you want to configure a
disablesid.conffile (you can name it whatever you want to, but having "disable" in the name someplace is a good idea for future reference). Once you create the file with the proper regex matching strings, then find your interface at the bottom of the web page and choose your disablesid.conf file (whatever you named it) in the drop-down selector for Disable SID List. Save the change.You can use SID management files to enable rules and to disable rules. The SID State Order box lets you choose which file is processed first (the one that enables specific rules or the one that disables specific rules). This becomes important if your regex happens to match the same rule in both files. Whichever file is processed last wins.
There is a Sticky Post at the top of this forum about using SID MGMT. Here is a link: https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata.
-
I'm currently running in Inline mode on all of my interfaces.
I think the word disable is throwing me off a little. If I want the disablesid list because I want to not use specific rules, I don't believe that's what I want. I want to use the rules to perform a specific action like drop packets. Maybe it's just the verbiage that I'm not understanding. No one has ever accused me of being smart [huge laugh].
When I edit an interface in Suricata and choose to manually drop a rule, I believe that when packets hit that interface that matches the rule I selected to drop, those packets get dropped - in other words, they don't make it through. That's what I understand this action to do. Am I incorrect in this?
When I read the word disable, I'm thinking I'm disabling the rule (don't use the rule) instead of choosing the rule to do what I want it to do - drop packets that hit the interface that matches the rule.
I hope that makes a little sense.
-
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.
