Suricata SID Mgmt - disable category + selective enable rules from that category
-
Say I want to disable all rules from ET P2P category except for those with classtype:trojan-activity. Should be possible with SID State Order set to "Disable, Enable" and proper PCRE. Cannot figure it out, suspect mainly because I hate PCRE with passion.
Anyone? ::)
-
You are on the right track with the "Disable, Enable" processing for the SID State Order. Simply put the name of the rule category in the disablesid.conf file to disable an entire category. Now to come back and selectively enable just some of the rules in that category will take a fancy PCRE in the enablesid.conf file. Unfortunately, my PCRE is super basic (as in just barely fluent at all without a ton of Google examples)… :(.
What has helped me a lot in the past with PCRE testing are the various online PHP PCRE testers out there. You paste in the target text in one box and your PCRE in another. The testers then show you the result of evaluating the PCRE against your supplied target text.
Did you try something like this in the enablesid.conf?
pcre:"classtype:trojan-activity"
This will, of course, enable any rule in any category with that class type. That may or may not be what you want. There is no way to apply the PCRE to just a single rule category, though.
Bill
-
OK, I did a quick test and got it to work, but it may not be 100% what you are wanting. Depends on how restrictive you want that "classtype:trojan-activity" PCRE test to be across the rule categories. The only way it will work is by letting it enable all rules containing that class type.
Here is the disablesid.conf file I used for testing:
# example disablesid.conf V3.1 # The modifications in this file are for sample/example purposes only and # should not actively be used, you need to modify this file to fit your # environment. # ssh: Protocol mismatch 128:4 # http_inspect: NO CONTENT Length or Transfer Encoding 120:3 # ET RDP connection confirm 1:2001329 # SENSITIVE-DATA Email Addresses 138:5 # Stream5: TCP Small Segment Threshold Exceeded 120:12 # http_inspect: LONG HEADER 119:19 # ET Policy RDP connection confirm 1:2001330 # http_inspect: Unknown Method 119:31 # http_inspect: Oversize Request-URI Directory 119:15 # Sensitive_data - Email Addresses 138:5 # Sensitive_data - Global threshold exceeded 139:1 # Sensitive_data - Credit card numbers 138:2 # http_inspect: Message with invalid content-length 120:8 # Stream5: Bad Segment, overlap adjusted size less than/equal 0 129:5 # Stream5: Reset outside window 129:15 # http_inspect: HTTP RESPONSE GZIP DECOMPRESSION FAILED 120:6 # Stream5: TCP Small Segment Threshold Exceeded 129:12 # stream5: TCP Timestamp is missing 129:14 # ssp_ssl: Invalid Client HELLO after Server Hello Detected 137:1 # ET POLICY Microsoft Online Storage Client Hello TLSv1 Possible SkyDrive 1:2014919 1:2014920 # ET CHAT Google IM traffic Jabber client sign-on 1:2002334 # http_Inspect: Non-RFC Defined CHAR 119:14 # GPL SNMP public access udp #1:2101411 # Stream5: TCP Timestamp is outside of PAWS window 129:4 # GPL SHELLCODE x86 inc ebx NOOP 1:2101390 #ET INFO Session Traversal Utilities for NAT (STUN Binding Response) 1:2016150 #ET INFO Session Traversal Utilities for NAT (STUN Binding Request) 1:2016149 # ET Policy Microsoft user-agent automated process response to automated request 1:2012692 # #SURICATA STREAM Packet with Invalid ack 1:2210045 #SURICATA STREAM ESTABLISHED invalid ack 1:2210029 #SURICATA STREAM ESTABLISHED packet out of window 1:2210020 #SURICATA ICMPv6 unknown type 1:2200029 #SURICATA STREAM ESTABLISHED retransmission packet before last ack 1:2210021 #SURICATA STREAM SHUTDOWN RST invalid ack 1:2210046 #GPL SNMP public access UDP 1:2101411 # # DISABLED SNORT VRT RULES browser-firefox.rules,browser-other.rules,chat.rules,content-replace.rules,os-other.rules,os-solaris.rules,policy-multimedia.rules,policy-other.rules,policy-social.rules,policy-spam.rules,server-mail.rules,server-oracle.rules,protocol-scada.rules # DISABLED ETPRO RULES chat.rules web_specific_apps.rules,web_server.rules,tor.rules,rbn.rules,rbn-malvertisers.rules,botcc.rules,ciarmy.rules,p2p.rules # PCRE DISABLES | # ----------------- pcre:"Adobe Director" pcre:"Microsoft Works" pcre:"Oracle AutoVue" pcre:"SkinCrafter" pcre:"ThreeDify" pcre:"SoftArtisans" pcre:"Tracker Software pdfSaver" pcre:"CA Internet"
Here is the enablesid.conf file:
# example enablesid.conf v3.1 # The modifications in this file are for sample/example purposes only and # should not actively be used, you need to modify this file to fit your # environment. # ENABLED ET-PRO RULES imap # Test PCRE rule pcre:"classtype:trojan-activity"
Resulting sid_changes.log file:
******************************************************** Starting auto RULE CATEGORY management for WAN Start Time: 2015-06-29 20:59:34 Processing disable_sid file: disablesid.conf Disabled rule category: etpro-chat.rules Disabled rule category: etpro-web_specific_apps.rules Disabled rule category: etpro-web_server.rules Disabled rule category: etpro-tor.rules Disabled rule category: etpro-rbn.rules Disabled rule category: etpro-rbn-malvertisers.rules Disabled rule category: etpro-botcc.rules Disabled rule category: etpro-ciarmy.rules Disabled rule category: etpro-p2p.rules Parsed 22 potential Rule Categories to match from the list of tokens. Disabled 9 matching Rule Categories. Processing enable_sid file: enablesid.conf Enabled rule category: etpro-imap.rules Parsed 1 potential Rule Categories to match from the list of tokens. Enabled 1 matching Rule Categories. End Time: 2015-06-29 20:59:34 ******************************************************** ******************************************************** Starting auto SID management for WAN Start Time: 2015-06-29 20:59:35 Processing disable_sid file: disablesid.conf Parsed 34 potential SIDs to match from the provided list of tokens. Found 15 matching SIDs in the active rules. Changed state for 15 SIDs to 'disabled'. Processing enable_sid file: enablesid.conf Parsed 41 potential SIDs to match from the provided list of tokens. Found 20 matching SIDs in the active rules. Changed state for 20 SIDs to 'enabled'. End Time: 2015-06-29 20:59:37 ********************************************************
If you look at the bottom of the log file you will see it enabled 1 category (the etpro-imap.rules) and 20 SIDs (should be the trojan-activity class type rules). Those would be the ones that matched the PCRE I provided.
Bill
-
Thanks, I will play with this. I really suck with PCRE. :D
Found these examples for PulledPork as well, but not sure it's usable on pfSense's Snort/Suricata: http://marc.info/?l=snort-users&m=139301166823518&w=2
-
Thanks, I will play with this. I really suck with PCRE. :D
Found these examples for PulledPork as well, but not sure it's usable on pfSense's Snort/Suricata: http://marc.info/?l=snort-users&m=139301166823518&w=2
The examples should work on Snort/Suricata. I tried to faithfully reproduce the behavior of Oinkmaster and PulledPork with regards to syntax in the conf files.
Bill
-
I don't seem to be able to successfully disable rules that are "classtype:not-suspicious" using pcre:"classtype:not-suspicious" - does anyone have a tip to offer?
-
I don't seem to be able to successfully disable rules that are "classtype:not-suspicious" using pcre:"classtype:not-suspicious" - does anyone have a tip to offer?
Will none of them will disable, or maybe just a few of them do not disable?
I ask because the order of processing for ensablesid.conf and disablesid.conf is very critical. There is a drop-down selector on the SID MGMT tab down at the bottom of the page to select the processing order for each configured Suricata interface. The last conf file wins, so for example if you had an expression in both files that selected the same rule, and enablesid.conf was selected to process last, the rule would be enabled even if it also got picked up by disablesid.conf. Reverse the processing order of the two conf files and the results from my example would be exactly opposite.
Another possibility if only some of those classtype rules are remaining enabled is that they are getting picked up in Auto Flowbit rules.
Finally, if none of the classtype rules are getting disabled, then the PCRE is failing to identify the text. I need to fire up a virtual machine with the latest Suricata and test. I run Snort on my home firewall just because that's what I originally started with, and I've never made the effort to swap over.
Bill
-
I don't seem to be able to successfully disable rules that are "classtype:not-suspicious" using pcre:"classtype:not-suspicious" - does anyone have a tip to offer?
Will none of them will disable, or maybe just a few of them do not disable?
I ask because the order of processing for ensablesid.conf and disablesid.conf is very critical. There is a drop-down selector on the SID MGMT tab down at the bottom of the page to select the processing order for each configured Suricata interface. The last conf file wins, so for example if you had an expression in both files that selected the same rule, and enablesid.conf was selected to process last, the rule would be enabled even if it also got picked up by disablesid.conf. Reverse the processing order of the two conf files and the results from my example would be exactly opposite.
Another possibility if only some of those classtype rules are remaining enabled is that they are getting picked up in Auto Flowbit rules.
Finally, if none of the classtype rules are getting disabled, then the PCRE is failing to identify the text. I need to fire up a virtual machine with the latest Suricata and test. I run Snort on my home firewall just because that's what I originally started with, and I've never made the effort to swap over.
Bill
Bill,
None of the rules are being disabled using that PCRE. I am able to, in the very same disable file, exclude the individual rules by numeric reference, however. I would think that the auto flowbits would also have an impact here if they were to have an impact on the PCREdefinition. FWIW, I am set to enable/disable.
-
I don't seem to be able to successfully disable rules that are "classtype:not-suspicious" using pcre:"classtype:not-suspicious" - does anyone have a tip to offer?
Will none of them will disable, or maybe just a few of them do not disable?
I ask because the order of processing for ensablesid.conf and disablesid.conf is very critical. There is a drop-down selector on the SID MGMT tab down at the bottom of the page to select the processing order for each configured Suricata interface. The last conf file wins, so for example if you had an expression in both files that selected the same rule, and enablesid.conf was selected to process last, the rule would be enabled even if it also got picked up by disablesid.conf. Reverse the processing order of the two conf files and the results from my example would be exactly opposite.
Another possibility if only some of those classtype rules are remaining enabled is that they are getting picked up in Auto Flowbit rules.
Finally, if none of the classtype rules are getting disabled, then the PCRE is failing to identify the text. I need to fire up a virtual machine with the latest Suricata and test. I run Snort on my home firewall just because that's what I originally started with, and I've never made the effort to swap over.
Bill
Bill,
None of the rules are being disabled using that PCRE. I am able to, in the very same disable file, exclude the individual rules by numeric reference, however. I would think that the auto flowbits would also have an impact here if they were to have an impact on the PCREdefinition. FWIW, I am set to enable/disable.
It works for me in a VM. Just tested. Try your PCRE without the quotation marks around classtype:not-suspicious like this –
pcre:classtype:not-suspicious
I verified the rules were physically not in the suricata.rules file which holds the active rules for an interface, and they were also flagged in the GUI on the RULES tab with the "A" in a red circle icon which indicates the rules were auto-disabled by SID managment.
Bill
-
Removing the quotation marks was the trick. Thanks. Not sure why the examples in the files include them!!!
-
Removing the quotation marks was the trick. Thanks. Not sure why the examples in the files include them!!!
To separate them from the other text, but perhaps it would be useful to add a disclaimer in the examples that the quotation marks should not be included.
You put only exactly what you are searching for after the pcre: keyword in the SID management conf files.
Bill