Selecting Server-Level HTTP Normalization Options
License:
Protection
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. For information on using IPv4 CIDR notation and IPv6 prefix lengths in the ASA FirePOWER module, see IP Address Conventions.
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).
Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.
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 for this option. See Setting Rule States for more information.
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. See HTTP Content Options for more information.
You can specify a value from -1 to 1460. Cisco recommends that you set client flow depth to its maximum value. Specify any of the following:
– From 1 to 1460 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 1460 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. See HTTP Content Options for more information.
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 a value from -1 to 65535. Cisco recommends that you set the server flow depth to its maximum value. You can specify any of the following:
– From 1 to 65535:
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. The value of 0 disables this option. Specify a value from 1 to 65535 to enable it.
You can enable rule 119:19 to generate events for this option. See Setting Rule States for more information.
Maximum Number of Headers
Detects when the number of headers exceeds this setting in an HTTP request. Specify a value from 1 to 1024 to enable it.
You can enable rule 119:20 to generate events for this option. See Setting Rule States for more information.
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 value from 1 to 65535 to enable it.
You can enable rule 119:26 to generate events for this option. See Setting Rule States for more information.
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. See HTTP Content Options for more information.
Specify a value from -1 to 65495. 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 from 0 to 65495 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 value of 1 to 255. 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 trigger events 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. See Setting Rule States for more information.
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. See HTTP Content Options. You can enable rule 119:31 to generate events when a method other than GET, POST, or a method configured for this option is encountered in traffic.
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. For more information, see HTTP Content Options, Generating Events on the HTTP Encoding Type and Location, and Pointing to a Specific Payload Type.
You can enable rules 120:2 and 120:3 to generate events for this option. See Setting Rule States for more information.
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 for this option. See Setting Rule States for more information.
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; see Pointing to a Specific Payload Type for more information.
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. See Selecting Global HTTP Normalization Options.
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
keyword to point intrusion rules to the normalized Javascript data. See Pointing to a Specific Payload Type for more information.
You can enable rules 120:9, 120:10, and 120:11 to generate events for this option, as follows:
Table 22-6 Normalize Javascript Option Rules
|
Triggers an event 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.
|
See Setting Rule States for more information.
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
rule keyword to inspect decompressed data; see Pointing to a Specific Payload Type for more information.
You can enable rules 120:12 and 120:13 to generate events for this option, as follows:
Table 22-7 Decompress SWF File Option Rules
|
Triggers an event 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
rule keyword to inspect decompressed data; see Pointing to a Specific Payload Type for more information.
You can enable rules 120:14, 120:15, 120:16, and 120:17 to generate events for this option, as follows:
Table 22-8 Decompress PDF File (Deflate) Option Rules
|
Triggers an event 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 intrusion events for this option.
XFF Header Priority
If
Extract Original Client IP Address
is enabled, 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. See Viewing Events for more information.
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. See Viewing Events for more information.
You can enable rule 119:25 to generate events for this option. See Setting Rule States for more information.
Note that when the preprocessor and rule 119:24 are enabled, the preprocessor generates an intrusion event if it detects multiple Host headers in an HTTP request, regardless of the setting for this option. See Enabling Additional HTTP Inspect Preprocessor Rules for more information.
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. See Selecting Server-Level HTTP Normalization Encoding Options for more information.
Selecting Server-Level HTTP Normalization Encoding Options
License:
Protection
You can select server-level HTTP normalization options to specify the types of encoding that are normalized for HTTP traffic, and to cause the system to generate events against traffic containing this type of encoding.
If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.
ASCII Encoding
Decodes encoded ASCII characters and specifies whether the rules engine generates an event on ASCII-encoded URIs.
You can enable rule 119:1 to generate events for this option. See Setting Rule States for more information.
UTF-8 Encoding
Decodes standard UTF-8 Unicode sequences in the URI.
You can enable rule 119:6 to generate events for this option. See Setting Rule States for more information.
Microsoft %U Encoding
Decodes the IIS %u encoding scheme that uses %u followed by four characters where the 4 characters are a hex encoded value that correlates to an IIS Unicode codepoint.
Tip Legitimate clients rarely use %u encodings, so Cisco recommends decoding HTTP traffic encoded with %u encodings.
You can enable rule 119:3 to generate events for this option. See Setting Rule States for more information.
Bare Byte UTF-8 Encoding
Decodes bare byte encoding, which uses non-ASCII characters as valid values in decoding UTF-8 values.
Tip Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings correctly. Cisco recommends enabling this option because no legitimate clients encode UTF-8 this way.
You can enable rule 119:4 to generate events for this option. See Setting Rule States for more information.
Microsoft IIS Encoding
Decodes using Unicode codepoint mapping.
Tip Cisco recommends enabling this option, because it is seen mainly in attacks and evasion attempts.
You can enable rule 119:7 to generate events for this option. See Setting Rule States for more information.
Double Encoding
Decodes IIS double encoded traffic by making two passes through the request URI performing decodes in each one. Cisco recommends enabling this option because it is usually found only in attack scenarios.
You can enable rule 119:2 to generate events for this option. See Setting Rule States for more information.
Multi-Slash Obfuscation
Normalizes multiple slashes in a row into a single slash.
You can enable rule 119:8 to generate events for this option. See Setting Rule States for more information.
IIS Backslash Obfuscation
Normalizes backslashes to forward slashes.
You can enable rule 119:9 to generate events for this option. See Setting Rule States for more information.
Directory Traversal
Normalizes directory traversals and self-referential directories. If you enable the accompanying preprocessor rules to generate events against this type of traffic, it may generate false positives because some web sites refer to files using directory traversals.
You can enable rules 119:10 and 119:11 to generate events for this option. See Setting Rule States for more information.
Tab Obfuscation
Normalizes the non-RFC standard of using a tab for a space delimiter. Apache and other non-IIS web servers use the tab character (0x09) as a delimiter in URLs.
Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab as white space if a space character (0x20) precedes it.
You can enable rule 119:12 to generate events for this option. See Setting Rule States for more information.
Invalid RFC Delimiter
Normalizes line breaks (\n) in URI data.
You can enable rule 119:13 to generate events for this option. See Setting Rule States for more information.
Webroot Directory Traversal
Detects directory traversals that traverse past the initial directory in the URL.
You can enable rule 119:18 to generate events for this option. See Setting Rule States for more information.
Tab URI Delimiter
Turns on the use of the tab character (0x09) as a delimiter for a URI. Apache, newer versions of IIS, and some other web servers use the tab character as a delimiter in URLs.
Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab as white space if a space character (0x20) precedes it.
Non-RFC characters
Detects the non-RFC character list you add in the corresponding field when it appears within incoming or outgoing URI data. When modifying this field, use the hexadecimal format that represents the byte character. If and when you configure this option, set the value with care. Using a character that is very common may overwhelm you with events.
You can enable rule 119:14 to generate events for this option. See Setting Rule States for more information.
Max Chunk Encoding Size
Detects abnormally large chunk sizes in URI data.
You can enable rules 119:16 and 119:22 to generate events for this option. See Setting Rule States for more information.
Disable Pipeline Decoding
Disables HTTP decoding for pipelined requests. When this option is disabled, performance is enhanced because HTTP requests waiting in the pipeline are not decoded or analyzed, and are only inspected using generic pattern matching.
Non-Strict URI Parsing
Enables non-strict URI parsing. Use this option only on servers that will accept non-standard URIs in the format "GET /index.html abc xo qr \n". Using this option, the decoder assumes that the URI is between the first and second space, even if there is no valid HTTP identifier after the second space.
Extended ASCII Encoding
Enables parsing of extended ASCII characters in an HTTP request URI. Note that this option is available in custom server profiles only, and not in the default profiles provided for Apache, IIS, or all servers.
Configuring HTTP Server Options
License:
Protection
Use the following procedure to configure HTTP server options. For more information on the HTTP server options, see Selecting Server-Level HTTP Normalization Options and Selecting Server-Level HTTP Normalization Encoding Options.
To configure server-level HTTP configuration options:
Step 1 Select
Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy
.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the
Advanced
tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Network Analysis and Intrusion Policies
.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click
Network Analysis Policy List
.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon (
) next to the policy you want to edit.
If you have unsaved changes in another policy, click
OK
to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 7 Click
Settings
in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether
HTTP Configuration
under Application Layer Preprocessors is enabled:
-
If the configuration is enabled, click
Edit
.
-
If the configuration is disabled, click
Enabled
, then click
Edit
.
The HTTP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 9 You have two options:
-
Add a new server profile. Click the add icon (
) next to
Servers
on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses for the client in the
Server Address
field and click
OK
.
You can specify a single IP address or address block, or a comma-separated list of either or both. You can include up to 496 characters in a list, specify a total of 256 address entries for all server profiles, and create a total of 255 profiles including the default profile. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions.
Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, and zones handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.
A new entry appears in the list of servers on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the profile you added.
-
Modify the settings for an existing profile. Click the configured address for a profile you have added under
Servers
on the left side of the page, or click
default
.
Your selection is highlighted and the Configuration section updates to display the current configuration for the profile you selected. To delete an existing profile, click the delete icon (
) next to the profile you want to remove.
Step 10 Optionally, modify the address or addresses listed in the
Networks
field and click any other area of the page.
The highlighted address updates on the left side of the page.
Note that you cannot modify the setting for
Networks
in the default profile. The default profile applies to all servers on your network that are not identified in another profile.
Step 11 In the
Ports
field, list the ports whose traffic you want to inspect with HTTP Inspect. Separate multiple ports with commas.
Step 12 You can modify any of the other options described in Selecting Server-Level HTTP Normalization Options.
Step 13 Select a server profile as follows:
-
Select
Custom
to create your own server profile (see Selecting Server-Level HTTP Normalization Encoding Options for more information).
-
Select
All
to use the standard default profile, appropriate for all servers.
-
Select
IIS
to use the default IIS profile.
-
Select
Apache
to use the default Apache profile.
Step 14 If you selected
Custom
, the custom options appear.
Step 15 Configure the HTTP decoding options you want in your profile.
See Selecting Server-Level HTTP Normalization Options for details on available normalization options.
Step 16 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.