Suricata SID Mgmt - disable category + selective enable rules from that category


  • Banned

    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


  • Banned

    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



  • @doktornotor:

    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?



  • @drewsaur:

    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



  • @bmeeks:

    @drewsaur:

    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.



  • @drewsaur:

    @bmeeks:

    @drewsaur:

    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!!!



  • @drewsaur:

    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


Log in to reply