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. However, HTTPS traffic is encrypted and cannot be decoded with HTTP Inspect. To ignore HTTPS traffic, use the SSL preprocessor.

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.

extended_response_inspection

This enables the extended HTTP response inspection. The default http response inspection does not inspect the various fields of a HTTP response. By turning this option the HTTP response will be thoroughly inspected. The different fields of a HTTP response such as status code, status message, headers, cookie (when enable_cookie is configured) and body are extracted and saved into buffers. Different rule options are provided to inspect these buffers.

Note:  

When this option is turned on, if the HTTP response packet has a body then any content pattern matches ( without http modifiers ) will search the response body ((decompressed in case of gzip) and not the entire packet payload. To search for patterns in the header of the response, one should use the http modifiers with content such as http_header, http_stat_code, http_stat_msg and http_cookie.

enable_cookie

This options turns on the cookie extraction from HTTP requests and HTTP response. By default the cookie inspection and extraction will be turned off. The cookie from the Cookie header line is extracted and stored in HTTP Cookie buffer for HTTP requests and cookie from the Set-Cookie is extracted and stored in HTTP Cookie buffer for HTTP responses. The Cookie: and Set-Cookie: header names itself along with leading spaces and the CRLF terminating the header line are stored in the HTTP header buffer and are not stored in the HTTP cookie buffer.

Ex: Set-Cookie: mycookie \r\n

In this case, Set-Cookie: \r\n will be in the HTTP header buffer and the pattern
mycookie will be in the HTTP cookie buffer.

inspect_gzip

This option specifies the HTTP inspect module to uncompress the compressed data(gzip/deflate) in HTTP response. You should select the config option "extended_response_inspection" before configuring this option. Decompression is done across packets. So the decompression will end when either the 'compress_depth' or 'decompress_depth' is reached or when the compressed data ends. When the compressed data is spanned across multiple packets, the state of the last decompressed packet is used to decompressed the data of the next packet. But the decompressed data are individually inspected. (i.e. the decompressed data from different packets are not combined while inspecting). Also the amount of decompressed data that will be inspected depends on the 'server_flow_depth' configured.

Http Inspect generates a preprocessor alert with gid 120 and sid 6 when the decompression fails. When the decompression fails due to a CRC error encountered by zlib, HTTP Inspect will also provide the detection module with the data that was decompressed by zlib.

Note:  

To enable compression of HTTP server response, Snort should be configured with the -enable-zlib flag.

unlimited_decompress

This option enables the user to decompress unlimited gzip data (across multiple packets).Decompression will stop when the compressed data ends or when a out of sequence packet is received. To ensure unlimited decompression, user should set the 'compress_depth' and 'decompress_depth' to its maximum values in the default policy. The decompression in a single packet is still limited by the 'compress_depth' and 'decompress_depth'.

normalize_javascript This option enables the normalization of Javascript within the HTTP response body. You should select the config option extended_response_inspection before configuring this option. When this option is turned on, Http Inspect searches for a Javascript within the HTTP response body by searching for the $<$script$>$ tags and starts normalizing it. When Http Inspect sees the $<$script$>$ tag without a type, it is considered as a javascript. The obfuscated data within the javascript functions such as unescape, String.fromCharCode, decodeURI, decodeURIComponent will be normalized. The different encodings handled within the unescape/ decodeURI/decodeURIComponent are %XX, %uXXXX,
XX and
uXXXXi. Apart from these encodings, Http Inspect will also detect the consecutive whitespaces and normalize it to a single space. Http Inspect will also normalize the plus and concatenate the strings. The rule option file_data can be used to access this normalized buffer from the rule. A preprocessor alert with SID 9 and GID 120 is generated when the obfuscation levels within the Http Inspect is equal to or greater than 2.

Example:

HTTP/1.1 200 OK\r\n
Date: Wed, 29 Jul 2009 13:35:26 GMT\r\n
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10 mod_ssl/2.2.3 OpenSSL/0.9.8c\r\n
Last-Modified: Sun, 20 Jan 2008 12:01:21 GMT\r\n
Accept-Ranges: bytes\r\n
Content-Length: 214\r\n
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: application/octet-stream\r\n\r\n 
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FIXME</title>
</head>
<body>
<script>document.write(unescape(unescape("%48%65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21")));
</script>
</body>
</html>

The above javascript will generate the preprocessor alert with SID 9 and GIDF 120 when normalize_javascript is turned on.

Http Inspect will also generate a preprocessor alert with GID 120 and SID 11 when there are more than one type of encodings within the escaped/encoded data.

For example:

unescape("%48\x65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21");
String.fromCharCode(0x48, 0x65, 0x6c, 0x6c, 111, 44, 32, 115, 110, 111, 114, 116, 32, 116, 101, 97, 109, 33)

\\end{verbatim}

The above obfuscation will generate the preprocessor alert with GID 120 and SID 11.

This option is turned off by default in HTTP Inspect.

\item \texttt{max\_javascript\_whitespaces $<$positive integer up to 65535$>$}
This option takes an integer as an argument.  The integer determines the maximum number
of consecutive whitespaces allowed within the Javascript obfuscated data in a HTTP
response body. The config option \texttt{normalize\_javascript} should be turned on before configuring
 this config option. When the whitespaces in the javascript obfuscated data is equal to or more
than this value a preprocessor alert with GID 120 and SID 10 is generated. The default value for 
this option is 200.  To enable, specify an integer argument to \texttt{max\_javascript\_spaces} of 1 to 65535.
Specifying a value of 0 is treated as disabling the alert.

\item \texttt{enable\_xff}

This option enables Snort to parse and log the original client IP present in the
X-Forwarded-For or True-Client-IP HTTP request headers along with the generated
events. The XFF/True-Client-IP Original client IP address is logged only with
unified2 output and is not logged with console (-A cmg) output.

\begin{note}

The original client IP from XFF/True-Client-IP in unified2 logs can be viewed using 
the tool u2spewfoo. This tool is present in the tools/u2spewfoo directory of snort 
source tree.

\end{note}

\item \texttt{server\_flow\_depth $<$integer$>$}

This specifies the amount of server response payload to inspect. When
\texttt{extended\_response\_inspection} is turned on, it is applied to the HTTP response 
body (decompressed data when \texttt{inspect\_gzip} is turned on) and not the HTTP headers.
When \texttt{extended\_response\_inspection} is turned off the \texttt{server\_flow\_depth} 
is applied to the entire HTTP response (including headers). Unlike \texttt{client\_flow\_depth} 
this option is applied per TCP session. This option can be used to balance the needs of 
IDS performance and level of inspection of HTTP server response data.  Snort rules are       
targeted at HTTP server response traffic and when used with a small flow\_depth value 
may cause false negatives. 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. 
It is suggested to set the \texttt{server\_flow\_depth} to its maximum value.

This value can be set from -1 to 65535. A value of -1 causes Snort
to ignore all server side traffic for ports defined in \texttt{ports} when
\texttt{extended\_response\_inspection} is turned off. When the \texttt{extended\_response\_inspection}
 is turned on, value of -1 causes Snort to ignore the HTTP response body data and
 not the HTTP headers.  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 of the server response (excluding the HTTP headers when \texttt{extended\_response\_inspection}
is turned on) in a given HTTP session.  Only packets payloads starting with 'HTTP' will
be considered as the first packet of a server response.  If less than flow\_depth bytes
are in the payload of the HTTP response packets in a given session, the entire payload will be
inspected.  If more than flow\_depth bytes are in the payload of the HTTP response packet in a session
only flow\_depth bytes of the payload will be inspected for that session.  Rules that are meant to
inspect data in the payload of the HTTP response packets in a session beyond 65535 bytes will be
ineffective unless flow\_depth is set to 0. The default value for \texttt{server\_flow\_depth} is 300.
Note that the 65535 byte maximum flow\_depth applies to stream reassembled packets as well. 
It is suggested to set the \texttt{server\_flow\_depth} to its maximum value.

\begin{note}

\texttt{server\_flow\_depth} is the same as the old \texttt{flow\_depth}
option, which will be deprecated in a future release.

\end{note}

\item \texttt{client\_flow\_depth $<$integer$>$}

This specifies the amount of raw client request payload to inspect. This
value can be set from -1 to 1460. Unlike \texttt{server\_flow\_depth} this value is applied
to the first packet of the HTTP request. It is not a session based flow depth.
It has a default value of 300.  It primarily eliminates Snort from inspecting
larger HTTP Cookies that appear at the end of many client request Headers.

A value of -1 causes Snort to ignore all client side traffic for ports
defined in "ports." Inversely, a value of 0 causes Snort to inspect all HTTP client
 side traffic 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 client request.  If less than flow\_depth bytes
are in the TCP payload (HTTP request) of the first packet, the entire payload will be inspected.
If more than flow\_depth bytes are in the payload of the first packet only flow\_depth
bytes of the payload will be inspected.  Rules that are meant to
inspect data in the payload of the first packet of a client request beyond 1460 bytes 
will be ineffective unless flow\_depth is set to 0. Note that the 1460 byte 
maximum flow\_depth applies to stream reassembled packets as well. It is 
suggested to set the \texttt{client\_flow\_depth} to its maximum value.

\item \texttt{post\_depth $<$integer$>$}

This specifies the amount of data to inspect in a client post message. The
value can be set from -1 to 65495. The default value is -1. A value of -1 
causes Snort to ignore all the data in the post message. Inversely, a value 
of 0 causes Snort to inspect all the client post message. This increases    
the performance by inspecting only specified bytes in the post message.

\item \texttt{ascii $<$yes$|$no$>$}

The \texttt{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.

\item \texttt{extended\_ascii\_uri}

This option enables the support for extended ASCII codes in the HTTP request
URI. This option is turned off by default and is not supported with any of
the profiles.

\item \texttt{utf\_8 $<$yes$|$no$>$}

The \texttt{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
\texttt{utf\_8} is enabled, ASCII decoding is also enabled to enforce correct
functioning.  

\item \texttt{u\_encode $<$yes$|$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.

\item \texttt{bare\_byte $<$yes$|$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.

\item \texttt{iis\_unicode $<$yes$|$no$>$}

The \texttt{iis\_unicode} option turns on the Unicode codepoint mapping.  If
there is no iis\_unicode\_map option specified with the server config,
\texttt{iis\_unicode} uses the default codemap.  The \texttt{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 \texttt{iis\_unicode option}, because it is seen mainly
in attacks and evasion attempts.  When \texttt{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 \texttt{utf\_8 yes}. 

\item \texttt{double\_decode $<$yes$|$no$>$}

The \texttt{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 \texttt{double\_decode} is enabled, so ASCII
is also enabled to enforce correct decoding.

\item \texttt{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.

\item \texttt{multi\_slash $<$yes$|$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
\texttt{yes}; otherwise, use \texttt{no}.

\item \texttt{iis\_backslash $<$yes$|$no$>$}

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

\item \texttt{directory $<$yes$|$no$>$}

This option normalizes directory traversals and self-referential directories.

The directory:

\begin{verbatim}
    /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.

small_chunk_length { $<$chunk size$>$ $<$consecutive chunks$>$ }

This option is an evasion detector for consecutive small chunk sizes when either the client or server use Transfer-Encoding: chunked. $<$chunk size$>$ specifies the maximum chunk size for which a chunk will be considered small. $<$consecutive chunks$>$ specifies the number of consecutive small chunks $<$= $<$chunk size$>$ before an event will be generated. This option is turned off by default. Maximum values for each are 255 and a $<$chunk size$>$ of 0 disables. Events generated are gid:119, sid:26 for client small chunks and gid:120, sid:7 for server small chunks.

Example:

small_chunk_length { 10 5 }

Meaning alert if we see 5 consecutive chunk sizes of 10 or less.

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.

max_header_length $<$positive integer up to 65535$>$

This option takes an integer as an argument. The integer is the maximum length allowed for an HTTP client request header field. Requests that exceed this length will cause a "Long Header" alert. This alert is off by default. To enable, specify an integer argument to max_header_length of 1 to 65535. Specifying a value of 0 is treated as disabling the alert.

max_spaces $<$positive integer up to 65535$>$

This option takes an integer as an argument. The integer determines the maximum number of whitespaces allowed with HTTP client request line folding. Requests headers folded with whitespaces equal to or more than this value will cause a "Space Saturation" alert with SID 26 and GID 119. The default value for this option is 200. To enable, specify an integer argument to max_spaces of 1 to 65535. Specifying a value of 0 is treated as disabling the alert.

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.

normalize_headers

This option turns on normalization for HTTP Header Fields, not including Cookies (using the same configuration parameters as the URI normalization (ie, multi-slash, directory, etc.). It is useful for normalizing Referrer URIs that may appear in the HTTP Header.

normalize_cookies

This option turns on normalization for HTTP Cookie Fields (using the same configuration parameters as the URI normalization (ie, multi-slash, directory, etc.). It is useful for normalizing data in HTTP Cookies that may be encoded.

normalize_utf

This option turns on normalization of HTTP response bodies where the Content-Type header lists the character set as "utf-16le", "utf-16be", "utf-32le", or "utf-32be". HTTP Inspect will attempt to normalize these back into 8-bit encoding, generating an alert if the extra bytes are non-zero.

max_headers $<$positive integer up to 1024$>$

This option takes an integer as an argument. The integer is the maximum number of HTTP client request header fields. Requests that contain more HTTP Headers than this value will cause a "Max Header" alert. The alert is off by default. To enable, specify an integer argument to max_headers of 1 to 1024. Specifying a value of 0 is treated as disabling the alert.

http_methods $\{ cmd [cmd] \}$ This specifies additional HTTP Request Methods outside of those checked by default within the preprocessor (GET and POST). The list should be enclosed within braces and delimited by spaces, tabs, line feed or carriage return. The config option, braces and methods also needs to be separated by braces.

    http_methods { PUT CONNECT }

Note:  

Please note the maximum length for a method name is 256.

log_uri

This option enables HTTP Inspect preprocessor to parse the URI data from the HTTP request and log it along with all the generated events for that session. Stream5 reassembly needs to be turned on HTTP ports to enable the logging. If there are multiple HTTP requests in the session, the URI data of the most recent HTTP request during the alert will be logged. The maximum URI logged is 2048.

Note:  

Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

log_hostname

This option enables HTTP Inspect preprocessor to parse the hostname data from the "Host" header of the HTTP request and log it along with all the generated events for that session. Stream5 reassembly needs to be turned on HTTP ports to enable the logging. If there are multiple HTTP requests in the session, the Hostname data of the most recent HTTP request during the alert will be logged. In case of multiple "Host" headers within one HTTP request, a preprocessor alert with sid 24 is generated. The maximum hostname length logged is 256.

Note:  

Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.