Applies To:

Show Versions Show Versions

Manual Chapter: Manually Configuring Security Policies
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The core of the Application Security Managers security functionality is the security policya collection of settings that secures traffic for a web application. The security policy is a set of definitions regarding the application traffic.
When the Application Security Manager receives an incoming HTTP or HTTPS request for the web application, the system compares the request to the active security policy. If some element of the request (or response) does not comply with security policy, the Application Security Manager processes the request according to the Blocking Policy settings, which include the enforcement mode and the Learn, Alarm, and Block flags. For more information about the Blocking Policy settings, see Configuring security policy blocking.
Deployment wizard
The Deployment wizard is a tool that automates the security policy setup tasks for a web application. The Deployment wizard builds security policies based on one of several typical deployment scenarios. For more information, refer to the BIG-IP® Application Security Manager: Getting Started Guide guide, which is available on the Ask F5SM web site, https://support.f5.com.
Security Policy Setup wizard
The Security Policy Setup wizard is a tool that helps you to perform most of the security policy setup tasks for web applications. You still need to configure additional settings manually. See Chapter 5, Working with the Security Policy Setup Wizard, for more information.
The Security Enforcer, part of the Application Security Manager, applies the active security policy to each request for the web application. If the request complies with the security policy, the Security Enforcer forwards the request on to the web application. If the request does not comply with the security policy, the Security Enforcer generates a violation (or violations), and then either forwards the request or blocks the request, depending on the enforcement mode of the security policy.
The Security Enforcer can also check responses from the web application.If the response complies with the security policy, the system sends the response to the client. If the response does not comply with the security policy, the Security Enforcer generates the relevant violation (or violations), and then either forwards the response or blocks the response, depending on the enforcement mode of the security policy. This prevents the transmission of information from the server to the client.
On the Blocking Policy screen, you can view a list of all of the possible security policy violations. The violations fall into these categories:
Click the information icon () by a violation, or refer to Appendix A, Security Policy Violations, for descriptions of all violations. For information on setting the learning, alarm, and blocking actions for the violations, see Configuring the blocking actions.
The Application Security Manager includes the Policy Builder, a tool that automates building a security policy. You can use the Policy Builder to build the security policy based either on real traffic (requests and/or responses) or on system-generated traffic. See Chapter 6, Building a Security Policy Automatically with the Policy Builder, for detailed information on using the Policy Builder.
Before you configure the security policy entities, which define parts of the web application, you configure the policy properties of the security policy. The policy properties are the general configuration options and settings that determine the overall behavior and functionality of the security policy.
Important: Whenever you change a security policy, you must apply the security policy to make it the active security policy. To remind you that you need to set the active security policy, the system displays an [M] next to the modified security policy. After you set the active security policy, the Security Enforcer enforces any changes you made. To set the active policy, refer to Setting the active security policy for a web application, for detailed information.
Each security policy that you configure has a unique name, which you assign as part of the general properties. At minimum, a new security policy must have a name. You can change the security policy name at any time. You can also provide a description of the security policy, to help you better identify the security policy.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
For the Security Policy Name setting, type a unique name for the security policy.
4.
Optionally, in the Security Policy Description box, type a description, as required.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, click the name of the web application in the Web Application setting.
The Web Application Properties screen opens, where you can view the details of the web application.
Security policies can be in one of two enforcement modes: transparent and blocking. When the system receives an incoming HTTP request that does not comply with the security policy, the system logs the HTTP request according to the logging profile for the web application, and generates violations.
If the security policy is in transparent mode, the system then forwards the request to the destination. If the security policy is in blocking mode, and the Block flag is enabled for the triggered violation, the system does not forward the request to the web application. Instead, the system sends the blocking response page to the client, which advises the client that the request was blocked, and provides a support ID number for the violating request. However, even in blocking mode, if the triggered violation does not have the Block flag enabled (and assuming that no other violation with block enabled was triggered), the request is not blocked. For information on setting Block flags, refer to Configuring the blocking actions.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
4.
Click Save to save any changes you may have made to the security policy properties.
You can configure the number of days used as the default staging-tightening period. Web application entities and attack signatures remain in staging for this period of time before the system suggests that you enforce them. The security policy provides staging suggestions when requests match the attack signatures, or do not adhere to the web application entity's settings.
Note: If the Policy Builder processes a minimum amount of traffic and runs after the staging-tightening period is over, the Policy Builder automatically enables the web application entities and the attack signatures that did not cause violations during the period.
The system does not enforce wildcard entities when they are in tightening mode. Wildcard entities remain in tightening for the number of days specified by staging-tightening period after which the system suggests you enforce them. In tightening mode, the system adds explicit entities it finds that match these wildcard expressions.
For example, if you enable tightening on file types, the system learns the explicit file types that the web application uses (such as .html, .php, .asp, .gif, and .jpeg). You can review the new entities and decide which are legitimate entities for the web application, and accept them into the security policy. For more information about the staging-tightening period, see Understanding staging and tightening for wildcard entities.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, for the Staging-Tightening Period, type the number of days you want the entities or signatures to be in staging or with tightening. The default value is seven days.
4.
Click Save to save any changes you may have made to the security policy properties.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area near the top of the screen.
You can enable or disable staging for attack signatures. The default setting is enabled. When the staging feature is enabled, the system places all newly assigned and newly updated signatures in staging for the number of days specified in the staging-tightening period. The system does not enforce signatures that are in staging even if it detects a violation. Instead, the system records the request information. If staging is disabled, the system enforces the signature Learn, Alarm, and Block settings immediately.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
Check the Enable Signature Staging box to enable staging on new or changed signatures.
4.
Click Save to save any changes you may have made to the security policy properties.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area near the top of the screen.
You specify a maximum HTTP header length so that the system knows the acceptable maximum length for the HTTP header in an incoming request. The system applies the length check to header names and value. You can use this setting to help prevent primary buffer overflow attacks.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Maximum HTTP Header Length setting, select one of the following options:
Select Any to have the system accept HTTP headers of any length.
Select Length, and type a value, to accept HTTP headers up to a certain length. The default maximum length is 8192 bytes.
5.
Click Save to save any changes you may have made to the security policy properties.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You specify a maximum cookie header length so that the system knows the acceptable maximum length for any cookie headers in the incoming HTTP request. As with the maximum HTTP header length setting, you can use this setting to help prevent primary buffer overflow attacks.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Maximum Cookie Header Length setting, select one of the following options:
Select Any to have the system accept cookie headers of any length.
Select Length, and type a value, to accept cookie headers up to a certain length.The default maximum length is 8192 bytes.
5.
Click Save to save any changes you may have made to the security policy properties.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
By default, the Application Security Manager accepts all response codes from 100 to 399 and 600 to 999 as valid responses. Response codes from 400 to 599 are all considered invalid. However, you can configure the security policy to accept certain specific codes in the invalid range as valid. The HTTP response status codes that the security policy considers valid are displayed in the Allowed Response Status Codes list.
If a response contains a response status code between 400 and 599 that is not on the list, the system issues the violation, Illegal HTTP status in response. If you configured the security policy to block this violation, the system blocks the response.
Note: The Application Security Manager checks only response codes from 400 to 599. It automatically allows all other response codes.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Allowed Response Status Codes setting, add the response status codes between 400 and 599 that you want the system to consider legal.
5.
Click Save.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
If an application uses dynamic session IDs in URLs, the Application Security Manager cannot use its normal functions to extract and enforce URLs or flows because the URI contains a dynamic element. If the web application that you are securing stores dynamic session ID information in a URL, you can enable the Dynamic Session ID in URL option. (In most cases, you do not need to configure this setting.) When the system receives a request in which the dynamic session information does not match the settings in the security policy, the Security Enforcer issues the Illegal session ID in URL violation.
When you enable the Dynamic Session ID in URL option, the Application Security Manager extracts the dynamic session information from requests or responses, based on the pattern that you configure. For requests, the Security Enforcer applies the pattern to the URI up to, but not including, the question mark (?) character of a query string.
Using dynamic session IDs does not change the length of the URL with regard to the URL length restriction specified in the file type properties. That is, any length restriction is based on the URL including the session ID.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Dynamic Session ID in URL option, set the option as needed:
Disabled: The security policy does not enforce dynamic session ID in URL.
Default pattern: The security policy uses the default regular expression (\/sap\([^)]+\)) for recognizing a dynamic session ID in URL.
Custom pattern: The security policy uses a user-defined regular expression to recognize a dynamic session ID in URL. Type a regular expression in the Value box, and a description in the Description box.
5.
Click Save.
The system updates the configuration with any changes you have made.
An iRule is a script that lets you customize how you manage traffic on the BIG-IP system. You can write iRules to modify a request or response based on violations that occur. For detailed information on writing iRules, see the F5 Networks DevCentral web site, http://devcentral.f5.com.
If you want to use iRules with Application Security Manager, you need to activate iRule events. By default, iRule events are disabled. Table 7.1 lists the iRule events that are available in Application Security Manager.
Occurs when Application Security Manager is generating an error response to the request that caused the violation, and gives the iRule a chance to modify the response before it is sent.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
Check the Trigger ASM iRule event box if you have written iRules that process Application Security Manager iRule events, and assigned them to a specific virtual server.
5.
Click Save.
The system updates the configuration.
You can configure Application Security Manager to trust requests that include XFF (X-Forwarded-For) headers or customized XFF headers. You may want to configure trusted XFF headers if the Application Security Manager is deployed behind an internal or other trusted proxy. Then, the system uses the IP address that initiated the connection to the proxy instead of the internal proxys IP address.
You should not configure trusted XFF headers if you think the HTTP header may be spoofed, or crafted, by a malicious client. When the Application Security Manager is deployed behind an internal proxy, the system uses the internal proxys IP address instead of the clients IP address.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
Check the Trust XFF Header box.
The screen refreshes, and displays custom XFF configuration options.
a)
For New Custom XFF Header, type a XFF header that the system should trust.
b)
Click Add.
6.
Click Save.
The system updates the configuration.
At any given time, the Application Security Manager enforces only one security policy for a web application. The security policy that is currently protecting the web application is called the active security policy. The active security policy is marked with the Active icon in the Security Policies List for the web application.
1.
In the Application Security navigation pane, click Web Applications.
The Web Applications list screen opens.
2.
In the Name column, click the name of the web application for which you are activating a security policy.
The Web Application Properties screen opens.
3.
In the Active Security Policy list, select the security policy that you want to be the active security policy for the web application. Note that the system automatically checks the Apply Policy setting when you change the Active Security Policy setting on this screen.
4.
Click Update.
The system changes the active security policy.
5.
To verify the change, in the Application Security navigation pane, click Policies List.
The Security Policies screen opens, and you see the Active Policy icon next to the new active security policy.
Tip: You can also set the active security policy from most of the screens throughout the Application Security Manager. Simply click the Apply Policy button in the editing context area.
When you change the configuration in a security policy, you must apply the security policy before the changes take effect. The following icons indicate the state of a security policy.
The Active icon next to a security policy name indicates the active security policy. You may also see an A in square brackets [A] to indicate the active security policy. Only one security policy can be the active security policy.
The Modified icon or [M] next to a security policy name indicates that the security policy has been modified. Clicking Apply Policy enforces the changes and removes the icon.
Figure 7.1 shows a Security Policies list containing two policies. The security policy called webapp_security is the active policy and it has been modified.
The first security checks that Application Security Manager performs are those for RFC compliance for the HTTP protocol. The system performs validation checks on HTTP requests to ensure that the requests are formatted properly. For each security policy, you can configure which HTTP validations the system performs. You can also configure whether the system generates learning suggestions, alarms, or blocks requests that trigger the HTTP protocol compliance failed violation.
When Application Security Manager receives a request from a client, the first aspect of the request that the system validates is HTTP protocol compliance. In rare cases, if a request is not compliant with the following subset of HTTP protocol validations, the web application receives the request even though it is not valid. The HTTP protocol validations that may cause this situation are:
In most cases, requests not meeting these validations contain payloads that most likely will not be parsed by the application, or clearly indicate a malicious action.
F5 Networks recommends that you retain the default blocking policy settings for the HTTP protocol validations because most of these validations are enabled. As an additional precaution, you may want to enable the blocking enforcement mode, and enable only the Block flag for the HTTP protocol compliance failed violation. When you do this, the Security Enforcer blocks requests that are not compliant with the HTTP protocol standards.
Note: The Request size exceeded maximum buffer size violation also causes the system to stop validating a request.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose HTTP Protocol Compliance.
The HTTP Protocol Compliance screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
On the HTTP Protocol Compliance screen, make any adjustments that are required. For an explanation of the individual validations, refer to the online help.
5.
Click Save to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Wildcard file type
Wildcard file types are those whose name is, or contains, a pattern string. When you configure a wildcard file type, and enable tightening, as the security policy processes traffic, the system discovers the file types that match the wildcard. You can then decide whether to add those file types to the security policy. For detailed information on wildcard file types, refer to Configuring wildcard file types.
No extension file type
The no extension file type represents file types that do not have the typical file extension as part of the name. The slash character (/) is an example of a no_ext file type.
Explicit file type
Explicit file types have a known file extension name, for example, JSP or htm.
Disallowed file types
You can also configure a list of file types that the system always rejects. These objects are known as disallowed file types. Refer to Disallowing specific file types, for more information.
Important: File types are case-sensitive. As a result, the security policy processes JPG and jpg files as separate file types.
Note: When you run the Policy Builder, the system automatically creates a no_ext file type for URLs with no file extension and URLs with file extensions longer than eight characters.
For allowed file types, which are file types that the system accepts, you can configure lengths, and whether the Security Enforcer checks responses for the associated requests. Table 7.2 describes the allowed file type properties.
Explicit: Specifies that the file type is not a wildcard entity. Type the file type name in the adjacent box.
Wildcard: Specifies that the file type is a wildcard expression. Any file type that matches the wildcard expression is considered legal. For example, entering the wildcard * specifies that any file type is allowed by the security policy. Type a wildcard expression in the adjacent box.
No Extension: Specifies that the web application has a URL with no file type. The system automatically assigns this file type the name no_ext.
Specifies, when checked, that the system places this entity in staging. If this entity is in staging, the system does not block requests for this entity even when the security policy is in blocking mode. Learning suggestions produced by requesting staged entities are logged in the Learning screens.
You can check the staging status on the Allowed File Types screen. If a file type is in staging, the system displays a light bulb icon (in different colors indicating status). Move the cursor over the light bulb icon to display staging information.
When the entity has been in staging for the staging period and requests for this entity do not log any learning suggestions, you can clear this check box.
Note: F5 Networks does not recommend using both tightening and staging on the same wildcard entity.
Specifies, when checked, that tightening is enabled for this wildcard file type. As a result, the system lists file types that do not exist in the security policy but match this wildcard.
The Staging-Tightening Summary screen shows how many entities are in staging or with tightening. You can review the explicit file types that do not exist in the security policy but match this wildcard object, decide which are legitimate for the web application, and accept them into the security policy.
Note: F5 Networks does not recommend using both tightening and staging on the same wildcard entity.
1.
In the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed File Types list, click the Create button.
The New Allowed File Type screen opens.
4.
In the Allowed File Type Properties area, for the File Type setting, select the type, and then type a file extension or wildcard expression.
If you select No Extension, the system specifies no_ext.
Tip: For more information about wildcard file types, see Configuring wildcard file types.
7.
Click Create.
The screen refreshes, and you see the new file type on the Allowed File Types List screen.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
To modify the allowed file type characteristics
1.
In the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed File Types List area, click the name of the file type that you want to update.
The Edit Allowed File Type screen opens.
4.
Make any changes as required, and click Update.
The screen refreshes, and returns to the Allowed File Types List screen.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Since web applications can change on a regular basis, you may find that the file types list contains file types that are no longer used in the web application. You can remove the file type and any related URLs (if applicable) in one step.
1.
In the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed File Types List area, click the Select box to the left of the file type that you want to remove from the list.
4.
Click the Delete button below the list.
The system removes the file type from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
For some web applications, you may want to deny requests for certain file types. In this case, you can create a set of disallowed file types. When the Application Security Manager receives a request whose file type is disallowed, the system rejects the request.
1.
In the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
On the menu bar, click Disallowed File Types List.
The Disallowed File Types List screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Above the Disallowed File Types List area, click the Create button.
The New Disallowed File Type screen opens.
5.
For the File Type setting, type the file type that you want to disallow (for example, jpg or exe).
Note: File types are case-sensitive.
6.
Click Create.
The screen refreshes, and displays the updated Disallowed File Types List screen.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can add three types of URLs for the web application that you are protecting:
Explicit URLs
An explicit URL has a specific name and represents one file or component of the web application, for example, /login.jsp or /sell.php.
Wildcard URLs
A wildcard URL is one whose name is or contains a pattern string, for example, * or *.png. For more information on managing wildcard URLs, refer to Configuring wildcard URLs.
Disallowed URLs
A disallowed URL is a URL that is not allowed by the security policy. For information on creating disallowed URLs, refer to Configuring URLs not allowed by the security policy.
Table 7.3 lists URL properties.
Table 7.3 URL properties 
Specifies the type and name for the URL that you are creating. URLs are case-sensitive. The available types are:
Explicit: Specifies that the URL is not a wildcard entity. Type the URL in the adjacent box.
Wildcard: Specifies a wildcard expression. Any URL that matches is considered legal. For example, typing * specifies that any URL is allowed by the security policy. Type a wildcard expression in the adjacent box.
Explicit URLs, wildcard URLs, and disallowed URLs
Specifies, when checked, that the system places this URL in staging. When in staging, the system does not block requests for this URL even when the security policy is in blocking mode. Violations related to the URL (Illegal meta character in URL) are also not blocked. Learning suggestions produced by requesting staged URLs are logged in the Learning screens.
You can check the staging status on the Parameters List screen. If a parameter is in staging, the system displays a light bulb icon (in different colors indicating status). Move the cursor over the light bulb icon to display staging information.
When the entity has been in staging for the staging period and requests for this entity do not log any learning suggestions, you can clear this check box.
Note: F5 Networks does not recommend using both tightening and staging on the same wildcard entity.
-When Policy Builder runs, it adds explicit URLs that do not exist in the security policy but match this wildcard URL.
-The system displays, on the Staging-Tightening Summary screen, how many entities are in staging and/or with tightening. You can review the explicit URLs that do not exist in the security policy but match this wildcard URL, decide which are legitimate for the web application, and accept them to the security policy.
Specifies, when cleared, that the Policy Builder does not add to the security policy explicit URLs that match this wildcard URL, and the system does not suggest URLs that match this wildcard URL. The default is disabled.
Note: F5 Networks does not recommend using both tightening and staging on the same wildcard URL.
Explicit URLs, wildcard URLs, and disallowed URLs
Specifies, when checked, that the security policy validates the flows to the URL. If this setting is disabled, the Security Enforcer ignores the flows to the URL. For more information on flows, refer to Configuring flows. When you check this box, additional settings appear.
(Visible when Check Flows to this URL is selected.) Specifies, when checked, that this URL is a page through which a visitor can enter the web application.
(Visible when Check Flows to this URL is selected.) Specifies, when checked, that the URL is a URL from which a user can access other URLs in the web application.
Specifies, when checked, that the security policy does not block an HTTP request where the domain cookie was modified on the client side. Note that this setting is applicable only if the URL is a referrer.
Specifies, when checked, that the system validates XML data found in requests to this URL. The default is disabled. For more information on XML security, refer to Chapter 13, Protecting XML Applications.
Explicit URLs and wildcard URLs
(Visible when Check XML is selected.) Specifies that the system validates XML data found in requests to this URL based on the settings you configure in a specific XML profile. For more information on XML profiles, refer to Associating an XML profile with a URL.
Explicit URLs and wildcard URLs
(Visible when Check XML is selected.) Specifies the kind of information the XML profile is to protect.
All specifies that the system validates XML data found in requests to this URL.
User defined specifies that the system validates XML data found in requests to this URL only if the context-type header includes a specific string.
Explicit URLs and wildcard URLs
(Visible when Check XML is selected.) Specifies, when checked, that the Security Enforcer applies security checks to AMF requests. For more information, refer to Configuring AMF security for URLs.
Explicit URLs and wildcard URLs
Explicit URLs and wildcard URLs
URL parameters are parameters that are associated with a specific URL. Extractions specify how the system discovers dynamic parameters and their properties. For full details on managing URL parameters and extractions, refer to Working with dynamic parameters and extractions.
Flows are the navigational relationships between the entities in a web application. Configuring flows may tighten the security policy, but this is an optional configuration option. For more information on flows, refer to Configuring flows.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed URLs List area, click the Create button.
The New Allowed URL screen opens.
4.
To configure the advanced settings, select Advanced above the Create New Allowed URL area.
The screen refreshes to display additional settings.
5.
In the Create New Allowed URL area, for the URL setting, select the type, and then type the explicit URL name. For explicit URLs, be sure to type the full resource path starting with the slash ( / ) character.
6.
In the Protocol list, select the protocol to be used to access the URL.
7.
Apply the XML profile and configure XML settings, if needed. For information on checking XML data, refer to Associating an XML profile with a URL. For information on checking AMF data, refer to Configuring AMF security for URLs.
8.
Click the Create button.
The screen refreshes, and you can see the new URL in the list.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Click the Delete button.
A confirmation popup screen opens, where you confirm the deletion of the URL.
5.
Click OK.
The system removes the URL from the security policy.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, click the name of a URL.
The Allowed URL Properties screen opens, where you can view or modify the URL properties.
You can create a list of disallowed URLs, for example, to disallow access to an administrative interface to the web application. If a requested URL is on the disallowed URLs list, the system issues an Illegal URL violation. You can view learning suggestions for disallowed URLs on the Illegal URL learning screen. For more information, refer to Working with learning suggestions.
1.
In the Application Security navigation pane, point to URLs, and then click Disallowed URLs List.
The Disallowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Click the Create button.
The New Disallowed URL screen opens.
4.
For Protocol, select HTTP or HTTPS.
5.
For URL, type the name of the URL you want the security policy to consider illegal.
6.
Click the Create button.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Action Message Format (AMF) is a binary format that is loosely based on Simple Object Access Protocol (SOAP). AMF is used primarily to exchange data between Adobe® Flash® applications and a database, by using the RPC (remote procedure call) protocol. The Application Security Manager secures applications that use AMF by applying attack signatures to parameters within POST requests, when the Content-Type header matches the pattern *amf*.
The Application Security Manager determines whether a request is an AMF request when the request meets the following criteria:
The Content-Type header matches the pattern *amf*
When a request matches the previous criteria, the system applies parameter-specific attack signatures to any parameters in the POST body of AMF requests. If the system finds a match, then the Security Enforcer issues the Attack signature detected violation, and handles the request according to the blocking policy settings.
Note: If a request contains a Content-Type header whose value matches the *amf* pattern, but the Check AMF option is not enabled for the corresponding URL, then the Application Security Manager does not apply the additional AMF checks.
You configure AMF security on a per-URL basis. You can configure AMF security for both wildcard URLs and explicit URLs.
Note: The following procedure assumes that you are configuring AMF security for a URL that already exists in the configuration. If this is not the case, refer to Creating an explicit URL, or Creating wildcard URLs, before proceeding.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, click the name of the URL for which you want to enable AMF security.
The Allowed URL Properties screen opens.
4.
Above the Allowed URL Properties area, select Advanced.
The screen refreshes, and displays additional configuration options.
5.
Check the box for Check AMF (When the content type matches "amf").
6.
Click Update.
The screen displays the Allowed URLs List screen.
When you first configure the web application properties in the Application Security Manager, you select a language encoding. The Security Enforcer then enforces the character set of that language encoding in the URL element in URIs, and also for any wildcard urls in the security policy. For example, by disallowing the characters <, >, ', and |, the Security Enforcer can protect against many cross-site scripting attacks and injection attacks. You can modify the character set as required by your web application.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Character Set.
The URLs Character Set screen opens, where you can view the character set, and state of each character.
4.
Use the Filter option to display only those characters that you want to view.
5.
To modify the character set, click Allow or Disallow to define which characters the system should allow or disallow in the name of a wildcard URL.
6.
Click Save to save your changes.
7.
Click the Apply Policy button (in the editing context area) to immediately put those changes into effect.
The application flow is the defined access path leading from one URL to another URL within the web application. For example, on a basic web page, you may have a graphic and a hyperlink to another page within the application. The calls to these other entities from the basic page make up the flow.
If you use either the Global Level or the URL Level security template, both the Policy Builder and the Security Enforcer ignore flows. If you decide to use the Flow Level security template for the Policy Builder, the Policy Builder discovers and populates the application flow, and the Security Enforcer verifies the flow properties. For more information on the Policy Builder templates, see Understanding the security templates for the Policy Builder.
Important: Configuring flows is an optional task. Unless you need the enhanced security of configured flows, F5 Networks recommends that you do not configure a flow-based security policy.
1.
In the Application Security navigation pane, click Flows.
The Flows List screen opens.
2.
When you view the flows for a particular URL, the system displays the flow to the particular URL. Note that flows may be associated with explicit URLs only.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, click the name of the URL for which you want to see the flow.
The Allowed URL Properties screen opens.
4.
On the menu bar, click Flows to URL.
The Flows to URL screen opens.
F5 Networks recommends that you use the Policy Builder and the learning process to create and maintain the application flow. Alternately, you can create a flow for a URL manually.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, click the name of the URL for which you want to see the flow.
The Allowed URL Properties screen opens.
4.
On the menu bar, click Flows to URL.
The Flows to URL screen opens.
5.
Above the Flows to URL list, click the Create button.
The Create a New Flow popup screen opens.
6.
In the Referrer URL box, select one of the following:
Entry Point: Specifies that the client can enter the application from this URL
URL Path: Specifies the URL, if the URL is not an entry point.
7.
In the Protocol list, select the appropriate protocol.
8.
In the Method list, select the HTTP method that the URL expects a visitor to use to access the authenticated URL, for example, GET or POST.
9.
In the Frame Target box, type the index (0-29, or 99) of the HTML frame in which the URL belongs, if the web application uses frames.
Tip: If your web application does not use frames, type the value 1.
12.
Click OK.
The popup screen closes, and on the Flows to URL screen, you see the URLs from which the authenticated URL can be accessed.
Tip: Click a URL in the Flows to URL list to open the Flow Properties screen where you can view or modify the flows properties.
13.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Some web applications contain URLs with dynamic names, for example, the links to a server location for file downloads, where the file name may be unique to each user. You can configure the system to detect these URLs by configuring a dynamic flow.
For a dynamic flow, you configure a regular expression that describes the dynamic name, and associate the flow with the URL. The Application Security Manager then extracts the dynamic URL names from URL responses, for which the dynamic flow is configured.
Important: Dynamic flows are relevant only if you are configuring advanced flows with the Policy Builder and the Flow Level security template. Additionally, the URL for which you are configuring a dynamic flow must be configured as a referrer URL.
1.
In the Application Security navigation pane, click URLs.
The Allowed URLs List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed URLs List area, click the name of the URL for which you want to see the flow.
The Allowed URL Properties screen opens.
4.
On the menu bar, click Dynamic Flows From URL.
The Dynamic Flows From URL screen opens.
5.
Click the Create button.
The Create New Dynamic Flow popup screen opens.
6.
In the Prefix box, type a fixed substring that appears near the top of the HTML source page before the dynamic URL. It may be a name of a section in combination with HTML tags, for example, <h3>Flows2URL</h3>.
7.
For the RegExpValue setting, type a regular expression that specifies the set of URLs that make up the dynamic flow, for example, a set of archive files.
8.
For the Suffix setting, type a fixed string that occurs in the referring URLs source code, and is physically located after the reference to the dynamic name URL.
9.
Click the OK button.
The popup screen closes, and on the Dynamic Flows from URL screen, you see the dynamic flow extraction properties.
10.
To put the security policy changes into effect immediately, in the Application Security navigation pane, click URLs, and then click the Apply Policy button in the editing context area.
Your web application may contain URLs that should be accessed only through other URLs. For example, in an online banking application, account holders should be able to access their account information only by logging on through a login screen first. In your security policy, you can configure login URLs to limit access to authenticated URLs. A login URL is a URL in the web application that requests must pass through to get to the authenticated URLs. You can prevent forceful browsing of restricted parts of the web application, by defining access permissions for users.
Using the login pages feature, you can specify one or more login URLs for a web application. If a user tries to bypass the login URLs, the system issues the Login URL bypassed violation. You can also configure login page settings that apply to all login URLs including the expiration time, authenticated URLs, and logout URLs. If a user session is idle and exceeds the expiration time, the system issues the Login URL expired violation, and the user can no longer reach the authenticated URLs. You can use login URLs to enforce idle time-outs on applications that are missing this functionality.
1.
In the Application Security navigation pane, click Flows.
The Flows List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Login Pages.
The Login URLs screen opens.
4.
Click the Create button.
The New Login URL screen opens.
5.
For the Login URL setting, select the appropriate protocol, and then type the URL.
6.
In the Access Validation area, define at least one validation criteria for the login URL response. See the online help for definitions of these settings.
7.
Click the Create button to add the login URL to the security policy.
The new login URL appears in the Login URLs area.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
In the Application Security navigation pane, point to Flows, point to Login Pages, and click Login Pages Settings.
2.
If you want the login URL to be valid for only a certain length of time, set Expiration Time to Enabled, and type a value, in seconds.
3.
For the Authenticated URLs setting, type the name of the URL (may include a wildcard) for which the login URL restricts access, and then click Add. Add as many authenticated URLs as needed.
4.
Optionally, for the Logout URL setting, type the name of the URL that, when accessed, the user must go through the login URL again before being able to access the authenticated URLs. Then click Add. Add as many logout URLs as needed.
5.
Click the Save button.
Depending on the web application, a response may contain sensitive user information, such as credit card numbers or social security numbers (U.S. only). The Data Guard feature can prevent responses from exposing this sensitive information. This process is known as response scrubbing. In addition to protecting credit card numbers and social security numbers, you can configure custom patterns using PCRE regular expressions to match other types of sensitive information. You can also specify exception patterns that you do not want to be considered sensitive data.
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 the security policy enforcement mode is blocking, the system does not send the response to the client.
When you enable the Mask Data option, the system replaces the sensitive data with asterisks (****). F5 Networks recommends that you enable this setting if the security policy enforcement mode is transparent. Otherwise, when the system returns a response, sensitive data could be exposed to the client.
You can configure one additional user-defined response content-type using the internal parameter user_defined_accum_type. If response logging is enabled, these responses can also be logged.
1.
In the Application Security navigation pane, click Data Guard.
The Data Guard screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
If you want the system to consider U.S. social security numbers (in the form nnn-nn-nnnn, where n is an integer) as sensitive data, check the U.S. Social Security Numbers box.
a)
Check the Enable Custom Patterns box.
b)
For New Pattern, use PCRE regular expression syntax to specify the sensitive data pattern, then click Add.
a)
Check the Enable Exception Patterns box.
b)
For New Pattern, use PCRE regular expression syntax to specify the pattern that you do not want to be considered sensitive, then click Add.
8.
Click the Save button to retain any changes you made.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure the security policy to ignore certain cookie headers that are included in an HTTP request, even if they do not meet the expected criteria, and would otherwise trigger a security policy violation. You use the Allowed Modified Cookies property to manage the list of cookies that you want the Security Enforcer to ignore. Typically, allowed modified cookies are cookies that can change on the client side, usually using JavaScript, and these cookies are not session-related.
1.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed Modified Cookies area, click the Create button.
The New Allowed Cookie screen opens.
4.
From the Cookie Name Type list, select whether the system identifies the cookie by a specific name (Explicit), or by a regular expression (Wildcard).
5.
In the Cookie Name box, type either the name of the allowed cookie, or the pattern string for the wildcard to match cookie names.
Tip: For wildcard syntax, refer to Understanding wildcard syntax.
6.
Click Create.
The screen refreshes, and you can see the newly created allowed cookie in the Allowed Modified Cookies area.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Cookie Name column, click the cookie name.
The Edit Allowed Cookie screen opens.
5.
Click Update.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Click the Delete button.
A confirmation popup screen opens.
5.
Click OK.
The system removes the cookie from the security policy.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
If your application uses custom headers that must occur in every request, you can configure them as mandatory headers in the security policy. A mandatory header is a header that must appear in a request for the request to be considered legal by the system. If a request does not contain the mandatory header, the system issues the Mandatory HTTP header is missing violation, and applies the blocking policy to the request.
You can use mandatory headers to make sure, for example, that requests are passing a proxy (which introduces such a header) before they reach the Application Security Manager.
1.
In the Application Security navigation pane, point to Headers and click Mandatory Headers.
The Mandatory Headers screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Click the Create button.
The New Mandatory Header screen opens.
4.
In the New Header box, type the name of the header you want to make mandatory. Mandatory headers are not case-sensitive.
5.
Click Create.
The screen refreshes, and you see the new mandatory header in the list.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
All security policies accept standard HTTP methods by default. The default allowed methods are GET, HEAD, and POST. The system treats any incoming HTTP request that uses an HTTP method other than the allowed methods as an invalid request. If your web application uses HTTP methods other than the default allowed methods, you can add them to the security policy.
1.
In the Application Security navigation pane, click Methods.
The Allowed Methods screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed Methods area, click the Create button.
The New Allowed Method screen opens.
4.
For the Method setting, choose one of the following actions:
Select New Method, and then type the name of a method in the New Method box. Use this option if the method you want to allow is not in the system-supplied list.
5.
In the Act as Method box, select one of the following options:
GET: Specifies that the request does not contain any HTTP data following the HTTP header.
POST: Specifies that the request contains HTTP data following the HTTP header.
6.
Click Create.
The screen refreshes, and on the Allowed Methods screen, you can see the additional allowed method in the Allowed Methods area.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In addition to creating allowed methods, you can also edit or delete existing allowed methods, as required by changes in the web application
Blocking policy
The blocking policy specifies the blocking actions for each of the security policy violations. The blocking policy also specifies the enforcement mode for the security policy. For more information, see Configuring the blocking policy.
Evasion techniques detection
Sophisticated hackers have figured out coding methods that normal attack signatures do not detect. These methods are known as evasion techniques. Application Security Manager can detect the evasion techniques, and you can configure blocking properties for them. For more information, see Configuring blocking properties for evasion techniques.
HTTP Protocol Compliance
The system performs validation checks on HTTP requests to ensure that the requests are formatted properly. You can configure which validation checks are enforced by the security policy. For more information, see Validating HTTP protocol compliance.
Web Services Security
You can configure which web services security errors must occur for the system to learn, log, or block requests that trigger the errors. For information on how to configure web services security errors, see Configuring blocking properties for web services security.
Response pages
When the enforcement mode is blocking, and a request (or response) triggers a violation for which the Block action is enabled, the system returns the response page to the client. If you configure login pages, you can also configure a response page for blocked access. For more information, see Configuring the response pages.
The Blocking Policy screen is where you configure how the security policy reacts to a request that does not comply with the security policy. On the Blocking Policy screen, you configure the enforcement mode for the security policy, and the blocking actions for all of the violations.
The security policy has two enforcement modes: transparent and blocking. In transparent mode, the system allows requests to reach the web application even if the request violates some aspect of the security policy. In blocking mode, the system does not allow requests that violate the security policy to reach the web application, and instead returns the blocking response page to the client. Note that the system blocks requests only for those violations with enabled Block flags. See Configuring the blocking actions, for more information on the Block flag.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
3.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
4.
Click the Save button to save any changes you may have made on this screen.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
In the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose Settings.
The Blocking Policy screen opens.
4.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
5.
Click the Save button to save any changes you may have made on this screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
On the Blocking Policy screen, you can view, and enable or disable, the Learn, Alarm, and Block flags, or blocking actions, for most violations. The blocking actions determine how the system processes requests that trigger the corresponding violation.
Learn
When the Learn flag is enabled for a violation, and a request triggers the violation, the system logs the request and generates learning suggestions. The system takes this action when the security policy is in both transparent mode and blocking mode.
Alarm
When the Alarm flag is enabled for a violation, and a request triggers the violation, the system logs the request, and also logs a security event. The system takes this action when the security policy is in both transparent mode and blocking mode.
Block
When the Block flag is enabled for a violation and a request violates a security policy that has the Block flag enabled, that request is not forwarded to the server. Instead, the system sends the blocking response page (which contains a Support ID to identify the request) to the client. If the violating request meets the conditions of the logging-profile filter that is assigned to the web application, the system logs the information. If a response from the web application triggers a violation for which the blocking action is enabled, the system sends the blocking response page to the client instead of sending the response.
1.
In the Application Security navigation pane, point to Policy, then Blocking, then click Settings.
The Blocking Policy screen opens.
3.
Review each violation and adjust the Learn, Alarm, and Block flags as required. Note that you can configure the Block flags only when the enforcement mode is set to Blocking.
4.
Click Save to save any changes you may have made on this screen.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
For every HTTP request, Application Security Manager examines the request for evasion techniques, which are coding methods used by attackers designed to avoid detection by attack signatures. You can enable or disable the blocking properties for evasion techniques.
1.
In the Application Security navigation pane, point to Policy, Blocking, then click Evasion Techniques.
The Evasion Techniques screen opens.
3.
For each evasion technique, check or clear the Enable Evasion Technique Checks check box as required.
4.
Click the Save button to retain any changes you may have made.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure which HTTP protocol compliance checks the security policy validates and enforces. If a request fails any of the enabled HTTP protocol compliance checks, the system responds according to the Learn/Alarm/Block settings of the HTTP protocol compliance failed violation on the Blocking Policy screen. For information on configuring the compliance checks, see Validating HTTP protocol compliance.
You can configure which web services security errors must occur for the system to learn, log, or block requests that trigger the errors. These errors are sub-violations of the parent violation Web Services Security failure configured on the Blocking Policy screen, as described in Configuring the blocking policy.
If you enable any of these errors and one of them occurs, web services security stops parsing the document. How the system reacts depends on how you configured the blocking settings for the Web Services Security failure violation:
If set to Learn or Alarm, the system does not encrypt or decrypt the SOAP message, and sends the original document to the web service.
If set to Block, the system prevents the document from reaching its intended destination.
1.
In the Application Security navigation pane, point to Policy, then Blocking, then click Web Services Security.
The Web Services Security errors screen opens.
4.
Click the Save button to retain your changes.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The Application Security Manager has a default blocking response page that it returns to the client when the client request, or the web server response, is blocked by the security policy. The system also has a login response page for login violations.
All response pages contain a variable, <%TS.request.ID()%>, that the system replaces with a support ID number when the system issues the page. Customers can use the support ID to identify the request when making inquiries.
1.
In the Application Security navigation pane, point to Policy, and then click Response Page.
The Blocking Response Page screen opens.
3.
Click the Edit button for either the blocking or login response page.
The Response Page 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 response page in HTML. Note that you cannot edit the text.
Custom Response: Specifies that the system returns a response page with HTML code that you define.
Redirect URL: Specifies that the system redirects the user to a specific web page.
SOAP Fault: Specifies that the system returns the system-supplied blocking response page in XML format. Note that you cannot edit the text.
Note: The settings on the screen change depending on the selection that you make for the Response Type setting.
5.
If you selected the Redirect URL option in step 4, then in the Redirect URL box, type the URL to which the system redirects the user, for example, http://www.myredirectpage.com. The URL that you configure should be for a page that is not within the web application itself.
To redirect the blocking page to a URL with a support ID in the query string, type the URL and the support ID in the following format:
The system replaces <%TS.request.ID%> with the relevant support ID so that the blocked request is redirected to the URL with the relevant support ID.
6.
If you selected the Custom Response option in step 4, you can either modify the default text 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.
b)
For the Response HTML Code setting, click the Paste Default Response HTML Code button, and make any changes as required. Use standard HTTP syntax.
a)
For the Upload HTML File setting, either type a path to an HTML response page in the box, or click Browse and navigate to an HTML response page.
b)
Click Upload when you are finished.
7.
Click Save.
The Blocking Response Page opens.
8.
For either the blocking or login response page, click Show.
A popup screen shows the text as it will appear to recipients.
9.
To put the security policy changes into effect immediately, click the Apply Policy button near the top of the Policy Properties screen.
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)