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

  • 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

About security policy settings

The security policy settings determine how the security policy is built. You initially specify 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, the system uses default values for some of the settings. You can access a security policy for editing either from the Policies List or from the Current edited security policy setting. (For parent policies, it is the Current edited parent policy.) The Current edited security 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 > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. Make any changes that are required for that security policy, such as to general settings, URLs, parameters, and so on.
  3. Click Save to save your settings.
  4. To put the security policy changes into effect immediately, click Apply Policy.
  5. 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 security policy list near the top of the screen, verify that the security policy shown 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 well for most situations so you typically do not need to change it.
  1. On the Main tab, click Security > Application Security > Policy > Policy Properties .
    The Policy Properties screen for the current edited policy opens.
  2. For the Enforcement Readiness Period, type the number of days you want the entities or signatures to be in staging.
    The default value is 7 days.
  3. Click Save to save your settings.
  4. 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 are using automatic policy building and the system has processed sufficient traffic, after the enforcement readiness period is over, the 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, you have the advanced option of making a security policy case-sensitive or not. 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 > Policy > Policy Properties .
    The Policy Properties screen for the current edited policy opens.
  2. Review the 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.
  3. 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 Policies List screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Summary 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 > Policy > Policy Properties .
    The Policy Properties screen for the current edited policy opens.
  2. From the list, select Advanced.
  3. 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.
  4. If you do not want to allow any response codes between 400 and 599, click Remove All.
  5. Click Save to save your settings.
  6. 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 > Policy > Policy Properties .
    The Policy Properties screen for the current edited policy opens.
  2. From the list, select Advanced.
  3. 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™).
  4. 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.
  5. Click Save to save your settings.
  6. 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 > Policy > Policy Properties .
    The Policy Properties screen for the current edited policy opens.
  2. From the list, select Advanced.
  3. For the Trust XFF Header setting, select the Enabled check box.
    The screen displays the Custom XFF Headers configuration option.
  4. 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.
  5. Click Save to save your settings.
  6. 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 security policy list near the top of the screen, verify that the security policy shown 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. If you also want to use all sub-domains of the specified host name to access the web application, select the Include Sub-domains check box.
  6. If you want to make sure all the traffic to the host is not blocked even if it has blocking violations, select Policy is always transparent for this host.
    This is useful when deploying the policy on a new application that needs to be tested before moving to blocking mode while still securing other applications protected by the same policy.
    This setting causes the policy to operate in transparent mode only for the application identified with this host name, while still working in blocking mode on other applications protected by the policy. For a host name with different enforcement, the event log shows the blocking override reason as Host name is configured as transparent.
  7. Click Create.
  8. 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. The list shows the enforcement mode of the host name (transparent or blocking).

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 carry out 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.
CSRF protection provides two enforcement options:
  • Verify CSRF Token: The system inserts a CSRF token to application URLs using JavaScript injection. Requests without a valid CSRF token are blocked. 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.
  • Verify Origin: The system blocks requests without a valid Origin header(such as a CSRF request, which has no Origin header). This enforcement option can protect an AJAX request of an application, because AJAX requests always contain an Origin header. If all protected URLs are configured with Verify Origin, the system does not do JavaScript injection. If the system detects a request without a valid Origin header, it issues a CSRF attack detected violation.

CSRF attacks specifically target state-changing requests (for example, transferring funds or changing an email address). State-changing requests are usually POST requests,but, in some cases, may be performed using GET requests. There are two modes for entering URLs for CSRF protection:

  • Simple Edit Mode: Defines URLs for CSRF token verification during a POST method.
  • Advanced Edit Mode: Defines URLs for additional methods, required parameters and enforcement actions.
  1. On the Main tab, click Security > Application Security > CSRF Protection .
    The CSRF Protection screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown 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 (for POST requests with CSRF token verification only) setting, select Simple Edit Mode and specify at least one URL (and its method) that you want the system to examine.
    The system considers all URLs that are not on the list to be safe unless it discovers another problem .
    If you need to specify methods other than POST, or request parameters, or use the Verify Origin enforcement option, you should select Advanced Edit Mode.
    1. Select the Method for request verification.
    2. Type the URL in the format /index.html.
      You can also use wildcards for URLs; for example, /myaccount/*.html, /*/index.php, or /index.?html.
    3. Click Add.
    4. Repeat steps a through c to add all of the potentially unsafe URLs that you want the system to examine.
  7. From the URL list, in the Required Parameters column, define any required parameters for the URL.
  8. From the URL list, in the Enforcement Action column, select the enforcement action to take.
  9. Click Save to save your settings.
  10. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  11. Select the Advanced setting, and in the Policy Building Settings area, expand CSRF Protection, then 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 area, check that Enforcement Mode is set to Blocking.
  12. Click Save to save your settings.
  13. To put the security policy changes into effect immediately, click Apply Policy.
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