Snort Suppress list - not working
-
I have a list of items in the suppress tab. The below sig keeps triggering on alerts and not sure why. Below is how I have it entered
#(http_inspect) UNKNOWN METHOD
suppress gen_id 119, sig_id 31 -
If you manually entered the suppression text, did you then restart Snort on the interface? Suppress lists are only read during startup. After that they are static. When you suppress using the icons in the GUI, then the Snort process is sent a SIGUSR command to reload its configuration.
Also, if you manually created a SUPPRESS LIST and did not use the GUI icons on the ALERTS tab, then you must go to the INTERFACE SETTINGS tab for the Snort interface and scroll down to the bottom and select the Suppress List in the SUPPRESS drop-down box. Save the change and then restart Snort on the interface.
Bill
-
If you manually entered the suppression text, did you then restart Snort on the interface? Suppress lists are only read during startup. After that they are static. When you suppress using the icons in the GUI, then the Snort process is sent a SIGUSR command to reload its configuration.
Also, if you manually created a SUPPRESS LIST and did not use the GUI icons on the ALERTS tab, then you must go to the INTERFACE SETTINGS tab for the Snort interface and scroll down to the bottom and select the Suppress List in the SUPPRESS drop-down box. Save the change and then restart Snort on the interface.
Bill
For the SSL HELLO rule, I would just disable it. On the ALERTS tab, click the red X beside the rule GID:SID in the far right column. When a rule is disabled, Snort will not even inspect traffic against it and thus save those CPU cycles. When just suppressed, the rule is still evaluated but it just does not generate any alerts (so wasted CPU cycles unless you are doing filtered suppression as in only suppressing for certain IP addresses, for example).
A ton of the HTTP_INSPECT preprocessor rules are prone to false positives. There is a recommended list on the forum here in a thread from a while back that shows which of these most folks disable. Google can be your friend in determining what some of the rules are trying to do.
Bill
On the other post and this one, thank you for explaining this to me, I think i miss understood how the suppression worked. I didn't assign an IP when I suppressed I just assumed it would stop paying attention to the rule all together. And no I didn't restart snort on the interface either.
When I go and disable the rule all together, where is that saved ? Like the area of the suppersions where I just copied and pasted a set of rules. Which are rules I saw on another section of this forum that said you should just ingore them all together. I took that and pasted it into suppression, where should I have pasted it to ignore instead ?
Or am i better off just clicking the X next to it instead on the ones I know I want to disable. I found the list of the one's enabled by default inthe interface rules on the WAN rules tab. If I can't copy and past like I can in suppersion, do I just find them all manually and click them on the RULES tab for each interface ? -
If you know you don't want the rule to trigger at all, then it is best to disable it versus suppressing it. Disabling saves memory and CPU cycles.
As for how to disable, there are three ways.
#1
For a single rule here and there, the easiest way is to click the red X beside the GID:SID on the ALERTS tab in the right-hand column for a row where that rule fired. If you don't have a recent or easily located alert for the rule, then either of the next two methods will work.#2
You can disable rules on the RULES tab for an interface. Click the icon on the left beside a rule to change its state from enabled to disabled, or from disabled to enabled. The icon will change to show you have modified the rule from its default state. There is a legend at the bottom of the page showing what the icon colors mean. You can select the different rules categories in the Category drop-down. When you select a category, then only those rules will display. Changes you make are saved in the config.xml file for the firewall. Any changes are per-interface. This means you can have the same rule active on the WAN but disabled on the LAN if you desire.#3
The third method for controlling the state of rules is the most powerful. It is located on the SID MGMT tab. There is a lot of power on that tab when it is enabled. Click the checkbox to enable SID management, then look through the example files you will see. They have comments inside them showing how to use the SID MGMT features. This tab lets you specify rules to enable to disable using powerful regular expression syntax.Bill
-
Just noting - really look at #3. Very convenient and very fast to quickly disable bunch of rules. Even if you won't use any of the advanced options like regex. Plus, you can add comments on when/why you disabled the rules there. Once you finished, save the file, assign it to interface(s) and tick the checkbox(es) to reload the rules for interface(s).
-
In my enviroment for my house I have 2 WAN connections, I am still waiting on the 2nd WAN connection to be installed but once it is I will be using the 2nd WAN connection as just a back up. Basically if one goes down, switch everything over to the 2nd WAN connection.
So I tried to do #2 that you mentioned and even though it was pretty easy it kind of sucked, cause I had to go find all the rules twice and click next to them. If I know I want to disabled the below rules ( I have more than this, just wanted to paste some as an example
#(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
suppress gen_id 120, sig_id 3#(http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED
suppress gen_id 120, sig_id 6#(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
suppress gen_id 120, sig_id 8#(http_inspect) DOUBLE DECODING ATTACK
suppress gen_id 119, sig_id 2#(http_inspect) JAVASCRIPT WHITESPACES EXCEEDS MAX ALLOWED
suppress gen_id 120, sig_id 10#(http_inspect) IIS UNICODE CODEPOINT ENCODING
suppress gen_id 119, sig_id 7Below is the examples fromt he SID Mgmt
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!
For the above rules I pasted as an example and using the example from the SID Mgmt, is the below the syntax I would use to disable the rules. When enter the information what goes first, gen ID or Sig ID
#would this be the syntax I need to use ?
3:120, 6:120, 8:120, 2:120, 10:120, 7:119 -
Yep, you've got the idea. There are also other examples in the files showing how to use rule names and other tidbits of information to identify rules. It is important to note that with SID MGMT, the last command to touch a rule's state wins. Notice there are two files: disablesid.conf and enablesid.conf. There is also a drop-down at the bottom of the page that determines the order in which those two files are used. So if the file that "enables" rules is run first and enables say rule 1:10000 and several dozen other rules; and then the file that "disables" rules is run next and it disables rule 1:10000, then rule 1:10000 will remain "disabled" because the disable command ran last. The converse is also true. If the enable command file runs last, it may enable a rule that was disabled in the disable command file. It sounds confusing initially, but if you just think about it in terms of "last action wins", it will make sense. This knowledge can be used to advantage when you want to disable almost all the rules in a category except maybe four or five. You put the category name in the "disable" file to cause all the rules in the category to be disabled, and then the GID:SID of just the four or five rules you want to enable from that category in the "enable" file. You would then set the order to be "disable,enable" so the enable file was evaluated last.
Bill
-
Awesome ! thanks everyone for the help with that an explaining what the enable, disable order does.
glad to hear I got the syntax right with GID:SID
off to do some more tinkering with my SNORT set up :-)