Search Site

Search Rules

Account

email
password

not registered?

can't login?

user preferences

Example

preprocessor http_inspect_server: server 1.1.1.1 profile all ports { 80 3128 }

ports $\{ <$port$> [<$port$> <...>] \}$

This is how the user configures which ports to decode on the HTTP server. Encrypted traffic (SSL) cannot be decoded, so adding port 443 will only yield encoding false positives.

iis_unicode_map $<$map_filename$>$ codemap $<$integer$>$

The IIS Unicode map is generated by the program ms_unicode_generator.c. This program is located on the Snort.org web site at http://www.snort.org/dl/contrib/ directory. Executing this program generates a Unicode map for the system that it was run on. So, to get the specific Unicode mappings for an IIS web server, you run this program on that server and use that Unicode map in this configuration.

When using this option, the user needs to specify the file that contains the IIS Unicode map and also specify the Unicode map to use. For US servers, this is usually 1252. But the ms_unicode_generator program tells you which codemap to use for you server; it's the ANSI code page. You can select the correct code page by looking at the available code pages that the ms_unicode_generator outputs.

flow_depth $<$integer$>$

This specifies the amount of server response payload to inspect. This option significantly increases IDS performance because we are ignoring a large part of the network traffic (HTTP server response payloads). A small percentage of Snort rules are targeted at this traffic and a small flow_depth value may cause false negatives in some of these rules. Most of these rules target either the HTTP header, or the content that is likely to be in the first hundred or so bytes of non-header data. Headers are usually under 300 bytes long, but your mileage may vary.

This value can be set from -1 to 1460. A value of -1 causes Snort to ignore all server side traffic for ports defined in ports. Inversely, a value of 0 causes Snort to inspect all HTTP server payloads defined in ports (note that this will likely slow down IDS performance). Values above 0 tell Snort the number of bytes to inspect in the first packet of the server response.

ascii $<$yes$\vert$no$>$

The ascii decode option tells us whether to decode encoded ASCII chars, a.k.a %2f = /, %2e = ., etc. It is normal to see ASCII encoding usage in URLs, so it is recommended that you disable HTTP Inspect alerting for this option.

utf_8 $<$yes$\vert$no$>$

The utf-8 decode option tells HTTP Inspect to decode standard UTF-8 Unicode sequences that are in the URI. This abides by the Unicode standard and only uses % encoding. Apache uses this standard, so for any Apache servers, make sure you have this option turned on. As for alerting, you may be interested in knowing when you have a UTF-8 encoded URI, but this will be prone to false positives as legitimate web clients use this type of encoding. When utf_8 is enabled, ASCII decoding is also enabled to enforce correct functioning.

u_encode $<$yes$\vert$no$>$

This option emulates the IIS %u encoding scheme. How the %u encoding scheme works is as follows: the encoding scheme is started by a %u followed by 4 characters, like %uxxxx. The xxxx is a hex-encoded value that correlates to an IIS Unicode codepoint. This value can most definitely be ASCII. An ASCII character is encoded like %u002f = /, %u002e = ., etc. If no iis_unicode_map is specified before or after this option, the default codemap is used.

You should alert on %u encodings, because we are not aware of any legitimate clients that use this encoding. So it is most likely someone trying to be covert.

bare_byte $<$yes$\vert$no$>$

Bare byte encoding is an IIS trick that uses non-ASCII characters as valid values when decoding UTF-8 values. This is not in the HTTP standard, as all non-ASCII values have to be encoded with a %. Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings correctly.

The alert on this decoding should be enabled, because there are no legitimate clients that encode UTF-8 this way since it is non-standard.

base36 $<$yes$\vert$no$>$

This is an option to decode base36 encoded chars. This option is based on of info from http://www.yk.rim.or.jp/ shikap/patch/spp_http_decode.patch.

If %u encoding is enabled, this option will not work. You have to use the base36 option with the utf_8 option. Don't use the %u option, because base36 won't work. When base36 is enabled, ASCII encoding is also enabled to enforce correct behavior.

iis_unicode $<$yes$\vert$no$>$

The iis_unicode option turns on the Unicode codepoint mapping. If there is no iis_unicode_map option specified with the server config, iis_unicode uses the default codemap. The iis_unicode option handles the mapping of non-ASCII codepoints that the IIS server accepts and decodes normal UTF-8 requests.

You should alert on the iis_unicode option, because it is seen mainly in attacks and evasion attempts. When iis_unicode is enabled, ASCII and UTF-8 decoding are also enabled to enforce correct decoding. To alert on UTF-8 decoding, you must enable also enable utf_8 yes.

double_decode $<$yes$\vert$no$>$ The double_decode option is once again IIS-specific and emulates IIS functionality. How this works is that IIS does two passes through the request URI, doing decodes in each one. In the first pass, it seems that all types of iis encoding is done: utf-8 unicode, ascii, bare byte, and %u. In the second pass, the following encodings are done: ascii, bare byte, and %u. We leave out utf-8 because I think how this works is that the % encoded utf-8 is decoded to the Unicode byte in the first pass, and then UTF-8 is decoded in the second stage. Anyway, this is really complex and adds tons of different encodings for one character. When double_decode is enabled, so ASCII is also enabled to enforce correct decoding.

non_rfc_char $\{ <$byte$> [<$byte ...$>] \}$

This option lets users receive an alert if certain non-RFC chars are used in a request URI. For instance, a user may not want to see null bytes in the request URI and we can alert on that. Please use this option with care, because you could configure it to say, alert on all `/' or something like that. It's flexible, so be careful.

multi_slash $<$yes$\vert$no$>$

This option normalizes multiple slashes in a row, so something like: ``foo/////////bar'' get normalized to ``foo/bar.''

If you want an alert when multiple slashes are seen, then configure with a yes; otherwise, use no.

iis_backslash $<$yes$\vert$no$>$

Normalizes backslashes to slashes. This is again an IIS emulation. So a request URI of ``/foo$\backslash$bar'' gets normalized to ``/foo/bar.''

directory $<$yes$\vert$no$>$

This option normalizes directory traversals and self-referential directories.

The directory:

 /foo/fake\_dir/../bar

gets normalized to:

 /foo/bar

The directory:

 /foo/./bar

gets normalized to:

 /foo/bar

If you want to configure an alert, specify yes, otherwise, specify no. This alert may give false positives, since some web sites refer to files using directory traversals.

apache_whitespace $<$yes$\vert$no$>$

This option deals with the non-RFC standard of using tab for a space delimiter. Apache uses this, so if the emulated web server is Apache, enable this option. Alerts on this option may be interesting, but may also be false positive prone.

iis_delimiter $<$yes$\vert$no$>$

This started out being IIS-specific, but Apache takes this non-standard delimiter was well. Since this is common, we always take this as standard since the most popular web servers accept it. But you can still get an alert on this option.

chunk_length $<$non-zero positive integer$>$

This option is an anomaly detector for abnormally large chunk sizes. This picks up the Apache chunk encoding exploits, and may also alert on HTTP tunneling that uses chunk encoding.

no_pipeline_req

This option turns HTTP pipeline decoding off, and is a performance enhancement if needed. By default, pipeline requests are inspected for attacks, but when this option is enabled, pipeline requests are not decoded and analyzed per HTTP protocol field. It is only inspected with the generic pattern matching.

non_strict

This option turns on non-strict URI parsing for the broken way in which Apache servers will decode a URI. Only use this option on servers that will accept URIs like this: "get /index.html alsjdfk alsj lj aj la jsj s$\backslash$n". The non_strict option assumes the URI is between the first and second space even if there is no valid HTTP identifier after the second space.

allow_proxy_use

By specifying this keyword, the user is allowing proxy use on this server. This means that no alert will be generated if the proxy_alert global keyword has been used. If the proxy_alert keyword is not enabled, then this option does nothing. The allow_proxy_use keyword is just a way to suppress unauthorized proxy use for an authorized server.

no_alerts

This option turns off all alerts that are generated by the HTTP Inspect preprocessor module. This has no effect on HTTP rules in the rule set. No argument is specified.

oversize_dir_length $<$non-zero positive integer$>$

This option takes a non-zero positive integer as an argument. The argument specifies the max char directory length for URL directory. If a url directory is larger than this argument size, an alert is generated. A good argument value is 300 characters. This should limit the alerts to IDS evasion type attacks, like whisker -i 4.

inspect_uri_only

This is a performance optimization. When enabled, only the URI portion of HTTP requests will be inspected for attacks. As this field usually contains 90-95% of the web attacks, you'll catch most of the attacks. So if you need extra performance, enable this optimization. It's important to note that if this option is used without any uricontent rules, then no inspection will take place. This is obvious since the URI is only inspected with uricontent rules, and if there are none available, then there is nothing to inspect.

For example, if we have the following rule set:

alert tcp any any -> any 80 ( msg:"content"; content: "foo"; )

and the we inspect the following URI:

get /foo.htm http/1.0\r\n\r\n

No alert will be generated when inspect_uri_only is enabled. The inspect_uri_only configuration turns off all forms of detection except uricontent inspection.

webroot $<$yes$\vert$no$>$

This option generates an alert when a directory traversal traverses past the web server root directory. This generates much fewer false positives than the directory option, because it doesn't alert on directory traversals that stay within the web server directory structure. It only alerts when the directory traversals go past the web server root directory, which is associated with certain web attacks.

tab_uri_delimiter

This option turns on the use of the tab character (0x09) as a delimiter for a URI. Apache accepts tab as a delimiter; IIS does not. For IIS, a tab in the URI should be treated as any other character. Whether this option is on or not, a tab is treated as whitespace if a space character (0x20) precedes it. No argument is specified.

site feedback | Terms of Use | Privacy Policy | forum archives ©2008 Snort and Sourcefire are registered trademarks of Sourcefire, Inc. All rights reserved.