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

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 14.0.0
Manual Chapter

Changing Security Policy Settings

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 Building
    Learning and Blocking Settings
    .
    The Learning and Blocking Settings screen 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.

Making a parent policy mandatory

You can mandate that all new policies created or imported be a child of a compatible parent policy. The parent must have the same partition or in the /common partition and all mandatory inheritance attributes, encoding language, protocol independence and case sensitivity match as the child policy. The default is not enabled.
  1. On the Main tab, click
    Security
    Options
    Application Security
    Advanced Configuration
    Parent Policy Settings
    .
  2. Select
    Enabled
    .
  3. Click
    Save
     to save your setting.
When enabled, if no accessible parent policy exists, a security policy can be created as a stand-alone security policy. However, if a parent policy exists and is accessible but is not suitable, you must create a suitable parent policy before continuing to create the child security policy. Existing child security policies are able to switch parents but cannot be orphaned. Security policies, without a parent policy, which existed before enabling this feature will not be affected and will remain stand-alone security policies without a parent but can be associated with a compatible parent policy at any time.

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
    Security Policies
    Policies List
    .
    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
    Security Policies
    Policies List
    .
    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
    Security Policies
    .
    The Policies List screen 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 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
      .
    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. Click
    Save
     to save your settings.
  5. 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
    Policies List
    .
    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.
    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
    .
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information