Applies To:

Show Versions Show Versions

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

For the HTTP security profile, you can also configure either a blocking response page or a redirection. If the system detects a violation according to the security profile settings, and you have enabled the Block flag for the violation, instead of forwarding the request, the Protocol Security Module either sends a blocking response page or redirects the client.
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.
After you enable protocol security, 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.
Check the Custom 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 are applicable to the HTTP traffic, and enforced by the Security Enforcer. In the security profile, you can also specify whether the Protocol Security Module logs violations to a remote logging server.
1.
In the navigation pane, expand the Protocol Security section and click Security Profiles.
The HTTP Security Profiles screen opens in a new browser session.
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.
For the Remote Logging setting, check the box if you want to enable remote logging for this security profile.
Note: You can only check the box if you have configured the remote logging server. See Configuring remote logging.
5.
If you do not check either Alarm or Block for a protocol check, the system does not perform the corresponding security check.
Check Alarm if you want the system to log any requests that trigger the security profile violation.
Check Block if you want the system to block requests that trigger the security profile violation.
Check both Alarm and Block if you want the system to perform both actions.
Tip: In the configuration area, point to the Info icon next to the name of each security check for a description of the check.
8.
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.
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 always enabling these checks:
Unparsable request content
This security check fails when the Protocol Security Module is unable to parse the incoming request.
Null in request
This security check fails when the incoming request contains a null character.
Several Content-Length headers
This security check fails when the incoming request contains more than one Content-Length header.
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 Security Enforcer blocks all requests that are not compliant with the HTTP protocol standards, and performs the additional security checks only on valid HTTP traffic.
1.
In the Protocol Security navigation pane, 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 tab.
3.
In the Defense Configuration area, select the HTTP Protocol Checks you want the system to check for.
4.
Click Update to retain any changes you may have made.
For every HTTP request that the Protocol Security Module receives, the Security Enforcer preprocesses requests to search for those methods of application attack that are designed to avoid detection. These coding methods, called evasion techniques, trigger the Evasion technique detected violation. The Security Enforcer 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 Protocol Security navigation pane, 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.
Check Alarm if you want the system to log any requests that trigger the Evasion technique detected violation.
Check Block if you want the system to block any requests that trigger the Evasion technique detected violation.
Check 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 Protocol Security navigation pane, 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 Security Enforcer can help prevent buffer overflow attacks. You can set maximum lengths for URLs, query strings, POST data, and the entire request.
1.
In the Protocol Security navigation pane, 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, POST, and HEAD. The system treats any incoming HTTP request that uses an HTTP method other than the allowed methods as a violating request. Later, you can decide how to handle each violation.
1.
In the Protocol Security navigation pane, 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 Protocol Security navigation pane, 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 Security Enforcer 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 headers in the security profile. The Security Enforcer 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 Protocol Security navigation pane, 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 detects sensitive user information in the server response. The allowed response codes list specifies which HTTP response codes are acceptable in the server response.
Depending on the application, a response may 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. The process of securing sensitive data in responses is called response scrubbing. In addition to protecting credit card numbers and social security numbers, you can configure custom patterns, by using PCRE-compliant regular expressions, to match other types of sensitive information.
When the system detects sensitive information in a response, and you have enabled the Data Guard feature, the system generates the Information leakage detected violation. Additionally, if you have enabled the Block action, the response where leakage was detected is not sent to the client; instead the system sends the Protocol Security Module blocking page.
1.
In the Protocol Security navigation pane, 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 Data Guard settings, specify the sensitive data that you want the system to identify in responses:
Select Credit Card numbers and Social Security numbers if you want this information to be considered sensitive.
Select Enable custom patterns if you want to specify a regular expression that represents a sensitive data pattern.
Select Enable exception patterns if you want to specify a regular expression that indicates data to exclude from being sensitive.
Important: You must check the Mask Data box if you want the system to replace sensitive data with asterisks (****).
5.
Check the Mask data box if you want the system to replace sensitive data in a response with asterisks.
6.
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.
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.
7.
Click Update to retain any changes you may have made.
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 Protocol Security navigation pane, 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 Allowed Response Status Codes setting, in the New Response Status Code box, type a response code between 400 and 599 and click the Add button to add the response code to the list. By default, the Allowed Response Codes are: 400, 401, 404, 407, 417, 503.
5.
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.
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.
6.
Click Save to save any changes you may have made to the security profile properties.
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 blocking response page on the clients screen. The default blocking response page states that the request was rejected, and provides a support ID.
If the current security profile blocks a client request or a web server response due to a violation, the Protocol Security Module displays a page, called the blocking response page, on the clients screen, or redirects the client to a specific web site.
Important: Only if one or more of the security checks is set to Block does the system display the response page when it encounters a violation.
1.
In the Protocol Security navigation pane, 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 that appears in requests and specify XML data format settings for your environment.
1.
In the Protocol Security navigation pane, 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 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 box. The systems default pattern is *xml*.
5.
For the XML Data Format Settings 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 values.
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 defense 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 any 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 Protocol Security navigation pane, 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 by typing the IP addresses and ports, or by selecting addresses from a list.
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.
12.
On the New Pool screen, for the Service Port setting, select HTTP from the list.
13.
Click the Add button to add each node or address to the New Members list.
14.
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.
15.
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.
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 Protocol Security navigation pane, click Statistics.
The Statistics screen opens.
2.
If the system has detected a violation, then the violation name becomes a hyperlink. Click the link to see details about the offending requests.
3.
Optionally, use the Search by Support ID (HTTP) setting to find a violation by the Support ID.
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)