Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Security for HTTP Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

With the Protocol Security Module, you can configure an HTTP security profile so that it performs the following security checks on HTTP traffic:
For the HTTP security profile, you can also specify how you want the system to respond when it encounters a violation. If the system detects a violation and you enabled the Block flag for that violation, instead of forwarding the request, the Protocol Security Module can either send a blocking response page or redirect the client to a different location.
The easiest method for initiating HTTP protocol security for your HTTP virtual server traffic is to use the system default settings. You do this by enabling protocol security for the system-supplied HTTP service profile, and then associating that service profile with a virtual server.
1.
In the navigation pane, expand Local Traffic, and then click Profiles.
The HTTP Profiles screen opens.
2.
In the Name column, click HTTP.
The Properties screen for the system-supplied HTTP profile opens.
3.
Check the Protocol Security box to enable HTTP security checks.
The system automatically associates a default HTTP security profile with the system-supplied HTTP service profile.
4.
Click Update.
Next, you can associate the HTTP service profile with a virtual server so that HTTP protocol checks are performed on the traffic that the HTTP virtual server receives. Refer to Configuring an HTTP virtual server, for more information.
The rest of this chapter explains how to manually configure HTTP security. You can find out how to create a customized HTTP security profile and tailor it to your companys needs.
If the default system configuration does not meet the requirements of your environment, you can manually configure HTTP security and traffic management. Following is an overview of the steps you need to follow:
In Protocol Security Module, create an HTTP security profile, then fine-tune it so it protects HTTP traffic the way you want it to:
An HTTP service profile, created in Local Traffic Manager, optimizes HTTP traffic in the LAN. The HTTP service profile uses the HTTP security profile to detect potential security risks specific to the protocol.
Note: For details about profiles, refer to the Understanding Profiles chapter in the Configuration Guide for BIG-IP® Local Traffic Manager. For information specific to the HTTP service profile, refer to Configuring HTTP standard profile settings, in the Managing Application Layer Traffic chapter in the same guide.
1.
In the navigation pane, expand Local Traffic and click Profiles.
The HTTP Profiles screen opens.
2.
Click the Create button.
The New HTTP Profile screen opens.
3.
For the Name setting, type a unique name for the profile.
4.
For the Parent Profile setting, select an existing HTTP profile from which you want the new profile to inherit settings. The default setting is http.
5.
Click the Custom check box.
The system activates the editing mode for the individual settings.
6.
Click the Protocol Security check box.
8.
Click Finished.
The screen refreshes and displays the new HTTP service profile in the list.
The HTTP security profile specifies the security checks that apply to HTTP traffic, and that you want the system to enforce. In the security profile, you can also configure remote logging and trusted XFF headers.
If the Application Security Manager is deployed behind an internal or other trusted proxy, enable the Trust XFF Header option to accept X-Forwarded-For headers in a request. In this case, the Application Security Manager uses the IP address that initiated the connection to the proxy instead of the internal proxys IP address for the request.
1.
In the navigation pane, expand the Protocol Security section and click Security Profiles.
The HTTP Security Profiles screen opens.
2.
Click the Create button.
The New Security Profile screen opens showing the HTTP Protocol Checks tab.
3.
In the Profile Properties area, in the Profile Name box, type a unique name for the profile.
4.
Check the Remote Logging box if you want to enable remote logging for this security profile.
Note: The Remote Logging check box is only available if you have configured the remote logging server. See Configuring remote logging.
a)
Check the Trust XFF Header box.
The screen refreshes and provides an additional setting
b)
In the New Custom XFF Header box, type the header that you want the system to trust, then click Add. You can add up to five custom XFF headers.
If you do not enable either Alarm or Block for a protocol check, the system does not perform the corresponding security verification.
Enable Alarm if you want the system to log any requests that trigger the security profile violation.
Enable Block if you want the system to block requests that trigger the security profile violation.
Enable both Alarm and Block if you want the system to perform both actions.
Tip: In the configuration area, point to the Info icon to the left of the security check name for a description of the check.
9.
Click Create.
The screen refreshes, and you see the new security profile in the list.
The HTTP security profile consists of many different security checks for the various components of HTTP traffic. You can either use the default settings for the security checks, or you can fine-tune your HTTP security profile as required by your environment.
The first security checks that Protocol Security Module performs are those related to RFC compliance for the HTTP protocol. If a request passes the compliance checks, the system applies the security profile to the remainder of the request. You can also configure whether the system generates alarms or blocks requests, for requests that trigger the HTTP protocol compliance failed violation.
For an HTTP profile, on the HTTP Protocol Checks tab, you can configure which HTTP protocol validations the system should check for and what action to take when it detects a request that is not formatted properly. Each check is described in the online help.
When Protocol Security Module receives a request from a client, the first aspect of the request that the system validates is HTTP protocol compliance. If the following HTTP protocol validations are not enabled and a request violates one of them, the system may not detect other violations, so F5 Networks recommends keeping these 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)
F5 Networks recommends that you retain the default properties for the HTTP protocol security checks. As an additional precaution, you may want to enable 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.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens showing the HTTP Protocol Checks.
4.
Click Update to retain any changes you may have made.
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:
Directory traversal, for example, a/b/../c turns into a/c
Apache whitespace (0x09, 0x0b, or 0x0c)
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
3.
In the Defense Configuration area, on the HTTP Protocol Checks tab, for the Evasion Techniques Checks setting, check or clear the Alarm or Block check boxes as required.
Enable Alarm if you want the system to log any requests that trigger the Evasion technique detected violation.
Enable Block if you want the system to block any requests that trigger the Evasion technique detected violation.
Enable both Alarm and Block if you want the system to perform both actions.
4.
Click Update to save your changes.
The system 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.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
3.
In the Defense Configuration area, on the HTTP Protocol Checks tab, for the XSS/SQL-Injection Attack Checks setting, check Alarm to log requests that trigger the XSS/SQL-injection attack detected violation. (No option to block these attacks is available.)
4.
Click Update to save your changes.
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.
You can specify valid maximum lengths for request components in the HTTP security profile. As a result, the Protocol Security Module can help prevent buffer overflow attacks. You can set maximum lengths for URLs, query strings, POST data, and the entire request.
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For each of the Length Checks settings, specify Any to allow any length, or click Length and specify the maximum length you want to allow.
5.
Check or clear the Alarm or Block check boxes as required.
Check Alarm if you want the system to log any requests that trigger length violations.
Check Block if you want the system to block any requests that trigger length violations.
Check both Alarm and Block if you want the system to perform both actions.
6.
For the Request Length Exceeds Defined Buffer Size setting, check or clear Alarm and Block.
Check Alarm if you want the system to log any requests that are longer than allowed by the long_request_buffer_size internal parameter (the default is 10,000,000 bytes).
Check Block if you want the system to block any requests that are longer than allowed by the long_request_buffer_size internal parameter (the default is 10,000,000 bytes).
Check both Alarm and Block if you want the system to perform both actions.
7.
Click Update to retain your request check changes.
The 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.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For the Methods setting, select the methods you want to allow in a request from the Available list, and move them to the Allowed list.
5.
To add a new method to the Available list: type the name in the Method box, click Add to add it to the list, and move it to the Allowed list.
6.
Check or clear the Alarm or Block check boxes as required.
Check Alarm if you want the system to log any requests that trigger the Illegal method violation.
Check Block if you want the system to block any requests that trigger the Illegal method violation.
Check both Alarm and Block if you want the system to perform both actions.
7.
Click Update to retain your request check changes.
By default, the HTTP security profile permits all file types in a request. For tighter security, you can create either an allowed file types list or a disallowed file types list, but not both.
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For the File Types setting, specify whether you want to create a list of allowed or disallowed file types:
5.
For the File Types setting, select the file types to allow or disallow in a request:
Select file types from the Available list, and move them to the Allowed or Disallowed list.
Add a new file type: type the name in the File type box, click Add to add it to the Available list, and move it to the list.
Important: File types are case-sensitive. For example, the Protocol Security Module treats jsp and JSP as separate file types.
6.
Check or clear the Alarm or Block check boxes as required.
Check Alarm if you want the system to log any requests that trigger the Illegal file type violation.
Check Block if you want the system to block any requests that trigger the Illegal file type violation.
Check both Alarm and Block if you want the system to perform both actions.
7.
Click Update to retain your request check changes.
If your application 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.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For the Mandatory Headers setting, in the Headers box, type the name of the mandatory header, and click the Add button to add it to the Available list.
5.
Move the new mandatory header from the Available list to the Mandatory list, by using the Move [<<] button.
6.
Check or clear the Alarm or Block check boxes as required.
Check Alarm if you want the system to log any requests that trigger the Mandatory HTTP header is missing violation.
Check Block if you want the system to block any requests that trigger the Mandatory HTTP header is missing violation.
Check both Alarm and Block if you want the system to perform both actions.
7.
Click Update to retain any changes you may have made.
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.
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 use the Data Guard feature to prevent responses from exposing sensitive information (by replacing it with asterisks). The process of securing sensitive data in responses is called response scrubbing.
In addition to protecting credit card numbers and social security numbers, which the system recognizes automatically, you can configure custom patterns, by using PCRE-compliant regular expressions, to match other types of sensitive information. Similarly, you can add exception patterns for data patterns that you do not want to be considered sensitive. You configure the Data Guard settings to specify the sensitive data that you want the system to identify in responses.
When the 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.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
Check the Remote Logging box.
5.
To identify credit card and social security numbers as sensitive in responses, select the Credit Card numbers and Social Security numbers check boxes.
a)
Check the Enable custom patterns box.
b)
In the New custom pattern box, type a regular expression
and click Add.
The pattern is added to the list.
a)
Check the Enable exception patterns box.
b)
In the New exception pattern box, type a regular expression and click Add.
The pattern is added to the list.
8.
Check the Mask data box if you want the system to replace sensitive data in a response with asterisks (****).
a) Select Enforce URLs from the list.
b) In the New URL box, type an URL (explicit or wildcard) and click Add.
10.
Check or clear the Alarm or Block check boxes as required.
Check Alarm if you want the system to log responses that trigger the Information leakage detected violation, and display it on the Protocol Security Statistics screen.
Check Block if you want the system to block responses that trigger the Information leakage detected violation. If blocking is configured, masking has no effect on responses with leakage because the entire response is blocked.
Check both Alarm and Block if you want the system to perform both actions.
11.
Click Update to save changes to the HTTP profile.
The allowed response status codes list in the HTTP security profile displays the response status codes between 400 and 599 that the security profile considers legal. The only responses that the system returns to the user as-is, are those with response codes that appear in the list.
If a response contains a response status code between 400 and 599 that is not on the list and the Allowed Response Status Codes setting is set to Alarm, the system issues the violation Illegal HTTP status in response. If you configured the security profile to block response status codes not on the list, the system blocks the response.
Note: The Protocol Security Module only checks response codes from 400 to 599. It automatically allows all other response codes.
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
a)
By the Allowed Response Status Codes setting, in the New Response Status Code box, type a response code between 400 and 599. By default, the Allowed Response Codes are: 400, 401, 404, 407, 417, and 503.
b)
Click the Add button.
a)
By the Allowed Response Status Codes setting, select one or more status codes to delete.
b)
Click the Remove button.
6.
Check or clear the Alarm and Block check boxes as required.
Check Alarm if you want the system to log requests that trigger the Illegal HTTP status in response violation, and display it on the Protocol Security Statistics screen.
Check Block if you want the system to block requests that trigger the Illegal HTTP status in response violation.
Check both Alarm and Block if you want the system to perform both actions.
7.
Click Save to save your changes.
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 clients 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.
Important: The system displays a response page when it encounters a violation, only if one or more of the security checks is set to Block.
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For the Response Type setting, select one of the following options:
Default Response: Specifies that the system returns the system-supplied blocking response page. Note that you cannot edit the HTML code on the default blocking page, but 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. Note that you cannot edit the SOAP fault code, but you can copy it into a custom response and edit it.
Note: 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 in step 4, you can either create a new response or upload an HTML file.
a)
For the Response Header setting, click the Paste Default Response Header button, and make any changes as required. Use standard HTTP syntax for the header.
b)
For the Response HTML Code setting, click the Paste Default Response HTML Code button, and make any changes as required. Use standard HTML syntax for the response code.
a)
For the Upload HTML File setting, click Browse to navigate to an existing HTML response page.
b)
Click Upload.
6.
If you selected the Redirect URL option in step 4, then in the Redirect URL box, type the full path of the web page where the system should redirect the client.
7.
Click Update to save your changes.
You can configure the Protocol Security Module to validate XML code in requests, and specify XML data format settings for your environment.
1.
In the navigation pane, expand Protocol Security, and then click Security Profiles.
The HTTP Security Profiles screen opens.
2.
In the HTTP Security Profiles area, in the Profile Name column, click the name of the security profile that you created.
The Profile Properties screen opens.
4.
For the Check XML Content-Type Headers setting, select one of the following:
All: Specifies that the system validates XML data 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 box. The systems default pattern is *xml*.
5.
In XML Data Format Settings, for the Defense Level, select High, Medium, or Low.
The system automatically loads the default values for the XML data format settings according to the defense level you selected. We recommend that you use the default value.
If you change any of the default values, the system automatically changes the defense level to Custom. The default level is Medium. Refer to the online help for details on the settings.
6.
For the XML Data Format Settings, check or clear Alarm or Block.
Check Alarm if you want the system to log any requests that violate any of the XML data format settings.
Check Block if you want the system to block any requests that violate any of the XML data format settings.
Check both Alarm and Block if you want the system to perform both actions.
7.
For the Well-Formedness setting, check or clear Alarm or Block.
Check Alarm if you want the system to log any requests that contain malformed XML data.
Check Block if you want the system to block requests that contain malformed XML data.
Check both Alarm and Block if you want the system to perform both actions.
8.
Click Update to save your changes.
When you enable the Protocol Security setting on an HTTP service profile, the system automatically assigns the first-listed HTTP security profile to the service profile. If you have more than one security profile configured, you can change the associations. On the Profile Assignment screen, you can review the current associations, including the HTTP service profile (called traffic profile), the virtual server that uses the service profile, and the HTTP security profile.
1.
In the navigation pane, expand Protocol Security, and then click Profiles Assignment.
The Profile Assignment screen opens.
2.
From the Profile Assignment menu, choose HTTP.
The Profile Assignment screen opens.
3.
In the Assigned Security Profile column of each traffic profile, select the HTTP security profile that you want the service profile to use.
4.
Click Save to retain any changes you may have made.
Note: If you have not yet created a virtual server that uses the HTTP service profile, no virtual servers appear in the security profiles list.
You need to configure a local traffic virtual server and a default pool for the HTTP servers, and associate the HTTP service profile that you created. This automatically associates the HTTP security profile with the virtual server. The result is that when the virtual server receives HTTP traffic, the HTTP security profile in the Protocol Security Module scans the HTTP traffic for security vulnerabilities, and then the local traffic virtual server load balances any traffic that passes the scan.
Note: For detailed information about local traffic virtual servers, refer to the Configuring Virtual Servers chapter in the Configuration Guide for BIG-IP® Local Traffic Manager, which is available from the AskF5 web site, https://support.f5.com.
1.
In the navigation pane, expand Local Traffic, and then click Virtual Servers.
The Virtual Servers screen opens.
2.
Click the Create button.
The New Virtual Server screen opens.
3.
For the Name setting, type a unique name for the virtual server.
4.
For the Destination setting, select the type, and type an address, or an address and mask, as appropriate for your network.
5.
For the Service Port setting, type either 80 (for HTTP) or 443 (for HTTPS) in the box. Alternately, select HTTP or HTTPS from the list.
6.
Next to Configuration, select Advanced.
The screen refreshes, and displays additional configuration options.
7.
For the HTTP Profile setting, select the profile that you created with protocol security enabled.
8.
For the SNAT Pool setting, if your network configuration requires address translation, select Auto Map.
9.
In the Resources area, for the Default Pool setting, click the Create (+) button.
The New Pool screen opens.
10.
On the New Pool screen, in the Configuration area, for the Name setting, type a unique name for the pool.
11.
On the New Pool screen, in the Resources area, for the New Members setting, you can add members to the pool:
Select New Address to type the address and port of any HTTP servers that you want to add to the configuration. (Note that the system automatically adds them as nodes, too.)
Select Node List to select addresses from a list of servers that already exist in the local traffic configuration.
b)
For Service Port, select HTTP from the list.
c)
Click the Add button to add each node or address to the New Members list.
12.
Click Finished.
The screen refreshes, and returns you to the New Virtual Server screen. The new pool should be listed in the Default Pool setting.
13.
Click Finished on the New Virtual Server screen.
The screen refreshes, and you see the new virtual server in the list.
The system is now ready to scan HTTP traffic for vulnerabilities common to that protocol. See Reviewing violations statistics for HTTP security profiles, for information on reviewing the HTTP security attacks that the system detects.
After you finish configuring the system, and traffic is flowing through it, the Protocol Security Module provides statistics and other information about requests that trigger HTTP security violations. If you have enabled the Alarm flag for a violation, and an incoming request triggers a violation, the Protocol Security Module logs the request, which you can review from the Statistics screen of the Protocol Security Module. If you have enabled the Block flag for any of the HTTP security violations, the Protocol Security Module blocks the request and sends the blocking response page, which includes the Support ID, to the offending client.
1.
In the navigation pane, expand Protocol Security, and then click Statistics.
The Statistics screen opens.
2.
If the system has detected a violation, the violation name becomes a hyperlink. Click the link to see details about the requests that caused the violations.
3.
Optionally, use the Search by Support ID (HTTP) setting to find a violation by the support ID:
b)
Click the Go button.
4.
On the Statistics screen, on the left side of the HTTP section, review information regarding the HTTP traffic volume.
Total transactions in the last minute and in the last hour are displayed.
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)