Suricata SID Mgmt Config List examples
-
silly/lazy question—but anybody got copies?
-
@cyberconsultants
i'm gonna post mine because i'm pretty sure it's wrong and i'm hoping that one of the experts would chime in and tell us what's wrong.
My settings are as follows:
-inline mode active on LAN.
-Block offenders checked (although in inline mode i don't think it matters because, if i'm correct, in inline mode it's more dynamic, whereas in legacy mode, an 'alert' auto drops/blocks the ip address).
under LAN Categories:
Use IPS policy checked.
IPS policy (mine is set to maximum detection)
ips policy mode is set to policy.i then did a select all and hit save. this only checks the ET rules. snort rules in the next column are auto-managed by the above IPS Policy Select (again, Max detection in my case).
under sid mgmt, i created a blank copy of each of the *sample.conf, renaming them to the same name as where they came from, sans "sample" in the name. the files are also blank.
i have 1 sid file active: dropsid.conf. it is also selected under the "drop sid list". from what i understand, the name is completely arbitrary.
in my dropsid.conf i have the following line:
"1:200000-1:2050000 "
the GID is 1 and rules 2000000-2050000 have all automatically been changed from 'alert' to 'drop'.
hopefully someone will chime in, because at this point, it almost seems to me that legacy mode might be the better way to go, only because, sure there's initial leakage, but as time wears on and the list of blocked ips builds in the snort2c file, there will be less and less leakage.
-
Just as a follow-up..
I should probably be putting that rule in the rejectsid.conf instead of dropsid.conf.
reason being is that i'm only scanning my lan interface because i don't have any ports open, and blocking would eat up cpu cycles, while reject really wouldn't..
something i'm gonna try..
-
@jc1976 said in Suricata SID Mgmt Config List examples:
legacy mode might be the better way to go, only because, sure there's initial leakage, but as time wears on and the list of blocked ips builds in the snort2c file, there will be less and less leakage
Depends on how long the block is set to last until removed. And whether "initial leakage" allows a malicious packet to get through and run a command before the second packet is blocked.
I tried inline several years ago but couldn't get it to work in a stable manner, and haven't tried again. It is rather NIC driver dependent.
-
@jc1976 on a default Suricata install, the SID Mgmt tab contains some example .conf files (maybe only after you tick and save the 'enable auto management' box.) but those are the copies i'm looking for.
-
@cyberconsultants Like the dropsid-sample.conf?
# Note: This file is used to specify what rules you wish to be set to have # an action of drop rather than alert. # Example of modifying state for individual rules # 1:1034,1:9837,1:1270,1:3390,1:710,1:1249,3:13010 # Example of modifying state for rule ranges # 1:220-1:3264,3:13010-3:13013 # Comments are allowed in this file, and can also be on the same line # As the modify state syntax, as long as it is a trailing comment # 1:1011 # I Disabled this rule because I could! # Example of modifying state for MS and cve rules, note the use of the : # in cve. This will modify MS09-008, cve 2009-0233, bugtraq 21301, # and all MS00 and all cve 2000 related sids! These support regular expression # matching only after you have specified what you are looking for, i.e. # MS00-<regex> or cve:<regex>, the first section CANNOT contain a regular # expression (MS\d{2}-\d+) will NOT work, use the pcre: keyword (below) # for this. # MS09-008,cve:2009-0233,bugtraq:21301,MS00-\d+,cve:2000-\d+ # Example of using the pcre: keyword to modify rulestate. the pcre keyword # allows for full use of regular expression syntax, you do not need to designate # with / and all pcre searches are treated as case insensitive. For more information # about regular expression syntax: http://www.regular-expressions.info/ # The following example modifies state for all MS07 through MS10 # pcre:MS(0[7-9]|10)-\d+ # The following example modifies state for Snort VRT rules tagged with IPS # Policy Security and ips drop # ----------------- # pcre:"pcre:security-ips\s*drop" # Example of modifying state for specific categories entirely # VRT-web-iis,ET-shellcode,ET-emergingthreats-smtp,Custom-shellcode,Custom-emergingthreats-smtp # Any of the above values can be on a single line or multiple lines, when # on a single line they simply need to be separated by a , # 1:9837,1:220-1:3264,3:13010-3:13013,pcre:MS(0[0-7])-\d+,MS09-008,cve:2009-0233 # 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.enablesid-sample.conf:
# example enablesid.conf # Example of modifying state for individual rules # 1:1034,1:9837,1:1270,1:3390,1:710,1:1249,3:13010 # Example of modifying state for rule ranges # 1:220-1:3264,3:13010-3:13013 # Comments are allowed in this file, and can also be on the same line # As the modify state syntax, as long as it is a trailing comment # 1:1011 # I Disabled this rule because I could! # Example of modifying state for MS and cve rules, note the use of the : # in cve. This will modify MS09-008, cve 2009-0233, bugtraq 21301, # and all MS00 and all cve 2000 related sids! These support regular expression # matching only after you have specified what you are looking for, i.e. # MS00-<regex> or cve:<regex>, the first section CANNOT contain a regular # expression (MS\d{2}-\d+) will NOT work, use the pcre: keyword (below) # for this. # MS09-008,cve:2009-0233,bugtraq:21301,MS00-\d+,cve:2000-\d+ # Example of using the pcre: keyword to modify rulestate. the pcre keyword # allows for full use of regular expression syntax, you do not need to designate # with / and all pcre searches are treated as case insensitive. For more information # about regular expression syntax: http://www.regular-expressions.info/ # The following example modifies state for all MS07 through MS10 # pcre:MS(0[7-9]|10)-\d+ # pcre:"Joomla" # Example of modifying state for specific categories entirely. # "snort_" limits to Snort VRT rules, "emerging-" limits to # Emerging Threats Open rules, "etpro-" limits to ET-PRO rules. # "shellcode" with no prefix would match in any vendor set. # snort_web-iis,emerging-shellcode,etpro-imap,shellcode # Any of the above values can be on a single line or multiple lines, when # on a single line they simply need to be separated by a , # 1:9837,1:220-1:3264,3:13010-3:13013,pcre:MS(0[0-7])-\d+,MS09-008,cve:2009-0233modifysid-sample.conf:
# example modifysid.conf # # formatting is simple # <sid, category, list of sids&categories> "what I'm replacing" "what I'm replacing it with" # # Note that this will only work with GID:1 rules, simply because modifying # GID:3 SO stub rules would not actually affect the rule. # # If you are attempting to change rulestate (enable,disable) from here # then you are doing it wrong. Do this from within the respective # rulestate modification configuration files. # the following applies to sid 10010 only and represents what would normally # be s/to_client/from_server/ # 10010 "to_client" "from_server" # the following would replace HTTP_PORTS with HTTPS_PORTS for ALL GID:1 # rules # "HTTP_PORTS" "HTTPS_PORTS" # multiple sids can be specified as noted below: # 302,429,1821 "$EXTERNAL_NET" "$HOME_NET" # modify all signatures in a category. Example: replace "$EXTERNAL_NETS" with "any" to be alerts on insider threats as well # emerging-scan "$EXTERNAL_NET" "any" # modify all signatures in multiple categories # emerging-scan,emerging-sql "$EXTERNAL_NET" "any" # modify all signatures for a category and specific SIDs from other categories # emerging-sql,2100691,2009817 "$EXTERNAL_NET" "any"disablesid-sample.conf:
# example disablesid.conf # Example of modifying state for individual rules # 1:1034,1:9837,1:1270,1:3390,1:710,1:1249,3:13010 # Example of modifying state for rule ranges # 1:220-1:3264,3:13010-3:13013 # Comments are allowed in this file, and can also be on the same line # As the modify state syntax, as long as it is a trailing comment # 1:1011 # I Disabled this rule because I could! # Example of modifying state for MS and cve rules, note the use of the : # in cve. This will modify MS09-008, cve 2009-0233, bugtraq 21301, # and all MS00 and all cve 2000 related sids! These support regular expression # matching only after you have specified what you are looking for, i.e. # MS00-<regex> or cve:<regex>, the first section CANNOT contain a regular # expression (MS\d{2}-\d+) will NOT work, use the pcre: keyword (below) # for this. # MS09-008,cve:2009-0233,bugtraq:21301,MS00-\d+,cve:2000-\d+ # Example of using the pcre: keyword to modify rulestate. the pcre keyword # allows for full use of regular expression syntax, you do not need to designate # with / and all pcre searches are treated as case insensitive. For more information # about regular expression syntax: http://www.regular-expressions.info/ # The following example modifies state for all MS07 through MS10 # pcre:MS(0[7-9]|10)-\d+ # pcre:"Joomla" # Example of modifying state for specific categories entirely. # "snort_" limits to Snort VRT rules, "emerging-" limits to # Emerging Threats Open rules, "etpro-" limits to ET-PRO rules. # "shellcode" with no prefix would match in any vendor set. # snort_web-iis,emerging-shellcode,etpro-imap,shellcode # Any of the above values can be on a single line or multiple lines, when # on a single line they simply need to be separated by a , # 1:9837,1:220-1:3264,3:13010-3:13013,pcre:MS(0[0-7])-\d+,MS09-008,cve:2009-0233 # 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. -
@steveits yep. thank you, sir.
-
@steveits said in Suricata SID Mgmt Config List examples:
@jc1976 said in Suricata SID Mgmt Config List examples:
legacy mode might be the better way to go, only because, sure there's initial leakage, but as time wears on and the list of blocked ips builds in the snort2c file, there will be less and less leakage
Depends on how long the block is set to last until removed. And whether "initial leakage" allows a malicious packet to get through and run a command before the second packet is blocked.
I tried inline several years ago but couldn't get it to work in a stable manner, and haven't tried again. It is rather NIC driver dependent.
stability and speed-wise, I've never had a problem with inline. i've only used intel nics as they were always what were available to me. i've used pro/1000's up to the i350t2v2, which is what i'm using at the moment and they seem to work flawlessly. just gotta make sure that all those hardware offload settings are disabled, and verify that they actually are (last night i realized that despite TSO offload being deactivated, the "net.inet.tcp.tso" enable, under SystemAdvancedSystem Tunables said otherwise. so i had to force it to '0'.
anywho, yeah i'd prefer to run inline but kinda doesn't serve much of a purpose if it's only alerting and not blocking. I thought about running legacy and set the block to never expire. not sure if that's best practice though
-
ultimately i still have no idea what i'm doing.. just as i think i might have gotten it, something else raises a question that makes me second guess everything.
