F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Changing Security Policy Settings
Manual Chapter : Changing Security Policy Settings

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Changing Security Policy Settings

About security policy settings

The security policy settings determine how the security policy is built. The Deployment wizard initially specifies the values of these settings when you create the policy. You can change the values, but understand that the security policy will have different characteristics than it originally did.

Editing an existing security policy

When you create a security policy using the Deployment wizard, the system uses default values for some of the settings. You can access a security policy for editing either from the Active Policies screen or from the Current edited policy setting. The Current edited policy setting appears at the top of almost every security policy screen throughout Application Security Manager™.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. Make any changes that are required for that security policy, such as to properties, URLs, parameters, and so on.
  4. To quickly access the Properties screen for a security policy, click the Current edited policy link in the editing context area.
  5. Click Save to save your settings.
  6. To put the security policy changes into effect immediately, click Apply Policy.
  7. To edit other security policies, from the Current edited policy list, select the security policy you want to edit.

Changing security policy enforcement

Security policies can be in one of two enforcement modes: transparent or blocking. The enforcement mode specifies whether the system simply logs or blocks a request that triggers a security policy violation. You can manually change the enforcement mode for a security policy depending on how you want the system to handle traffic that causes violations.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. For the Enforcement Mode setting, specify how to treat traffic that causes violations.
    • To block traffic that causes violations (that are set to block), select Blocking.
    • To stop allow traffic even if it causes violations so you can review the violations, select Transparent.
  4. Click Save to save your settings.
  5. To put the security policy changes into effect immediately, click Apply Policy.

When the enforcement mode is set to transparent, traffic is not blocked even if a violation is triggered. The system typically logs the violation event (if the Learn flag is set on the violation). You can use this mode along with an enforcement readiness period when you first put a security policy into effect to make sure that no false positives occur that would stop legitimate traffic.

When the enforcement mode is set to blocking, traffic is blocked if it causes a violation (that is configured for blocking), and the enforcement readiness period is over. You can use this mode when you are ready to enforce a security policy.

Adjusting the enforcement readiness period

For each security policy, you can configure the number of days used as the enforcement readiness period, also called staging. Security policy entities and attack signatures remain in staging for this period of time before the system suggests that you enforce them. Staging allows you to test security policy entities and attack signatures for false positives without enforcing them. The default value of 7 days works for most situations so you typically do not need to change it.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. For the Enforcement Readiness Period, type the number of days you want the entities or signatures to be in staging; this is also how long you want the security policy to learn explicit entities for wildcards (when learning is set to Add All Entities).
    The default value is 7 days.
  4. Click Save to save your settings.
  5. To put the security policy changes into effect immediately, click Apply Policy.

During the enforcement readiness period, the system does not block traffic, even if requests trigger violations against the security policy and the violations are set to Block. The security policy provides suggestions when requests match the attack signatures or do not adhere to the security policy entity's settings.

If you enable the option to learn explicit entities on the wildcard entities, the system learns the explicit file types, parameters, or URLs that the web application uses. You can review the new entities and decide which are legitimate entities for the web application, and accept them into the security policy.

If you are using automatic policy building and the system has processed sufficient traffic, after the enforcement readiness period is over, the Real Traffic Policy Builder® automatically enforces the security policy entities and the attack signatures that did not cause violations during the period.

Viewing whether a security policy is case-sensitive

When you first create a security policy using the Deployment wizard, you have the option of making a security policy case-sensitive. By default, the option Security Policy is case sensitive is selected, and the security policy treats file types, URLs, and parameters as case-sensitive. You cannot change this setting after the security policy is created, but you can view how it is set.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. Review the Security Policy is case sensitive setting.
    If the value is Yes, the security policy is case-sensitive; if the value is No, the policy is not case-sensitive.
  4. Click Cancel when you are done.

Differentiating between HTTP and HTTPS URLs

When creating a security policy, you can determine whether a security policy differentiates between HTTP and HTTPS URLs. Later, you can view the setting, but you can change it only if the security policy contains no URLs that have the same name and use different protocols.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. Review the Differentiate between HTTP and HTTPS URLs setting.
    If the Enabled check box is selected, the security policy differentiates between HTTP and HTTPS URLs. Otherwise, it does not, and creates protocol-independent URLs.
  4. Click Cancel when you are done.

If the Differentiate between HTTP and HTTPS URLs setting is disabled, the security policy configures URLs without specifying a specific protocol. This is useful for applications that behave the same for HTTP and HTTPS, and it keeps the security policy from including the same URL twice.

Specifying the response codes that are allowed

You can specify which responses a security policy permits. By default, the Application Security Manager™ accepts all response codes from 100 to 399 as valid responses. Response codes from 400 to 599 are considered invalid unless added to the Allowed Response Status Codes list. By default, 400, 401, 404, 407, 417, and 503 are on the list as allowed HTTP response status codes.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. From the list, select Advanced.
  4. If you want to allow additional responses for the Allowed Response Status Codes setting, in the New Allowed Response Status Code field, type the HTTP response status code, between 400 and 599, that the security policy should consider a legal response, and click Add.
  5. If you do not want to allow any response codes between 400 and 599, click Remove All.
  6. Click Save to save your settings.
  7. To put the security policy changes into effect immediately, click Apply Policy.

The security policy considers legal responses that return response codes that are listed as allowed response codes. If a response contains a response status code from 400 to 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.

Activating ASM iRule events

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, or to cause an action to occur. For detailed information on iRules, see the F5 Networks DevCentral web site, http://devcentral.f5.com. If you are using iRules to perform actions based on Application Security Manager™ iRule events, you must instruct ASM™ to trigger iRule events. By default, the trigger iRule event setting is disabled.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. From the list, select Advanced.
  4. If you have written iRules to process application security events, for the Trigger ASM iRule Events setting, select the Enabled check box.
    Leave this option disabled if you have not written any ASM iRules, or you have written iRules not for ASM (triggered by the Local Traffic Manager™).
  5. For the ASM iRules Event Mode setting, select the mode to use.
    • Recommended: If you are writing new iRules, such as those that perform a specific action after handling requests, select Normal Mode. Whenever ASM processes a request, it triggers an ASM_REQUEST_DONE event.
    • Not recommended: If you are using iRules that use ASM_REQUEST_VIOLATION, select Compatibility Mode. Whenever ASM processes a request with a violation, it triggers an ASM_REQUEST_VIOLATION event. F5 recommends that you rewrite the iRules using ASM_REQUEST_DONE in the Normal Mode.
  6. Click Save to save your settings.
  7. To put the security policy changes into effect immediately, click Apply Policy.
If you write iRules that process ASM iRule events and assign them to a specific virtual server, when the trigger iRules setting is enabled, ASM triggers iRule events for requests. If the trigger iRules setting is not enabled, no iRule events occur for ASM iRule events.

Application security iRule events

These are the events that iRules® can subscribe to in Application Security Manager™.

Application Security iRule Event Description
ASM_REQUEST_DONE Occurs when Application Security Manager finishes processing a request in Normal mode (regardless of whether a violation occurred or not). The system triggers this event after deciding what to do with the request, block it or forward it, but before actually executing that action, so you can specify a change to that action.
ASM_REQUEST_BLOCKING Occurs when Application Security Manager is generating an error response to the request that caused a violation, and gives the iRule a chance to modify the response before it is sent. Allows you to modify the blocking page.
ASM_RESPONSE_VIOLATION Occurs when Application Security Manager detects a response that violates a security policy.
ASM_REQUEST_VIOLATION Deprecated. Use ASM_REQUEST_DONE instead. Occurs when Application Security Manager detects a request that violates a security policy when using Compatibility mode only.
Notes

From any of these events, you can use the ASM::fingerprint command to get fingerprinting information from a request. For example:

when ASM_REQUEST_DONE {
    log local0.[ASM::fingerprint]
}

If fingerprinting information is available, this example returns the fingerprint ID. If it is not available, the example returns 0.

The fingerprint ID is a number representing the client's browser. If requests coming from a particular fingerprint ID contain violations, you could mark that ID as suspicious and treat future requests from that ID differently.

Allowing XFF headers in requests

You can configure Application Security Manager™ (ASM) to trust XFF (X-Forwarded-For) headers or customized XFF headers in requests. For example, you could do this if ASM 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 proxy’s IP address. This option is useful for logging, web scraping, anomaly detection, and the geolocation feature.

You should not configure trusted XFF headers if you think the HTTP header may be spoofed, or crafted, by a malicious client.

  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. From the list, select Advanced.
  4. For the Trust XFF Header setting, select the Enabled check box.
    The screen displays the Custom XFF Headers configuration option.
  5. If your web application uses custom XFF headers, in the Custom XFF Headers setting, add them as follows:
    1. In the New Custom XFF Header field, type the XFF header that the system should trust.
    2. Click Add.
    You can add up to five custom XFF headers.
  6. Click Save to save your settings.
  7. To put the security policy changes into effect immediately, click Apply Policy.
When you trust XFF headers, the system has confidence in XFF headers in the request. If you added custom XFF headers, the system recognizes and trusts them. If deployed behind a proxy, ASM uses the initiating IP address rather than the address of the proxy.

Adding host names

You can manually add legitimate host names to a security policy, for example, if users can access the application from multiple host names. If you are using automatic policy building, the system automatically adds domain names to the security policy so adding them in that case is optional.
  1. On the Main tab, click Security > Application Security > Headers > Host Names .
    The Host Names screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. Above the list of host names, click the Create button.
    The New Host Name screen opens.
  4. In the Host Name field, type the host name that is used to access the web application (either a domain name or an IP address).
  5. To include all sub-domains of the specified host name, select the Include Sub-domains check box.
  6. Click Create.
  7. To put the security policy changes into effect immediately, click Apply Policy.
The host name is added to the list of host names that can legitimately be used to access the web application that the security policy is protecting.

About adding multiple host names

If users can access a web application using multiple host names or IP addresses, you can add the multiple host names or IP addresses to the security policy that protects the application. The system uses this list of host names as follows:

  • The Policy Builder considers the host names in the list to be legitimate internal links and forms, and learns security policy entities from them, and also from relative URLs that do not contain a domain name.
  • The CSRF feature uses the list to distinguish between internal and external links and forms, and the system inserts the CSRF token only into internal links and forms.

The Application Security Manager™ (ASM) identifies web application-related host names as fully qualified domain names (FQDNs) in requests or responses. If you include sub-domains with the host name, the system matches all sub-domains when evaluating FQDNs, and inserts ASM™ cookies into responses from the sub-domains of the host name. When an application uses several sub-domains, ASM cookie-based features (like CSRF protection, Login Pages, and Dynamic Sessions ID in URL) require ASM cookies to be inserted from the correct domain.

Protecting against cross-site request forgery (CSRF)

Cross-site request forgery (CSRF) is an attack where a user is forced to execute unauthorized actions (such as a bank transfer) within a web application where the user is currently authenticated. You can configure a security policy to protect against CSRF attacks, including specifying which URLS you want the system to examine.
  1. On the Main tab, click Security > Application Security > CSRF Protection .
    The CSRF Protection screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. Select the CSRF Protection check box.
  4. Specify which part of the application you want to protect against CSRF attacks:
    • To protect SSL requests only in the secured part of the application, select the SSL Only check box.
    • To protect the entire web application, leave the SSL Only check box cleared.
  5. If you want the CSRF token (which is injected into responses) to expire:
    1. For Expiration Time, select Enabled.
    2. In the field, type the amount of time, in seconds (1 to 99999), after which the token should expire.
      The default is 600 seconds.
  6. In the URLs List (Wildcards supported) setting, specify the URLs you want the system to examine.
    You need to add at least one URL to the list. The system considers all URLs not on the list safe unless another problem is discovered.
    1. Type the URL in the format /index.html.
      You can also use wildcards for URLs; for example /myaccount/*.html, /*/index.php, or /index.?html.
    2. Click Add.
    3. Add all of the potentially unsafe URLs that you want the system to examine.
  7. Click Save to save your settings.
  8. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  9. In the Policy Building Settings (in the Advanced settings), expand CSRF Protection, and click the appropriate Learn, Alarm, and Block settings in the two CSRF violations.
    Tip: If you want to block CSRF attacks, click Block for CSRF attack detected. Also in the General Settings, check that Enforcement Mode is set to Blocking.
  10. Click Save to save your settings.
  11. To put the security policy changes into effect immediately, click Apply Policy.
The system inserts an Application Security Manager™ token to prevent CSRF attacks. If the system detects a CSRF attack, it issues a CSRF attack detected violation. To prevent token hijacking, the system reviews the token expiration date. If the token is expired, the system issues the CSRF authentication expired violation.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information