Applies To:
Show VersionsBIG-IP ASM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
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
Changing security policy enforcement
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
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
Differentiating between HTTP and HTTPS URLs
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
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
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 should not configure trusted XFF headers if you think the HTTP header may be spoofed, or crafted, by a malicious client.
Adding host names
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.