HTTP Inspect is a generic HTTP decoder for user applications. Given a data buffer, HTTP Inspect will decode the buffer, find HTTP fields, and normalize the fields. HTTP Inspect works on both client requests and server responses.
HTTP Inspect has a very ;SPMldquo;rich;SPMrdquo; user configuration. Users can configure individual HTTP servers with a variety of options, which should allow the user to emulate any type of web server. Within HTTP Inspect, there are two areas of configuration: global and server.
The global configuration deals with configuration options that determine the global functioning of HTTP Inspect. The following example gives the generic global configuration format:
verbatim266#
You can only have a single global configuration, you'll get an error if you try otherwise.
This is the global iis_unicode_map file. The iis_unicode_map is a required configuration parameter. The map file can reside in the same directory as snort.conf or be specified via a fully-qualified path to the map file.
The iis_unicode_map file is a Unicode codepoint map which tells HTTP Inspect which codepage to use when decoding Unicode characters. For US servers, the codemap is usually 1252.
A Microsoft US Unicode codepoint map is provided in the Snort source etc directory by default. It is called unicode.map and should be used if no other codepoint map is available. A tool is supplied with Snort to generate custom Unicode maps--ms_unicode_generator.c, which is available at http://www.snort.org/dl/contrib/.
Remember that this configuration is for the global IIS Unicode map, individual
servers can reference their own IIS Unicode map.
This global configuration option enables generic HTTP server traffic inspection
on non-HTTP configured ports, and alerts if HTTP traffic is seen. Don't turn
this on if you don't have a default server configuration that encompasses all
of the HTTP server ports that your users might access. In the future, we want
to limit this to specific networks so it's more useful, but for right now, this
inspects all network traffic. This option is turned off by default.
This enables global alerting on HTTP server proxy usage. By configuring HTTP
Inspect servers and enabling allow_proxy_use, you will only receive
proxy use alerts for web users that aren't using the configured proxies or are
using a rogue proxy server.
Please note that if users aren't required to configure web proxy use, then you
may get a lot of proxy alerts. So, please only use this feature with
traditional proxy environments. Blind firewall proxies don't count.
Please note, in case of multiple policies, the value specified in the default policy
is used and this value overwrites the values specified in the other policies. In case
of unlimited_decompress this should be set to its max value. This value should
be specified in the default policy even when the HTTP inspect preprocessor is turned off
using the disabled keyword.
Please note, in case of multiple policies, the value specified in the default policy
is used and this value overwrites the values specified in the other policies. In case
of unlimited_decompress this should be set to its max value. This value should
be specified in the default policy even when the HTTP inspect preprocessor is turned off
using the disabled keyword.
This option determines (in bytes) the maximum amount of memory the HTTP Inspect preprocessor
will use for decompression. The minimum allowed value for this option is 3276 bytes. This option
determines the number of concurrent sessions that can be decompressed at any given instant.
The default value for this option is 838860.
This value is also used for the optional SWF/PDF file decompression. If these modes are enabled
this same value sets the maximum about of memory used for file decompression session state
information.
This value should be specified in the default policy even when the HTTP inspect preprocessor is
turned off using the disabled keyword.
This option determines (in bytes) the maximum amount of memory the HTTP Inspect preprocessor
will use for logging the URI and Hostname data. This value can be set from 2304 to 603979776 (576 MB).
This option along with the maximum uri and hostname logging size (which is defined in snort) will
determine the maximum HTTP sessions that will log the URI and hostname data at any given instant. The
maximum size for logging URI data is 2048 and for hostname is 256. The default value for this
option is 150994944 (144 MB).
This value should be specified in the default policy even when the HTTP inspect preprocessor is turned off
using the disabled keyword. In case of multiple policies, the value specified in the
default policy will overwrite the value specified in other policies.
max http sessions logged = memcap /( max uri logging size + max hostname logging size )
max uri logging size defined in snort : 2048
max hostname logging size defined in snort : 256
This optional keyword is allowed with any policy to avoid packet processing.
This option disables the preprocessor. When the preprocessor is disabled
only the ;SPMquot;memcap;SPMquot;, ;SPMquot;max_gzip_mem;SPMquot;, ;SPMquot;compress_depth;SPMquot; and ;SPMquot;decompress_depth;SPMquot;
options are applied when specified with the configuration. Other options are
parsed but not used. Any valid configuration may have ;SPMquot;disabled;SPMquot; added to it.
verbatim267#
There are two types of server configurations: default and by IP address.
This configuration supplies the default server configuration for any server that is not individually configured. Most of your web servers will most likely end up using the default configuration.
verbatim268#
This format is very similar to ;SPMldquo;default;SPMrdquo;, the only difference being that specific IPs can be configured.
verbatim269#
This format is very similar to ;SPMldquo;Configuration by IP Address;SPMrdquo;, the only difference being that multiple IPs can be specified via a space separated list. There is a limit of 40 IP addresses or CIDR notations per http_inspect_server line.
verbatim270#
Important: Some configuration options have an argument of `yes' or `no'. This argument specifies whether the user wants the configuration option to generate an HTTP Inspect alert or not. The `yes/no' argument does not specify whether the configuration option itself is on or off, only the alerting functionality. In other words, whether set to `yes' or 'no', HTTP normalization will still occur, and rules based on HTTP traffic will still trigger.
Users can configure HTTP Inspect by using pre-defined HTTP server profiles. Profiles allow the user to easily configure the preprocessor for a certain type of server, but are not required for proper operation.
There are five profiles available: all, apache, iis, iis5_0, and iis4_0.
The all profile is meant to normalize the URI using most of the common
tricks available. We alert on the more serious forms of evasions. This is a
great profile for detecting all types of attacks, regardless of the HTTP
server. profile all sets the configuration options described in Table
#profile_all_options#1224>
| Option | Setting | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
|---|---|---|---|---|
| server_flow_depth | 300 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| client_flow_depth | 300 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| post_depth | 0 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| chunk encoding | alert on chunks larger than 500000 bytes | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| iis_unicode_map | codepoint map in the global configuration | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| ASCII decoding | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| multiple slash | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| directory normalization | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| apache whitespace | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| double decoding | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; | |
| bare byte decoding | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| iis unicode codepoints | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| iis backslash | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| iis delimiter | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| webroot | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| non_strict URL parsing | on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| tab_uri_delimiter | is set | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_header_length | 0, header length not checked | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_spaces | 200 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_headers | 0, number of headers not checked | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
The apache profile is used for Apache web servers. This differs from
the iis profile by only accepting UTF-8 standard Unicode encoding and
not accepting backslashes as legitimate slashes, like IIS does. Apache also
accepts tabs as whitespace. profile apache sets the configuration
options described in Table #profile_apache_options#1240>
| Option | Setting | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
|---|---|---|---|---|
| server_flow_depth | 300 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| client_flow_depth | 300 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| post_depth | 0 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| chunk encoding | alert on chunks larger than 500000 bytes | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| ASCII decoding | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| multiple slash | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| directory normalization | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| webroot | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| apache whitespace | on, alert on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| utf_8 encoding | on, alert off | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| non_strict url parsing | on | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| tab_uri_delimiter | is set | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_header_length | 0, header length not checked | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_spaces | 200 | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
| max_headers | 0, number of headers not checked | ;SPMnbsp; | ;SPMnbsp; | ;SPMnbsp; |
The iis profile mimics IIS servers. So that means we use IIS Unicode
codemaps for each server,
In IIS 4.0 and IIS 5.0, there was a double decoding vulnerability. These two
profiles are identical to iis, except they will alert by default if a
URL has a double encoding. Double decode is not supported in IIS 5.1 and
beyond, so it's disabled by default.
The default options used by HTTP Inspect do not use a profile and are described
in Table #default_HTTP_Inspect_options#1270>
Profiles must be specified as the first server option and cannot be combined
with any other options except:
These options must be specified after the profile option.
Option
Setting
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
server_flow_depth
300
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
client_flow_depth
300
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
post_depth
-1
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
chunk encoding
alert on chunks larger than 500000 bytes
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis_unicode_map
codepoint map in the global configuration
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
ASCII decoding
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
multiple slash
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
directory normalization
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
webroot
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
double decoding
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
bare byte decoding
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis unicode codepoints
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis backslash
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis delimiter
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
apache whitespace
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
non_strict URL parsing
on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_header_length
0, header length not checked
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_spaces
200
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_headers
0, number of headers not checked
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
Option
Setting
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
port
80
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
server_flow_depth
300
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
client_flow_depth
300
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
post_depth
-1
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
chunk encoding
alert on chunks larger than 500000 bytes
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
ASCII decoding
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
utf_8 encoding
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
multiple slash
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
directory normalization
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
webroot
on, alert on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis backslash
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
apache whitespace
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
iis delimiter
on, alert off
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
non_strict URL parsing
on
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_header_length
0, header length not checked
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_spaces
200
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
max_headers
0, number of headers not checked
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
verbatim271#
ports
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
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.
This option must be enabled to make use of the decompress_swf or decompress_pdf options.
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.
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
;SPMquot;extended_response_inspection;SPMquot; 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.
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'.
decompress_swf
This option will enable decompression of compressed SWF (Adobe Flash content) files
encountered as the HTTP Response body in a GET transaction. The available decompression
modes are 'deflate' and 'lzma'. A prerequisite is enabling
extended_response_inspection (described above). When enabled, the preprocessor will
examine the response body for the corresponding file signature. 'CWS' for Deflate/ZLIB
compressed and 'ZWS' for LZMA compressed. Each decompression mode can be individually enabled.
e.g. ... <#1338#> lzma <#1338#> or <#1339#> deflate <#1339#> or <#1340#> lzma deflate <#1340#>. The compressed content is decompressed
'in-place' with the content made available to the detection/rules 'file_data' option.
If enabled and located, the compressed SWF file signature is converted to 'FWS' to indicate
an uncompressed file.
The 'decompress_depth', 'compress_depth', and 'unlimited_decompress' are optionally used to
place limits on the decompression process. The semantics for SWF files are similar to the
gzip decompression process.
During the decompression process, the preprocessor may generate alert 120:12 if Deflate
decompression fails or alert 120:13 if LZMA decompression fails.
decompress_pdf
This option will enable decompression of the compressed portions of PDF files encountered
as the HTTP Response body in a GET transaction. A prerequisite is enabling
extended_response_inspection (described above).
When enabled, the preprocessor will examine the response body for the '
The 'decompress_depth', 'compress_depth', and 'unlimited_decompress' are optionally used to
place limits on the decompression process. The semantics for PDF files are similar to the
gzip decompression process.
During the file parsing/decompression process, the preprocessor may generate several alerts:
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
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.
The default X-Forwarded-For and True-Client-IP headers are always present. They may be explicitly
specified in the xff_headers config in order to determine their priority. If not specified, they
will be automatically added to the xff list as the lowest priority headers.
For example, let us say that we have the following (abbreviated) HTTP request header:
With the default xff behavior (no xff_headers), the 'X-Forwarded-For' header would be used to
provide a 192.168.1.1 Original Client IP address in the unified2 log. Custom headers are not
parsed.
With:
The X-Was-Originally-Forwarded-From header is the highest priority present and its value
of 10.1.1.1 will be logged as the Original Client IP in the unified2 log.
But with:
Now the X-Forwarded-For header is the highest priority and its value of 192.168.1.1 is logged.
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.
server_flow_depth
This specifies the amount of server response payload to inspect. When
extended_response_inspection is turned on, it is applied to the HTTP response
body (decompressed data when inspect_gzip is turned on) and not the HTTP headers.
When extended_response_inspection is turned off the server_flow_depth
is applied to the entire HTTP response (including headers). Unlike 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 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 ports when
extended_response_inspection is turned off. When the 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 ;SPMquot;ports;SPMquot; (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 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 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 server_flow_depth to its maximum value.
server_flow_depth is the same as the old flow_depth
option, which will be deprecated in a future release.
client_flow_depth
This specifies the amount of raw client request payload to inspect. This
value can be set from -1 to 1460. Unlike 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 ;SPMquot;ports.;SPMquot; Inversely, a value of 0 causes Snort to inspect all HTTP client
side traffic defined in ;SPMquot;ports;SPMquot; (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 client_flow_depth to its maximum value.
post_depth
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.
ascii
The ascii decode option tells us whether to decode encoded ASCII
chars, a.k.a
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.
utf_8
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
u_encode
This option emulates the IIS
You should alert on
bare_byte
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
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.
iis_unicode
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
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
non_rfc_char
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
This option normalizes multiple slashes in a row, so something like:
;SPMldquo;foo/////////bar;SPMrdquo; get normalized to ;SPMldquo;foo/bar.;SPMrdquo;
If you want an alert when multiple slashes are seen, then configure with a
yes; otherwise, use no.
iis_backslash
Normalizes backslashes to slashes. This is again an IIS emulation. So a
request URI of ;SPMldquo;/foo
directory
This option normalizes directory traversals and self-referential directories.
The directory:
gets normalized to:
The directory:
gets normalized to:
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
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
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
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 {
This option is an evasion detector for consecutive small chunk sizes when
either the client or server use Transfer-Encoding: chunked.
Example:
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: ;SPMquot;get /index.html alsjdfk alsj lj aj la jsj s
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
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
For example, if we have the following rule set:
and the we inspect the following URI:
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
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 ;SPMquot;Long Header;SPMquot; 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
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
;SPMquot;Space Saturation;SPMquot; 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
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 (i.e.,
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 (i.e., 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 ;SPMquot;utf-16le;SPMquot;, ;SPMquot;utf-16be;SPMquot;, ;SPMquot;utf-32le;SPMquot;, or
;SPMquot;utf-32be;SPMquot;. HTTP Inspect will attempt to normalize these back into 8-bit encoding,
generating an alert if the extra bytes are non-zero.
max_headers
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 ;SPMquot;Max Header;SPMquot; 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
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.
Stream 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.
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
;SPMquot;Host;SPMquot; header of the HTTP request and log it along with all the generated events
for that session. Stream 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 ;SPMquot;Host;SPMquot; headers within one HTTP request, a preprocessor alert with sid 24 is
generated. The maximum hostname length logged is 256.
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.
legacy_mode
By default, HTTP2 traffic is not supported. You can use ;SPMquot;legacy_mode no;SPMquot;
to enable HTTP2 support.
If http legacy mode is configured, HTTP2 inspection is disabled.
Alert
Description
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
120:14
Deflate decompression failure
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
120:15
Located a 'stream' with an unsupported compression ('/Filter') algorithm
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
120:16
Located a 'stream' with unsupported cascaded '/FlateDecode' options, e.g.:
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
120:17
PDF File parsing error
;SPMnbsp;
;SPMnbsp;
;SPMnbsp;
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.
Meaning alert if we see 5 consecutive chunk sizes of 10 or less.
2.2.7.10 Examples