SID Mgmt change drop to block (white listing instead of blacklisting)
-
Hello,
Let's say I run Suricata in legacy IPS Mode with "block on DROP only" enabled
Now I set Snort detection policy to max-detect. There will be some drop rules, that trigger a lot of false positives, but may be useful when researching an incident, so disabling them is not an option.
I could force them to ALERT action via GUI, but I would like to do this via SID_Mgmt, for versionability and commenting.
The goal is to set a very restricting poilcy and then whitelisting rules, instead of the documented blacklisting through dropsid.confI got, that there is no dedicated inverse dropsid.conf file.
I tried doing it via modifysid.conf, but it diddn't work, because as I understand it, the Modify SID list cant modify the action part.My resulting question now is:
Is there some way to reset dropping rules to alerting via some versionable and commentable file?Thanks for your time
-
No, there is no method in the GUI package to accomplish what you desire short of doing it rule-by-rule on the RULES tab or using the icons beside individual alerts on the ALERTS tab.
-
OK.
Are you open for a PR adding an "alertsid.conf" as counterpart for "dropsid.conf"? -
@F90 said in SID Mgmt change drop to block (white listing instead of blacklisting):
OK.
Are you open for a PR adding an "alertsid.conf" as counterpart for "dropsid.conf"?I'm not sure about that. It seems it would only generate confusion for the vast majority of users as the rules default to ALERT anyway. The existence of an
alert.sidlogic has the potential to confuse users IMHO.The Max Detect policy is really designed for limited testing or perhaps when ingesting a PCAP file captured from some incident. So, I would consider your scenario to be an edge case and not widely applicable to Suricata and Snort users in general on pfSense.
-
@F90 said in SID Mgmt change drop to block (white listing instead of blacklisting):
OK.
Are you open for a PR adding an "alertsid.conf" as counterpart for "dropsid.conf"?I have also been looking for something similar to what you are proposing. Starting with the ET Open rules which has around 50 lists, some of which I wanted to keep as Alert. In the end I had to enter all the lists into the dropsid.conf, except the ones I wanted to keep as Alert.
Having a way to set entire lists or individual rules to Alert would be really helpful. Especially as you say from a manageability standpoint. In my case I could have left it with "emerging" in the Dropsid and then added the three or so lists I wanted to revert back to Alert in the Alertsid.conf file.
I'm thinking that users already understand that there is an order by which the lists are handled. As defined by the SID State Order. Same logic here where dropsid.conf may be processed before alertsid.conf... or reverse if set like that. It could even "inherit" the order from the existing SID State Order selected. (assuming Enable = Drop and Disable = Alert).
-
@Gblenn said in SID Mgmt change drop to block (white listing instead of blacklisting):
Strating with the ET Open rules which has around 50 lists, some of which I wanted to keep as Alert. In the end I had to enter all the lists into the dropsid.conf, except the ones I wanted to keep as Alert.
But the default state of all the rules is ALERT, so I'm struggling to see the actual use case here. Simply set the categories or specific rules (you can also match by GID:SID in
dropsid.conf) to DROP and the others will remain as their default of ALERT.Yes, it's a bit of typing or copy-paste, but that's part of the drudgery of what an IDS/IPS admin does. Once done, it's done.
The Snort IPS Policies are unique to just the Snort VRT rules. That meta data is not available in the Emerging Threats nor any other rules family. Just want to state that so there is no misunderstanding there. IPS Policy settings do not work at all (and the entire section is hidden) if you do not have the Snort VRT rules enabled on the GLOBAL SETTINGS tab.
-
@bmeeks said in SID Mgmt change drop to block (white listing instead of blacklisting):
Yes, it's a bit of typing or copy-paste, but that's part of the drudgery of what an IDS/IPS admin does. Once done, it's done.
And that's what I ended up doing, listing all the 50+ ET rules lists, except the three I wanted to keep as Alert only. Which, in order to keep track of what I did, I commented out and kept in the file.
But once done, it's done isn't really true is it? Things change, and you constantly need to adjust, typically by disabling or suppressing rules that are false positives. Mostly individual rules, but it could possibly be an entire list.
I think all changes I have ended up making are in the direction from Drop to Alert. Not the other way around... Starting out from some reasonable level based on e.g. Snort Policy (where I use Balanced) and some ideas about what other rules lists to disable or keep as Alert.
And this is part of what is so good with the lists, also the suppress list, in that they are so simple to read, and can easily be copied over to other tools like excel. They give you a good overview of what it is you have done.
And then we have usability aspect, and being practical or efficient. It's either:
emerging-3coresec.rules
emerging-activex.rules
emerging-adware_pup.rules
... and so on for each list ...Or simply writing.
emergingAnd then all the emerging threats rules are affected, and changed to Drop for example.
Then the next simple step would be to have a few of them reverted back to Alert, by creating a list for that, as suggested.
-
T tinfoilmatt referenced this topic on
