Difference between revisions of "Snort payload rule options"

From Notes_Wiki
(Created page with "=snort payload rule options= ==content== content option allows the user to set rules that search for specific content in the packet payload and trigger response based on that ...")
 
m
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
=snort payload rule options=
[[Main Page|Home]] > [[CentOS]] > [[CentOS 6.x]] > [[Security tools]] > [[Snort configuration]] > [[Snort payload rule options]]
 
==content==
==content==
content option allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. If data exactly matching the argument data string is contained anywhere within the packet’s payload, the test is successful and the remainder of the rule option tests are performed. Match is case sensitive by default.  
content option allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. If data exactly matching the argument data string is contained anywhere within the packet’s payload, the test is successful and the remainder of the rule option tests are performed. Match is case sensitive by default.  
Line 396: Line 397:


One can refer to Snort Manual for various other payload rules options not described here or for more description / examples on payload rule options described on this page. '<tt>byte_test</tt>', '<tt>byte_jump</tt>' and '<tt>byte_extract</tt>' not covered here can be of interest.
One can refer to Snort Manual for various other payload rules options not described here or for more description / examples on payload rule options described on this page. '<tt>byte_test</tt>', '<tt>byte_jump</tt>' and '<tt>byte_extract</tt>' not covered here can be of interest.
[[Main Page|Home]] > [[CentOS]] > [[CentOS 6.x]] > [[Security tools]] > [[Snort configuration]] > [[Snort payload rule options]]

Latest revision as of 15:53, 24 March 2022

Home > CentOS > CentOS 6.x > Security tools > Snort configuration > Snort payload rule options

content

content option allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. If data exactly matching the argument data string is contained anywhere within the packet’s payload, the test is successful and the remainder of the rule option tests are performed. Match is case sensitive by default.

We can mix and match text and binary data. To specify binary data we enclose hexadecimal representation of binary data within pipe ('|') characters. If we want to specify more than one binary character than we use space (' ') to separate the binary characters from each other.


Format:

content:[!]"<content string>";


Example:

alert tcp any any -> any 139 (content:"|5c 00|P|00|I|00|P|00|E|00 5c|";)
alert tcp any any -> any 80 (content:!"GET";)


Content modifiers

Content has lot of modifier keywords which affect how previously defined content option works.


nocase

This modifier makes content search case insensitive.

Format:

nocase;


rawbytes

The rawbytes keyword allows rules to look at the raw packet data, ignoring any decoding that was done by preprocessors.

Format:

rawbytes;


depth

The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern. For example, a depth of 5 would tell Snort to only look for the specified pattern within the first 5 bytes of the payload.

The value can also be set to a string value referencing a variable extracted by the byte extract keyword in the same rule. The offset and depth keywords may be used together. You can not use depth with itself, distance, or within (to modify the same content).

Format:

depth:[<number>|<var_name>];


offset

The offset keyword allows the rule writer to specify where to start searching for a pattern within a packet. For example, an offset of 5 would tell Snort to start looking for the specified pattern after the first 5 bytes of the payload.

The value can also be set to a string value referencing a variable extracted by the byte extract keyword in the same rule. The offset and depth keywords may be used together. You can not use offset with itself, distance, or within (to modify the same content).

Format:

    offset:[<number>|<var_name>];


distance

The distance keyword allows the rule writer to specify how far into a packet Snort should ignore before starting to search for the specified pattern relative to the end of the previous pattern match. This can be thought of as exactly the same thing as offset, except it is relative to the end of the last pattern match instead of the beginning of the packet.

This keyword allows values from -65535 to 65535. The distance and within keywords may be used together. You can not use distance with itself, offset, or depth (to modify the same content). The value can also be set to a string value referencing a variable extracted by the byte extract keyword in the same rule.

Format:

distance:[<byte_count>|<var_name>];

Example: The rule below maps to a regular expression 'ABC.DEF'

alert tcp any any -> any any (content:"ABC"; content:"DEF"; distance:1;)


within

The within keyword is a content modifier that makes sure that at most N bytes are between pattern matches using the content keyword. It’s designed to be used in conjunction with the distance rule option.

The distance and within keywords may be used together. You can not use within with itself, offset, or depth (to modify the same content). The value can also be set to a string value referencing a variable extracted by the byte extract keyword in the same rule.

Format:

within:[<byte_count>|<var_name>];

Example: This rule constrains the search of EFG to not go past 10 bytes past the ABC match.

alert tcp any any -> any any (content:"ABC"; content:"EFG"; within:10;)


http_client_body

The http client body keyword is a content modifier that restricts the search to the body of an HTTP client request.

The amount of data that is inspected with this option depends on the post depth config option of HttpInspect. Pattern matches with this keyword wont work when post depth is set to -1.

Format:

      http_client_body;

Example: This rule constrains the search for the pattern ”EFG” to the raw body of an HTTP client request. Here content "ABC" can be anywhere in the packet, only "EFG" must be in HTTP client request.

alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_client_body;)

Note:

  • The http client body modifier is not allowed to be used with the rawbytes modifier for the same content.


http_cookie

The http cookie keyword is a content modifier that restricts the search to the extracted Cookie Header field of a HTTP client request or a HTTP server response. The cookie buffer also includes the header name (Cookie for HTTP requests or Set-Cookie for HTTP responses).

This keyword is dependent on the enable cookie config option. The Cookie Header field will be extracted only when this option is configured. If enable cookie is not specified, the cookie still ends up in HTTP header. When enable cookie is not specified, using http cookie is the same as using http header.

The extracted Cookie Header field may be NORMALIZED, per the configuration of HttpInspect.

Format:

      http_cookie;

Note:

  • The http cookie modifier is not allowed to be used with the rawbytes or fast pattern modifiers for the same content.


http_raw_cookie

The http raw cookie keyword is a content modifier that restricts the search to the extracted UNNORMALIZED Cookie Header field of a HTTP client request or a HTTP server response. This keyword is dependent on the enable cookie config option. The Cookie Header field will be extracted only when this option is configured.


Format:

    http_raw_cookie;

Note:

  • The http raw cookie modifier is not allowed to be used with the rawbytes, http cookie or fast pattern modifiers for the same content.


http_header

The http header keyword is a content modifier that restricts the search to the extracted Header fields of a HTTP client request or a HTTP server response. The extracted Header fields may be NORMALIZED, per the configuration of HttpInspect.

Format:

    http_header;

Note:

  • The http header modifier is not allowed to be used with the rawbytes modifier for the same content.


http_raw_header

The http raw header keyword is a content modifier that restricts the search to the extracted UNNORMALIZED Header fields of a HTTP client request or a HTTP server response.

Format:

    http_raw_header;

Note:

  • The http raw header modifier is not allowed to be used with the rawbytes, http header or fast pattern modifiers for the same content.


http_method

The http method keyword is a content modifier that restricts the search to the extracted Method from a HTTP client request.

Format

    http_method;

Note:

  • The http method modifier is not allowed to be used with the rawbytes modifier for the same content.


http_uri

The http uri keyword is a content modifier that restricts the search to the NORMALIZED request URI field. Using a content rule option followed by a http uri modifier is the same as using a uricontent by itself.

Format:

    http_uri;

Note:

  • The http uri modifier is not allowed to be used with the rawbytes modifier for the same content.


http_raw_uri

The http raw uri keyword is a content modifier that restricts the search to the UNNORMALIZED request URI field.

Format:

    http_raw_uri;

Note:

  • The http raw uri modifier is not allowed to be used with the rawbytes, http uri or fast pattern modifiers for the same content.


http_stat_code

The http stat code keyword is a content modifier that restricts the search to the extracted Status code field from a HTTP server response. The Status Code field will be extracted only if the extended reponse inspection is configured for the HttpInspect.

Format:

    http_stat_code;

Note:

  • The http stat code modifier is not allowed to be used with the rawbytes or fast pattern modifiers for the same content.


http_stat_msg

The http stat msg keyword is a content modifier that restricts the search to the extracted Status Message field from a HTTP server response. The Status Message field will be extracted only if the extended reponse inspection is configured for the HttpInspect.


Format:

    http_stat_msg;

Note:

  • The http stat msg modifier is not allowed to be used with the rawbytes or fast pattern modifiers for the same content.


fast_pattern

The fast pattern keyword is a content modifier that sets the content within a rule to be used with the fast pattern matcher. Since the default behavior of fast pattern determination is to use the longest content in the rule, it is useful if a shorter content is more ”unique” than the longer content, meaning the shorter content is less likely to be found in a packet than the longer content.

The fast pattern matcher is used to select only those rules that have a chance of matching by using a content in the rule for selection and only evaluating that rule if the content is found in the payload. Though this may seem to be overhead, it can significantly reduce the number of rules that need to be evaluated and thus increases performance. The better the content used for the fast pattern matcher, the less likely the rule will needlessly be evaluated.

As this keyword is a modifier to the previous content keyword, there must be a content rule option in the rule before fast pattern is specified. The fast pattern option may be specified only once per rule.


Note:

  • The fast pattern modifier cannot be used with the following http content modifiers: http cookie, http raw uri, http raw header, http raw cookie, http stat code, http stat msg. Note, however, that it is okay to use the fast pattern modifier if another http content modifier not mentioned above is used in combination with one of the above to modify the same content.


Format:

The fast pattern option can be used alone or optionally take arguments. When used alone, the meaning is simply to use the specified content as the fast pattern content for the rule.

fast_pattern;


The optional argument 'only' can be used to specify that the content should only be used for the fast pattern matcher and should not be evaluated as a rule option. This is useful, for example, if a known content must be located in the payload independent of location in the payload, as it saves the time necessary to evaluate the rule option. Note:

  • The modified content must be case insensitive since patterns are inserted into the pattern matcher in a case insensitive manner
  • Negated contents cannot be used
  • Contents cannot have any positional modifiers such as offset, depth, distance or within.
fast_pattern:only;


The optional argument '<offset>,<length>' can be used to specify that only a portion of the content should be used for the fast pattern matcher. This is useful if the pattern is very long and only a portion of the pattern is necessary to satisfy ”uniqueness” thus reducing the memory required to store the entire pattern in the fast pattern matcher.

fast_pattern:<offset>,<length>;

Note:

  • The optional arguments only and <offset>,<length> are mutually exclusive.


Examples:

  • This rule causes the pattern ”IJKLMNO” to be used with the fast pattern matcher, even though it is shorter than the earlier pattern ”ABCDEFGH”.
alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern;)
  • This rule says to use the content ”IJKLMNO” for the fast pattern matcher and that the content should only be used for the fast pattern matcher and not evaluated as a content rule option.
alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; nocase; fast_pattern:only;)
  • This rule says to use ”JKLMN” as the fast pattern content, but still evaluate the content rule option as ”IJKLMNO”. Also Only "JKLMN" will be used by fast pattern matcher to determine whether entire rule should be processed with full normal content match and other condition tests or not.
alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern:1,5;)



uricontent

The uricontent keyword in the Snort rule language searches the NORMALIZED request URI field. This is equivalent to using the http uri modifier to a content keyword. As such if you are writing rules that include things that are normalized, such as %2f or directory traversals, these rules will not alert. The reason is that the things you are looking for are normalized out of the URI buffer.

For example, the URI:

      /scripts/..%c0%af../winnt/system32/cmd.exe?/c+ver

will get normalized into:

      /winnt/system32/cmd.exe?/c+ver

Another example, the URI:

      /cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f?

will get normalized into:

      /cgi-bin/phf?

When writing a uricontent rule, write the content that you want to find in the context that the URI will be normalized. For example, if Snort normalizes directory traversals, do not include directory traversals. You can write rules that look for the non-normalized content by using the content option. uricontent can be used with several of the modifiers available to the content keyword. These include 'nocase', 'depth', 'offset', 'distance', 'within, 'fast pattern'

This option works in conjunction with the HTTP Inspect preprocessor.

Format:

      uricontent:[!]"<content string>";

Note:

  • uricontent cannot be modified by a rawbytes modifier or any of the other HTTP modifiers. If you wish to search the UNNORMALIZED request URI field, use the http raw uri modifier with a content option.



urilen

The urilen keyword in the Snort rule language specifies the exact length, the minimum length, the maximum length, or range of URI lengths to match.


Format:

    urilen:min<>max;
    urilen:[<|>]<number>;


isdataat

Verify that the payload has data at a specified location, optionally looking for data relative to the end of the previous content match.

Format:

     isdataat:[!]<int>[, relative|rawbytes];


Example:

     alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative; content:!"|0a|"; within:50;)

This rule looks for the string PASS exists in the packet, then verifies there is at least 50 bytes after the end of the string PASS, then verifies that there is not a newline character within 50 bytes of the end of the PASS string.

When the rawbytes modifier is specified with isdataat, it looks at the raw packet data, ignoring any decoding that was done by the preprocessors. This modifier will work with the relative modifier as long as the previous content match was in the raw packet data.

A ! modifier negates the results of the isdataat test. It will alert if a certain amount of data is not present within the payload. For example, the rule with modifiers 'content:"foo"; isdataat:!10,relative;' would alert if there were not 10 bytes after ”foo” before the payload ended.



One can refer to Snort Manual for various other payload rules options not described here or for more description / examples on payload rule options described on this page. 'byte_test', 'byte_jump' and 'byte_extract' not covered here can be of interest.


Home > CentOS > CentOS 6.x > Security tools > Snort configuration > Snort payload rule options