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

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Configuring Manual Security Policy Settings

Editing an existing security policy

When you create a security policy using the Deployment wizard, the system uses default values. If you are manually building the security policy rather than using the Policy Builder, you can edit the security policy. You can access a security policy for editing either from the Active Policies screen or from the editing context area. The editing context area appears at the top of almost every security policy component 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 Properties screen opens.
  3. Make any changes that are required for that security policy, such as to 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, for Current edited policy, select the security policy you want to edit.

Changing security policy enforcement

An enforcement mode specifies how the system processes a request that triggers a security policy violation. Security policies can be in one of two enforcement modes: transparent or blocking. 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 > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Properties screen opens.
  3. In the Configuration area, for the Enforcement Mode setting, specify how to treat traffic that causes violations.
    • To block traffic that causes violations, select Blocking.
    • To stop traffic from being blocked and 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 (configured for blocking), and the enforcement readiness period is over. You 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. 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 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 (in Add All Entities mode).
    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. 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 enables 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 what the setting is.
  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 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 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 Properties screen opens.
  3. From the Configuration 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 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 Properties screen opens.
  3. From the Configuration 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.

Configuring trusted XFF headers

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 Properties screen opens.
  3. From the Configuration 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 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: check box.
    • 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 session cookie (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 cookie should expire.
      The default is 600 seconds.
  6. In the URLs List setting, specify the URLs you want the system to examine.
    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. To put the security policy changes into effect immediately, click Apply Policy.
If the system detects a CSRF attack, it issues a CSRF attack detected violation. The system inserts an Application Security Manager™ token to prevent CSRF attacks. To prevent token hijacking, the system reviews the token expiration date. If the token is expired, the system issues the CSRF authentication expired violation.
If you want to block requests suspected of being CSRF attacks, in addition to enabling CSRF protection, you also need to set the security policy enforcement mode to Blocking. Also, one or both of the CSRF violations must have the Block flag enabled. Though these violations are set to block by default, CSRF protection must be enabled for this feature to work.
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