You can set server-level options for each server you monitor,
globally for all servers, or for a list of servers. Additionally, you can use a
predefined server profile to set these options, or you can set them
individually to meet the needs of your environment. Use these options, or one
of the default profiles that set these options, to specify the HTTP server
ports whose traffic you want to normalize, the amount of server response
payload you want to normalize, and the types of encoding you want to normalize.
If no preprocessor rule is mentioned in the following
descriptions, the option is not associated with a preprocessor rule.
Networks
Use this option to specify the IP address of one or more
servers. You can specify a single IP address or address block, or a
comma-separated list comprised of either or both.
In addition to a limit of up to 255 total profiles, including
the default profile, you can include up to 496 characters, or approximately 26
entries, in an HTTP server list, and specify a total of 256 address entries for
all server profiles.
Note
|
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal IP addresses to
constrain this configuration can have unexpected results.
Using override-enabled objects allows descendant domain administrators to tailor Global configurations to their local environments.
|
Note that the
default
setting in the default policy specifies all IP
addresses on your monitored network segment that are not covered by another
target-based policy. Therefore, you cannot and do not need to specify an IP
address or CIDR block/prefix length for the default policy, and you cannot
leave this setting blank in another policy or use address notation to represent
any
(for example, 0.0.0.0/0 or ::/0).
Ports
The ports whose HTTP traffic the preprocessor engine normalizes.
Separate multiple port numbers with commas.
Oversize Dir
Length
Detects URL directories longer than the specified value.
You can enable rule 119:15 to generate events and, in an inline deployment, drop offending packets when the preprocessor detects a request for a URL that is longer than the specified length.
Client Flow
Depth
Specifies the number of bytes for rules to inspect in raw HTTP
packets, including header and payload data, in client-side HTTP traffic defined
in
Ports. Client flow depth does not apply when HTTP
content rule options within a rule inspect specific parts of a request message.
Specify any of the following:
-
A positive value inspects the specified number of bytes in the
first packet. If the first packet contains fewer bytes than specified, inspect
the entire packet. Note that the specified value applies to both segmented and
reassembled packets.
Note also that a value of 300 typically eliminates inspection of
large HTTP Cookies that appear at the end of many client request headers.
-
0 inspects all client-side traffic, including multiple packets
in a session and exceeding the upper byte limit if necessary. Note that this
value is likely to affect performance.
-
-1 ignores all client-side traffic.
Server Flow
Depth
Specifies the number of bytes for rules to inspect in raw HTTP
packets in server-side HTTP traffic specified by
Ports. Inspection includes the raw header and
payload when Inspect HTTP Responses
disabled and only the raw response body when
Inspect HTTP Response is enabled.
Server flow depth specifies the number of bytes of raw server
response data in a session for rules to inspect in server-side HTTP traffic
defined in
Ports. You can use this option to balance
performance and the level of inspection of HTTP server response data. Server
flow depth does not apply when HTTP content options within a rule inspect
specific parts of a response message.
Unlike client flow depth, server flow depth specifies the number
of bytes per HTTP response, not per HTTP request packet, for rules to inspect.
You can specify any of the following:
-
A positive value:
When
Inspect HTTP Responses is
enabled, inspects only the raw HTTP response body, and not
raw HTTP headers; also inspects decompressed data when
Inspect Compressed Data is enabled.
When
Inspect HTTP Responses is
disabled, inspects the raw packet header and payload.
If the session includes fewer response bytes than specified,
rules fully inspect all response packets in a given session, across multiple
packets as needed. If the session includes more response bytes than specified,
rules inspect only the specified number of bytes for that session, across
multiple packets as needed.
Note that a small flow depth value may cause false negatives
from rules that target server-side traffic defined in
Ports. Most of these rules target either the HTTP
header or 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 header size may
vary.
Note also that the specified value applies to both segmented and
reassembled packets.
-
0 inspects the entire packet for all HTTP server-side traffic
defined in
Ports, including response data in a session that
exceeds 65535 bytes.
Note that this value is likely to affect performance.
-
-1:
When
Inspect HTTP Responses is
enabled, inspects only raw HTTP headers and not the raw HTTP
response body.
When
Inspect HTTP Responses is
disabled, ignores all server-side traffic defined in
Ports.
Maximum Header
Length
Detects a header field longer than the specified maximum number
of bytes in an HTTP request; also in HTTP responses when
Inspect HTTP Responses is enabled. A value of 0
disables this option. Specify a positive value to enable it.
You can enable rule 119:19 to generate events and, in an inline deployment, drop offending packets for this option. See Setting Intrusion Rule States..
Maximum Number
of Headers
Detects when the number of headers exceeds this setting in an
HTTP request. A value of 0 disables this option. Specify a positive value to
enable it.
You can enable rule 119:20 to generate events and, in an inline deployment, drop offending packets for this option. See Setting Intrusion Rule States..
Maximum Number
of Spaces
Detects when the number of white spaces in a folded line equals
or exceeds this setting in an HTTP request. A value of 0 disables this option.
Specify a positive value to enable it.
You can enable rule 119:26 to generate events and, in an inline deployment, drop offending packets for this option. See Setting Intrusion Rule States..
HTTP Client Body Extraction Depth
Specifies the number of bytes to extract from the message body of an HTTP client request. You can use an intrusion rule to
inspect the extracted data by selecting the content
or protected_content
keyword HTTP Client Body option.
Specify -1 to ignore the client body. Specify 0 to extract the entire client body. Note that identifying specific bytes to
extract can improve system performance. Note also that you must specify a value greater than or equal to 0 for the HTTP Client Body option to function in an intrusion rule.
Small Chunk
Size
Specifies the maximum number of bytes at which a chunk is
considered small. Specify a positive value. A value of 0 disables detection of
anomalous consecutive small segments. See the
Consecutive Small Chunks option for more
information.
Consecutive
Small Chunks
Specifies how many consecutive small chunks represent an
abnormally large number in client or server traffic that uses chunked transfer
encoding. The
Small Chunk Size option specifies the maximum size
of a small chunk.
For example, set
Small Chunk Size to 10 and
Consecutive Small Chunks to 5 to detect 5
consecutive chunks of 10 bytes or less.
You can enable preprocessor rule 119:27 to generate events and, in an inline deployment, drop offending packets on excessive small chunks in client traffic, and rule 120:7 in server traffic. When Small Chunk Size is enabled and this option is set to 0 or 1, enabling these rules would trigger an event on every chunk of the specified
size or less.
HTTP
Methods
Specifies HTTP request methods in addition to GET and POST that
you expect the system to encounter in traffic. Use a comma to separate multiple
values.
Intrusion rules use the content
or protected_content
keyword with the HTTP Method argument to search for content in HTTP methods. You can enable rule 119:31to generate events and, in an inline deployment, drop offending packets when a method other than GET, POST, or a method configured for this option is encountered in traffic. See Setting Intrusion Rule States.
No
Alerts
Disables intrusion events when accompanying preprocessor rules
are enabled.
Note
|
This option does
not disable HTTP standard text rules and shared object
rules.
|
Normalize HTTP
Headers
When
Inspect HTTP Responses is enabled, enables
normalization of non-cookie data in request and response headers. When
Inspect HTTP Responses is
not enabled, enables normalization of the entire HTTP
header, including cookies, in request and response headers.
Inspect HTTP
Cookies
Enables extraction of cookies from HTTP request headers. Also
enables extraction of set-cookie data from response headers when
Inspect HTTP Responses is enabled. Disabling this
option when cookie extraction is not required can improve performance.
Note that the
Cookie:
and
Set-Cookie:
header names, leading spaces on the header
line, and the
CRLF
that terminates the header line are inspected as
part of the header and not as part of the cookie.
Normalize
Cookies in HTTP headers
Enables normalization of cookies in HTTP request headers. When
Inspect HTTP Responses is enabled, also enables
normalization of set-cookie data in response headers. You must select
Inspect HTTP Cookies before selecting this options.
Allow HTTP
Proxy Use
Allows the monitored web server to be used as an HTTP proxy.
This option is used only in the inspection of HTTP requests.
Inspect URI
Only
Inspects only the URI portion of the normalized HTTP request
packet.
Inspect HTTP
Responses
Enables extended inspection of HTTP responses so, in addition to
decoding and normalizing HTTP request messages, the preprocessor extracts
response fields for inspection by the rules engine. Enabling this option causes
the system to extract the response header, body, status code, and so on, and
also extracts set-cookie data when
Inspect HTTP Cookies is enabled.
You can enable rules 120:2 and 120:3 to generate events and, in an inline deployment, drop offending packets, as follows:
Table 6. Inspect HTTP Response Rules
This rule...
|
Triggers when...
|
120:2
|
an invalid HTTP response status code occurs.
|
120:3
|
an HTTP response does not include Content-Length or Transfer-Encoding.
|
Normalize UTF
Encodings to UTF-8
When
Inspect HTTP Responses is enabled, detects UTF-16LE,
UTF-16BE, UTF-32LE, and UTF32-BE encodings in HTTP responses and normalizes
them to UTF-8.
You can enable rule 120:4 to generate events and, in an inline deployment, drop offending packets when UTF normalization fails.
Inspect
Compressed Data
When
Inspect HTTP Responses is enabled, enables
decompression of gzip and deflate-compatible compressed data in the HTTP
response body, and inspection of the normalized decompressed data. The system
inspects chunked and non-chunked HTTP response data. The system inspects
decompressed data packet by packet across multiple packets as needed; that is,
the system does not combine the decompressed data from different packets for
inspection. Decompression ends when
Maximum Compressed Data Depth,
Maximum Decompressed Data Depth, or the end of the
compressed data is reached. Inspection of decompressed data ends when
Server Flow Depth is reached unless you also select
Unlimited Decompression. You can use the
file_data
rule keyword to inspect decompressed data.
You can enable rules 120:6 and 120:24 to generate events and, in an inline deployment, drop offending packets, as follows:
Table 7. Inspect Compressed HTTP Response Rules
This rule...
|
Triggers when...
|
120:6
|
decompression of a compressed HTTP response fails.
|
120:24
|
partial decompression of a compressed HTTP response fails.
|
Unlimited
Decompression
When
Inspect Compressed Data (and, optionally,
Decompress SWF File (LZMA),
Decompress SWF File (Deflate), or
Decompress PDF File (Deflate)) is enabled, overrides
Maximum Decompressed Data Depth across multiple
packets; that is, this option enables unlimited decompression across multiple
packets. Note that enabling this option does not affect
Maximum Compressed Data Depth or
Maximum Decompressed Data Depth within a single
packet. Note also that enabling this option sets
Maximum Compressed Data Depth and
Maximum Decompressed Data Depth to 65535 when you
commit your changes.
Normalize
Javascript
When
Inspect HTTP Responses is enabled, enables detection
and normalization of Javascript within the HTTP response body. The preprocessor
normalizes obfuscated Javascript data such as the unescape and decodeURI
functions and the String.fromCharCode method. The preprocessor normalizes the
following encodings within the unescape, decodeURI, and decodeURIComponent
functions:
-
%XX
-
%uXXXX
-
0xXX
-
\xXX
-
\uXXXX
The preprocessor detects consecutive white spaces and normalizes
them into a single space. When this option is enabled, a configuration field
allows you to specify the maximum number of consecutive white spaces to permit
in obfuscated Javascript data. You can enter a value from 1 to 65535. The value
0 disables event generation, regardless of whether the preprocessor rule
(120:10) associated with this field is enabled.
The preprocessor also normalizes the Javascript plus (+)
operator and concatenates strings using the operator.
You can use the
file_data
intrusion rule keyword to point intrusion
rules to the normalized Javascript data.
You can enable rules 120:9, 120:10, and 120:11 to generate events and, in an inline deployment, drop offending packets, as follows:
Table 8. Normalize Javascript Option Rules
This rule...
|
Triggers when...
|
120:9
|
the obfuscation level within the preprocessor is greater than or
equal to 2.
|
120:10
|
the number of consecutive white spaces in the Javascript
obfuscated data is greater than or equal to the value configured for the
maximum number of consecutive white spaces allowed.
|
120:11
|
escaped or encoded data includes more than one type of encoding.
|
Decompress SWF
File (LZMA) and Decompress SWF File (Deflate)
When
HTTP Inspect Responses is enabled, these options
decompress the compressed portions of files located within the HTTP response
body of HTTP requests.
Note
|
You can
only
decompress the compressed portions of files found in HTTP GET
responses.
|
-
Decompress SWF File
(LZMA) decompresses the LZMA-compatible compressed portions of
Adobe ShockWave Flash (.swf
) files
-
Decompress SWF File
(Deflate) decompresses the deflate-compatible compressed portions
of Adobe ShockWave Flash (.swf
) files
Decompression ends when
Maximum Compressed Data Depth,
Maximum Decompressed Data Depth, or the end of the
compressed data is reached. Inspection of decompressed data ends when
Server Flow Depth is reached unless you also select
Unlimited Decompression. You can use the
file_data
intrusion rule keyword to inspect
decompressed data.
You can enable rules 120:12 and 120:13 to generate events and, in an inline deployment, drop offending packets, as follows:
Table 9. Decompress SWF File Option Rules
This rule...
|
Triggers when...
|
120:12
|
deflate file decompression fails.
|
120:13
|
LZMA file decompression fails.
|
Decompress PDF
File (Deflate)
When
HTTP Inspect Responses is enabled,
Decompress PDF File (Deflate) decompresses the
deflate-compatible compressed portions of Portable Document Format (.pdf
) files located within the HTTP response body of
HTTP requests. The system can only decompress PDF files with the
/FlateDecode
stream filter. Other stream filters
(including
/FlateDecode /FlateDecode
) are unsupported.
Note
|
You can
only
decompress the compressed portions of files found in HTTP GET
responses.
|
Decompression ends when
Maximum Compressed Data Depth,
Maximum Decompressed Data Depth, or the end of the
compressed data is reached. Inspection of decompressed data ends when
Server Flow Depth is reached unless you also select
Unlimited Decompression. You can use the
file_data
intrusion rule keyword to inspect
decompressed data.
You can enable rules 120:14, 120:15, 120:16, and 120:17 to generate events and, in an inline deployment, drop offending packets, as follows:
Table 10. Decompress PDF File (Deflate) Option Rules
This rule...
|
Triggers when...
|
120:14
|
file decompression fails.
|
120:15
|
file decompression fails due to an unsupported compression type.
|
120:16
|
file decompression fails due to an unsupported PDF stream
filter.
|
120:17
|
file parsing fails.
|
Extract
Original Client IP Address
Enables the examination of original client IP addresses during intrusion inspection. The system extracts the original client
IP address from the X-Forwarded-For (XFF), True-Client-IP, or custom HTTP headers you define in the XFF Header Priority option. You can view the extracted original client IP address in the intrusion events table.
You can enable rules 119:23, 119:29, and 119:30 to generate events and, in an inline deployment, drop offending packets for this option. See Setting Intrusion Rule States..
XFF Header Priority
Specifies the order in which the system processes original client IP headers when multiple headers are present in an HTTP
request. By default, the system examines X-Forwarded-For (XFF) headers, then True-Client-IP headers. Use the up and down arrow
icons beside each header type to adjust its priority.
This option also allows you to specify original client IP headers other than XFF or True-Client-IP for extraction and evaluation.
Click Add to add custom header names to the priority list. The system only supports custom headers that use the same syntax as an XFF
or True-Client-IP header.
Keep in mind the following when configuring this option:
-
The system uses this priority order when evaluating original client IP address headers for both access control and intrusion
inspection.
-
If multiple original client IP headers are present, the system processes only the header with the highest priority.
-
The XFF header contains a list of IP addresses, which represent the proxy servers through which the request has passed. To
prevent spoofing, the system uses the last IP address in the list (that is, the address appended by the trusted proxy) as
the original client IP address.
Log
URI
Enables extraction of the raw URI, if present, from HTTP request
packets and associates the URI with all intrusion events generated for the
session.
When this option is enabled, you can display the first fifty
characters of the extracted URI in the HTTP URI column of the intrusion events
table view. You can display the complete URI, up to 2048 bytes, in the packet
view.
Log
Hostname
Enables extraction of the host name, if present, from the HTTP
request Host header and associates the host name with all intrusion events
generated for the session. When multiple Host headers are present, extracts the
host name from the first header.
When this option is enabled, you can display the first fifty
characters of the extracted host name in the HTTP Hostname column of the
intrusion events table view. You can display the complete host name, up to 256
bytes, in the packet view.
You can enable rule 119:25 to generate events and, in an inline deployment, drop offending packets for this option. See Setting Intrusion Rule States.
Note that, when enabled, rule 119:24 triggers if it detects multiple Host headers in an HTTP request, regardless of the setting
for this option.
Profile
Specifies the types of encoding that are normalized for HTTP
traffic. The system provides a default profile appropriate for most servers,
default profiles for Apache servers and IIS servers, and custom default
settings that you can tailor to meet the needs of your monitored traffic:
-
Select
All to use the
standard default profile, appropriate for all servers.
-
Select
IIS to use the
system-provided IIS profile.
-
Select
Apache to use
the system-provided Apache profile.
-
Select
Custom to
create your own server profile.