Applies To:

Show Versions Show Versions

Manual Chapter: Fine-tuning HTTP Security Profiles
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Overview: Increasing HTTP traffic security

The HTTP security profile consists of many different security checks for the various components of HTTP traffic. This implementation shows you how to fine-tune your HTTP security profile as required by your environment. The custom checks are described under the assumption that you have already created a custom HTTP security profile but have no other prerequisite or special order. You need configure only the custom checks that you are interested in.

You can achieve a greater level of security when you configure Protocol Security Module to perform the following checks:

  • HTTP Protocol Checks that are related to RFC compliance and actions to take resulting from a violation
  • Request Checks such as length, allowable HTTP request methods, inclusion or exclusion of files by type, and custom headers that must occur in every request
  • Response Checks that look for and mask sensitive data (response scrubbing)
  • Blocking Page configuration in the event of a block request when a violation is encountered as defined by you
  • XML Defense validation of code in HTTP requests

About RFC compliance and validation checks

When Protocol Security Module receives a request from a client, the first request that the system validates for HTTP traffic is RFC protocol compliance. If a request passes the compliance checks, the system applies the security profile to the remainder of the request. So that your system fully validates RFC compliance, keep all of these default checks enabled:

  • Several Content-Length headers: This security check fails when the incoming request contains more than one content-length header. (Enabled by default)
  • Null in request: This security check fails when the incoming request contains a null character. (Enabled by default)
  • Unparsable request content: This security check fails when the Protocol Security Module is unable to parse the incoming request. (Enabled by default)

Modifying HTTP protocol compliance checks

F5 Networks recommends that you retain the default properties for the HTTP protocol security checks. This task allows you to take additional precautions such as enabling the Block flag for the HTTP Protocol Checks setting, even if you enable only the Alarm flag for the other security checks. When you do this, the system blocks all requests that are not compliant with HTTP protocol standards, and performs additional security checks only on valid HTTP traffic.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you are modifying. The Profile Properties screen opens showing the HTTP Protocol Checks.
  3. On the HTTP Protocol Checks tab, for the HTTP Protocol Checks setting, select the check boxes for the protocol checks that you want the system to validate.
  4. For the Alarm or Block settings, modify the blocking policy settings for each violation.
    • Alarm: The system logs any requests that trigger the violation.
    • Block: The system blocks any requests that trigger the violation.
    • Alarm and Block: The system both logs and blocks any requests that trigger the violation.
  5. Click Update to retain changes.
The BIG-IP system is now enabled for compliance checks on all valid HTTP traffic.

Monitoring URLs and headers for XSS/SQL-injection attacks

Protocol Security Module® uses attack signatures to check for certain patterns in incoming request headers and URLs (including query string parameters), as a way of identifying cross-site scripting (XSS) or SQL injection attacks. If the system detects an XSS or SQL injection attack, an XSS/SQL-injection attack detected violation occurs. You can configure the system so that it logs the request data associated with the violation.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to enable an XSS/SQL-injection attack alarm. The Profile Properties screen opens.
  3. On the HTTP Protocol Checks tab, for the XSS/SQL-Injection Attack Checks setting, select the Alarm check box to log requests that trigger the XSS/SQL-injection attack detected violation. (No option to block these attacks is available.)
  4. Click Update to retain changes.
The page you configured is displayed every time one of the security checks set to Block has been violated.

About configuring evasion techniques checks

For every HTTP request that the Protocol Security Module receives, the system examines requests for methods of application attack that are designed to avoid detection. These coding methods, called evasion techniques, trigger the Evasion technique detected violation. The Protocol Security Module can detect many evasion techniques such as these:

  • Directory traversal, for example, a/b/../c turns into a/c
  • Multiple decoding passes
  • Multiple backslash characters in a URI, for example, \\servername
  • Bare byte decoding (higher than ASCII-127) in a URI
  • Apache whitespace characters (0x09, 0x0b, or 0x0c)
  • Bad unescape

Configuring HTTP protocol evasion techniques blocking policy

Protocol Security Module enables you to detect, log, alarm, and block evasion techniques detected in HTTP traffic by choosing the Evasion techniques detected setting in a custom security profile you create.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you are modifying. The Profile Properties screen opens showing the HTTP Protocol Checks.
  3. On the HTTP Protocol Checks tab, for the Evasion Techniques Checks setting, select or clear the Alarm or Block check boxes as required.
    Option Description
    Alarm The system logs any requests that trigger the violation.
    Block The system blocks any requests that trigger the violation.
    Alarm and Block The system both logs and blocks any requests that trigger the violation.
  4. Click Update to retain changes.

Securing HTTP traffic by establishing protocol request checks

In the HTTP security profile, on the Requests Checks tab, you can specify the following types of checks that the system performs on HTTP traffic:

  • Length checks: Specify valid maximum lengths for request components to help prevent buffer overflow attacks.
  • Method checks: Specify which HTTP methods the system allows in requests.
  • File type checks: Specify which file types users can or cannot access.
  • Mandatory headers: Specify custom headers that must occur in every request.
  • Null in request: This security check fails when the incoming request contains a null character. (Enabled by default)
  • Unparsable request content: This security check fails when the Protocol Security Module is unable to parse the incoming request. (Enabled by default)

Configuring length checks for HTTP traffic

With Protocol Security Module ™ you can specify valid maximum lengths for request components in HTTP security profiles to prevent buffer overflow attacks. You can set maximum lengths for URLs, query strings, POST data, and the entire request.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to configure length checking. The Profile Properties screen opens.
  3. Click the Request Checks tab.
  4. For each option of the Length Checks setting, specify Any to allow any length or click Length and specify the maximum length you want to allow
  5. Select or clear the Alarm or Block check boxes as required.
    Option Description
    Alarm The system logs any requests that trigger the violation.
    Block The system blocks any requests that trigger the violation.
    Alarm and Block The system both logs and blocks any requests that trigger the violation.
  6. For the Request Length Exceeds Defined Buffer Size setting, select or clear Alarm and Block.
    Option Description
    Alarm The system logs any requests that are longer than allowed by the long_request_buffer_size internal parameter (the default is 10,000,000 bytes).
    Block The system blocks any requests that are longer than allowed by the long_request_buffer_size internal parameter (the default is 10,000,000 bytes).
    Alarm and Block The system both logs and blocks any requests that trigger the violation.
    Important: If you selected Alarm or Block for the Request Length Exceeds Defined Buffer Size setting, you must enforce XSS/SQL-injection attack checks by selecting Alarm for XSS/SQL-Injection Attack Checks in the HTTP Protocol Checks area.
  7. Click Update to retain changes.

Enforcing XSS/SQL-injection attack checks

Protocol Security Module™ uses attack signatures to check for certain patterns in incoming request headers and URLs as a way of identifying cross-site scripting (XSS) or SQL injection attacks. Enforcing XSS/SQL-injection attack checks is also useful in prevention of buffer overflow attacks by allowing the BIG-IP® system to examine the HTTP traffic payload to ensure that the buffer length specified complies with what you have configured.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to enable an XSS/SQL-injection attack alarm. The Profile Properties screen opens.
  3. On the HTTP Protocol Checks tab, for the XSS/SQL-Injection Attack Checks setting, select the Alarm check box to log requests that trigger the XSS/SQL-injection attack detected violation. (No option to block these attacks is available.)
  4. Click Update to retain changes.
The page you configured is displayed every time one of the security checks set to Block has been violated.

Specifying which HTTP methods to allow

Protocol Security Module ™accepts certain HTTP methods by default. The default allowed methods are GET, HEAD, and POST. The system treats any incoming HTTP request that includes an HTTP method other than the allowed methods as a violating request. Later, you can decide how to handle each violation.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to modify allowable HTTP methods. The Profile Properties screen opens.
  3. Click the Request Checks tab.
  4. Using the Methods setting, specify which HTTP methods to allow:
    • From the Available list, select the methods you want to allow in a request and move them to the Allowed list.
    • To add a new method to the Available list: type the name in the Method field, click Add to add it to the list, and move it to the Allowed list.
  5. Select or clear the Alarm or Block check boxes as required.
    Option Description
    Alarm The system logs any requests that trigger the violation.
    Block The system blocks any requests that trigger the violation.
    Alarm and Block The system both logs and blocks any requests that trigger the violation.
  6. Click Update to retain changes.

Including or excluding files by type in HTTP security profiles

By default, the HTTP security profile permits all file types in a request. For tighter security, you can create a list that specifies either all file types you want to allow, or a list specifiying all the file types you do not want allowed.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to modify allowable files by type. The Profile Properties screen opens.
  3. Click the Request Checks tab.
  4. Using the File Types setting, specify whether you want to create a list of allowed or disallowed file types, and which files you want in the list:
    • To create a list of file types that are permitted in requests, select Define Allowed.
    • To create a list of file types not permitted, select Define Disallowed.
    • Select file types from the Available list, and move them to the Allowed or Disallowed list.
    • To add a new file type, type the name in the File Type field, click Add to add it to the Available list, and move it to the Allowed or Disallowed list.
    Important: If the profile is case-sensitive, the file types are case-sensitive. For example, jsp and JSP> will be treated as separate file types.
  5. Select or clear the Alarm or Block check boxes as required.
    Option Description
    Alarm The system logs any requests that trigger the Illegal file type violation.
    Block The system blocks any requests that trigger the Illegal file type violation.
    Alarm and Block The system both logs and blocks any requests that trigger the Illegal file type violation.
The page you configured is displayed every time one of the security checks set to Block has been violated.

Configuring a mandatory header for an HTTP security profile

When the BIG-IP® system is managing an application that uses custom headers that must occur in every request, you can specify mandatory HTTP headers in the security profile. The Protocol Security Module™ verifies that all requests contain those headers. If a request does not contain the mandatory header, the system issues the Mandatory HTTP header is missing violation, and takes the action that you configure: Alarm, Block, or both.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to configure a Mandatory Header alarm. The Profile Properties screen opens.
  3. Click the Request Checks tab.
  4. Use the Mandatory Headers setting to specify the heading:
    1. In the Header field, type the name of the mandatory header, and click the Add button to add it to the Available list.
    2. Move the new mandatory header from the Available list to the Mandatory list.
    3. Select or clear the Alarm or Block check boxes as required.
    Option Description
    Alarm The system logs any responses that trigger the Mandatory HTTP header is missing violation.
    Block The system blocks any requests that trigger the Mandatory HTTP header is missing violation.
    Alarm and Block The system both logs and blocks any requests that trigger the Mandatory HTTP header is missing violation.
  5. Click Update to retain changes.
All HTTP requests are checked for the mandatory headers you have selected.

Protecting sensitive data using HTTP protocol response checks

Depending on the application, a response can contain sensitive user information, such as credit card numbers, or social security numbers (U.S. only). You can configure an HTTP security profile to look for sensitive data in server responses, and to allow only specific HTTP response codes. The Data Guard response check can detect sensitive user information in the server response for all URLs, or for ones you specify. You can also decide which HTTP response codes are acceptable in a server response.

Configuring response scrubbing with Data Guard

When the BIG-IP® system detects sensitive information in a response, and you have configured the Data Guard settings, an Information leakage detected violation occurs. Additionally, if you have enabled the Block action, the response containing the sensitive information is not sent to the client; instead the system sends the Protocol Security Module™ blocking page.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to enable Data Guard. The Profile Properties screen opens.
  3. Click the Response Checks tab.
  4. Select the Enable Data Guard check box.
  5. To identify credit card and social security numbers as sensitive in responses, select the Credit Card numbers and U.S. Social Security numbers check boxes.
  6. You may also specify a custom sensitive data pattern:
    1. Select the Enable custom patterns check box.
    2. In the New custom pattern field, type a regular expression and click Add. The new pattern is added to the list.
    3. Repeat to add as many custom patterns as you need.
  7. You may also specify an exception pattern to indicate data that you do not want to be considered sensitive:
    1. Select the Enable exception patterns check box.
    2. In the New exception pattern field, type a regular expression and click Add. The new pattern is added to the list.
    3. Repeat to add as many custom patterns as you need.
  8. If you want the system to replace sensitive data in a response with asterisks (****), select the Mask data check box .
    Important: If the Mask Data check box is cleared, sensitive data may still appear in responses.
  9. Specify which URLs to examine for sensitive data:
    • To Inspect all URLS (except any that you add to the list):
      • Use the default value of Ignore URLs in list.
      • In the New URL field, type a URL (explicit or wildcard) in the format /index.html, and click Add.
      • Repeat to add as many custom patterns as you need.
    • To check only specific URLS for sensitive data:
      • Select Enforce URLs in list.
      • In theNew URL field, type a URL (explicit or wildcard) in the format /index.html, and click Add.
      • Repeat to add as many custom patterns as you need.
  10. For the Data Guard setting, select the Alarm or Block boxes to enable the Information leakage detection violation.
    Option Description
    Alarm The system logs any responses that trigger the Information leakage detection violation, and displays them on the Protocol Security statistics screen.
    Block The system blocks any requests that trigger the Information leakage detection violation. If blocking is configured, masking has no effect on responses with leakage because the entire response is blocked.
    Alarm and Block The system both logs and blocks any requests that trigger the Information leakage detection violation.
  11. Click Update to retain changes.
The custom HTTP profile now provides response scrubbing using Data Guard.

Disabling Data Guard from an HTTP profile

If you no longer require a custom HTTP profile to enlist theBIG-IP®system in protecting sensitive information such as credit card numbers, you can remove this feature from a custom profile by disabling Data Guard settings.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to disable Data Guard. The Profile Properties screen opens.
  3. Click the Response Checks tab.
  4. Clear the Enable Data Guard check box.
  5. Click Update to retain changes.
The custom HTTP profile no longer provides response scrubbing using Data Guard.

Configuring the blocking response page for HTTP security profiles

If your security profile is set up to block requests that violate one or more of the security checks, the Protocol Security Module® displays a page, called the blocking response page, on the client’s screen. The default blocking response page states that the request was rejected, and provides a support ID. You can also configure the system to redirect the client to a specific web site instead of displaying the blocking response page.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the Profile Name column, click the name of the security profile for which you want to configure a blocking page. The Profile Properties screen opens.
  3. Click the Blocking Page tab.
  4. For the Response Type setting, select one of the options:
    • Default Response: Specifies that the system returns the system-supplied blocking response page. Though you cannot edit the HTML code on the default blocking page, you can copy it into a custom response and edit it.
    • Custom Response: Specifies that the system returns a response page that you design or upload.
    • Redirect URL: Specifies that the system redirects the client to the specified URL.
    • SOAP Fault: Specifies that the system displays a blocking page in standard SOAP fault message format. Though you cannot edit the SOAP fault code, you can copy it into a custom response and edit it.
    The settings on the screen change depending on the selection that you make for the Response Type setting.
  5. If you selected the Custom Response option, you can either create a new response or upload and HTML file.
    • To create a custom response, make the changes you want to the default responses for the Response Header and Response Body settings using HTTP syntax for the content, and click Upload.
    • To upload an HTML file for the response body, click Browse to navigate to an existing HTML response page, and Click Upload.
  6. If you selected Redirect URL, type the full path of the web page to which the system should redirect the client in the Redirect URL field.
  7. Click Update to retain changes.
The page you configured is now displayed every time one of the security checks set to Block has been violated.

Configuring XML defense

You can configure the BIG-IP system to validate XML code in requests, and specify XML data format settings for your environment, using Protocol Security Module.
  1. On the Main tab, click Protocol Security > Security Profiles > HTTP . The Security Profiles: HTTP screen opens.
  2. In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you are modifying. The Profile Properties screen opens showing the HTTP Protocol Checks.
  3. Click the XML Defense tab.
  4. Use the Check XML Content-Type Headers setting to specify whether the system validates XML data in requests based on information in the header:
    • All: Specifies that the system validates XML data found in all requests.
    • User-defined: Specifies that the system validates XML data found in requests only if the content-type header matches a specific pattern. Type the pattern in the User-defined field. The system's default pattern is *xml*
  5. In the XML Data Format Settings, for the Defense Level option, select High, Medium, or Low, to determine the default settings included for each defense level, and the types of patterns that the system protects against.
    Note: The default is Medium. You can see defaults for each level and are not required to change them. If you change any of the default settings, the system automatically changes the defense level to Custom.
  6. Below the data format settings, select one or both of the Alarm or Block check boxes.
    Option Description
    Alarm The system logs any requests that violate any of the XML data format settings.
    Block The system blocks any requests that violate any of the XML data format settings.
    Alarm and Block The system both logs and blocks any requests that violate any of the XML data format settings.
  7. For the Well-Formedness setting, select or clear the Alarm or Block check boxes.
    Option Description
    Alarm The system logs any requests that contain malformed XML data.
    Block The system blocks any requests that contain malformed XML data.
    Alarm and Block The system both logs and blocks any requests that contain malformed XML data.
  8. Click Update to retain changes.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)