Applies To:
Show VersionsBIG-IQ Centralized Management
- 5.4.0
About application security policies in Web Application Security
Web Application Security imports BIG-IP® Application Security Manager™ (ASM) application security policies from discovered BIG-IP devices, and lists them on the Web Application Security policy editor Policies screen. Each security policy is assigned a unique identifier that it carries across the enterprise. This ensures that each policy is shown only once in the Policies screen, no matter how many devices it is attached to. In the Web Application Security repository, policies are in XML format.
About subcollections in policies
Subcollections are groups of like objects related to the Web Application Security policy. Not all subcollections are visible in the Web Application Security policy editor. Other subcollections can be imported and deployed without being displayed. Generally, you can import subcollections from a BIG-IP device and then deploy them without editing. Note that you cannot manage wildcard ordering for subcollections using the BIG-IQ® Centralized Management user interface.Following is a list of the supported versions of the BIG-IQ Centralized Management system and the BIG-IP device for each subcollection. Refer to the release notes for BIG-IQ Centralized Management for detailed information on BIG-IP device and BIG-IQ Centralized Management system support, such as the minimum F5® TMOS® version supported for this release.
Subcollection | Discovery and Deployment Support | Edit Support using BIG-IQ GUI | Minimum BIG-IP Device Version Support | Comments |
---|---|---|---|---|
Policy and properties | Yes | Yes | Any | |
Character Sets | Yes | Yes | Any | The BIG-IQ Centralized Management user interface can be used to edit parameter names and parameter values. |
Data Guard | Yes | Yes | Any | |
File Types | Yes | Yes | Any | |
IP Address Exceptions | Yes | Yes | Any | |
Parameters | Yes | Yes | Any | |
Extractions | Yes | Yes | 11.6.0 | |
Response Pages | Yes | Yes | Any | Learning using the Central Policy Builder is not applicable for use with response pages. |
Signatures | Yes | Yes | Any | |
Signature Sets and attack signature configuration | Yes | Yes | Any | Filter-based sets are supported, manual sets are not. |
Blocking settings - violations | Yes | Yes | Any | No support for user defined violations. |
Blocking settings - evasions | Yes | Yes | Any | |
Blocking settings - HTTP protocol compliance | Yes | Yes | Any | |
Blocking settings - web services securities | Yes | Yes | Any | |
Policy Builder | Yes | Yes | Any | Learning using the Central Policy Builder is not applicable for use with the local Policy Builder. |
Central Policy Builder | Yes | Yes | 13.1.0 | Learning using the Central Policy Builder is not supported with GWT content profiles, and is non-applicable for response pages, local policy builder, web scraping, and brute force attack prevention. |
Allowed methods | Yes | Yes | Any | |
Headers | Yes | Yes | Any | |
Cookies | Yes | Yes | Any | |
Host names | Yes | Yes | Any | |
Geolocation enforcement | Yes | Yes | 11.6.0 | |
IP Intelligence | Yes | Yes | 11.6.0 | |
Redirection protection | Yes | Yes | 11.6.0 | |
Sensitive parameters | Yes | Yes | Any | |
Web scraping | Yes | No | 12.0.0 | Learning using the Central Policy Builder is not applicable for use with web scraping. |
CSRF protection | Yes | Yes | 11.6.0 | When editing policies deployed to BIG-IP device versions earlier than 13.1, URLs added
to the CSRF URLs list must have the following settings:
|
JSON Content Profiles | Yes | Yes | 11.6.0 | |
XML Content Profiles | Yes | Yes | 11.6.0 | Schemas and WSS are not supported. |
GWT Content Profiles | Yes | No | 11.6.0 | Learning using the Central Policy Builder is not supported with GWT content profiles. |
Plain Text Content Profiles | Yes | Yes | 12.1.0 | |
URLs | Yes | Yes | Any | Flow configuration for URLs is not supported, such as referrer, check flows, check pd/qa, allow pd/qs, or isEntryPoint. |
Websocket URLs | Yes | Yes | 12.1.0 | |
Login Pages | Yes | Yes | 11.6.0 | |
Login Enforcement | Yes | Yes | 11.6.0 | |
Brute Force Attack Preventions | Yes | Yes | 11.6.0 | Learning using the Central Policy Builder is not applicable for use with brute force attack prevention. |
Session Tracking Configuration | Yes | Yes | 11.6.0 | Only configuration is supported, there is no support for online tracking data. |
Layered Policy | Yes | Yes | 13.0.0 | |
Inheritance Settings | Yes | Yes | 13.0.0 | |
Enforcement Readiness | Yes | Yes | Any | |
Server Technologies | Yes | Yes | 13.1.0 |
Overview of layered policies and inheritance
You can use Web Application Security to create and manage two layers of security policies: parent policies and child policies. This feature is new with BIG-IP® version 13.0 and BIG-IQ® Centralized Management version 5.2. Parent policies include mandatory policy elements, and child policies inherit those attributes from the parent. When the parent policy is updated, the associated child policies are automatically updated.
With parent policies you can:
- Create and maintain common elements and settings.
- Impose mandatory elements on child policies.
- Push a change to multiple child policies.
You can specify which parts of the security policy must be inherited, which are optional, and which are not inherited. This allows you to keep child policies synchronized with the changes in the global mandatory policies and still allow the child policies to address their own unique requirements.
You establish the parent and child policy relationship as follows:
- Identify the current policy as a parent policy.
On the General Properties screen for the policy, set the Policy Type to Parent Policy. Navigate to , then click the policy to edit, and click
- Set a policy to be the child policy of the
parent policy.
On the Inheritance Settings screen for the policy, select the parent policy for a child policy by selecting the parent policy name in the Parent Policy setting. Navigate to , then click the policy to become a child policy and click .
- Click Save to save this policy as a child policy and display the inheritance properties.
- Continue to use the Inheritance Settings screen to accept or decline what is to be inherited from the parent policy.
By default, the Parent Policy field is set to None, and there is no layered policy use (no child or parent policies).
Refer to the BIG-IP Application Security Manager: Getting Started guide for additional information on using parent and child layered policies.
Overview of central policy building
You can use the Central Policy Builder feature to receive policy building learning suggestions from multiple BIG-IP® devices, rather than have each BIG-IP device perform policy learning in isolation. Using the Central Policy Builder, the learning suggestions from all BIG-IP devices are combined to improve the policy.
Using the Central Policy Builder:
- Each BIG-IP device sends learning suggestions for a particular policy to the centralized policy building device or devices. These devices are BIG-IQ data collection devices (DCD) that have the Web Application Security service activated on them.
- The policy learning suggestions from all BIG-IP devices are combined so that you can view and manage them on the BIG-IQ Centralized Management system.
- As suggestions are accepted and the policy is tuned, you can choose to deploy the policy to one or more of the BIG-IP devices that use it.
Configuring central policy building
- A BIG-IP® version 13.1 or later device with ASM® provisioned and licensed.
- A BIG-IQ® Centralized Management version 5.4 or later system, with the Web Application Security service installed and the BIG-IP device discovered and imported. Data collections devices also need to be configured.
How do I determine what permissions to apply to roles accessing child and parent policies?
- Click .
- Click Add. The New Role Type properties screen opens.
- Select Web Application Security (ASM) as the service. Those object types are displayed.
- Select Policies: Web Application Security as the object type, and click Add Selected.
- To define access to standalone policies that do not use inheritance, select from the permissions without the Child or Parent prefix: Read, Add, Edit, or Delete.
- To define access to only child policies, select permissions with the Child prefix: Child Create, Child Delete, or Child Edit.
- To define access to only parent policies, select permissions with the Parent prefix: Parent Create, Parent Delete, or Parent Edit.
Regardless of the type of policy, you should always allow users Read access to the policy.
Edit application security policies
Edit general property settings
- Go to the General Properties screen: click .
- Click the name of the policy to modify, and then on the left click General Properties.
- Edit the properties as appropriate.
- Save your changes to the general properties of the policy.
General property settings
These properties are the general configuration options and settings that determine the overall behavior and functionality of the security policy.
Property | Description |
---|---|
Name | Unique name of the security policy. You can set the Name only when you create the policy. |
Partition | Partition to which the security policy belongs. Only users with access to a partition can view the objects that it contains. If the policy resides in the Common partition, all users can access it. |
Description | Optional description of the security policy. Type in any helpful details about
the policy.
Note: This field is limited
to 255 characters.
|
Full Path | Full path to the security policy. |
Policy Type | Indicates the type of policy.
|
Parent Policy | Specifies the parent policy associated with this policy, if any.
|
Application Language | A language encoding for the web application, which determines how the security policy processes the character sets. The default language encoding determines the default character sets for URLs, parameter names, and parameter values. |
Security Policy is case sensitive | If enabled, the security policy treats file types, URLs, and parameters as case-sensitive. When this setting is disabled (not checked), the system stores these policy elements in lowercase in the policy configuration. |
Event Correlation Reporting | If enabled, events are reported in groups (correlated), rather than as individual transactions. You can only disable this setting for BIG-IP devices version 13.1 or later. |
Learning Mode | Select one of the options to indicate how the policy learns:
|
Enforcement Mode | Specifies how the system processes a request that triggers a security policy
violation.
|
Enforcement Readiness Period | Indicates the number of days in the period. The default is 7 days. Both security policy entities and attack signatures remain in staging mode before the system suggests you enforce them. The system does not enforce policy entities and attack signatures in staging. Staging allows you to test the policy entities and the attack signatures for false positives without enforcing them. |
Mask Credit Card Numbers in Request Log | When enabled, they system masks credit card numbers in the request log. If disabled (cleared), credit card numbers are not masked. |
Maximum HTTP Header Length | Specifies the maximum length of an HTTP header name and value that the system processes. The default setting is 8192 bytes. The system calculates and enforces the HTTP header length based on the sum of the length of the HTTP header name and value. To specify a value for length, type a different value in the field. To specify that any length is acceptable, clear the field. An empty field (a value of any) indicates that there are no restrictions on the HTTP header length up to 8192 bytes. |
Maximum Cookie Header Length | Specifies the maximum length of a cookie header name and value that the system processes. The default setting is 8192 bytes. The system calculates and enforces a cookie header length based on the sum of the length of the cookie header name and value. To specify a value for length, type a different value in the field. To specify that any length is acceptable, clear the field. An empty field (a value of any) indicates that there are no restrictions on the cookie header length up to 8192 bytes. |
Allowed Response Status Code | Specifies which requests the security policy permits, based on the HTTP response status codes they return. Click the gear icon to add or delete response codes. |
Dynamic Session ID in URL | Specifies how the security policy processes URLs that use dynamic sessions. Click
the gear icon to change the setting or create a custom pattern.
|
Trigger ASM iRule Events | When enabled, specifies that Web Application Security activates ASM™ iRule events. Specifies, when disabled, that Web Application Security does not activate ASM iRule events. The default setting is disabled. Leave this option disabled if you either have not written any ASM iRules® or have written iRules that are not ASM iRules. iRule events that are not ASM are triggered by the Local Traffic Manager™. Enable this option if you have written iRules that process ASM iRule events, and assigned them to a specific virtual server. |
Trust XFF Header | When set to No (the default), specifies that the system
does not have confidence in an XFF (X-Forwarded-For) header in the request. Leave this
option disabled if you think the HTTP header may be spoofed, or crafted, by a
malicious client. With this setting disabled, if Web Application Security is deployed
behind an internal proxy, the system uses the internal proxy’s IP address instead of
the client’s IP address. If Web Application Security is deployed behind an internal or
other trusted proxy, you can click the gear icon to change the setting and specify
that the system has confidence in an XFF header in the request. Select the Trust XFF Headers check box and add a required custom header (use a-z, A-Z, no whitespace allowed). The system then uses the IP address that initiated the connection to the proxy instead of the internal proxy’s IP address. |
Handle Path Parameters | Specifies how the system handles path parameters that are attached to path
segments in URIs.
|
Edit inheritance settings
Edit child policy overview settings
- Navigate to the Child Policy Overview screen: click .
- Click the name of the policy you want to review, and click Child Policy Overview.
-
Review the inheritance settings for child policies associated with the parent
policy.
- Click All to view all properties that could be inherited by a child policy.
- Click Declined to view only the properties that a child policy declined to inherit.
- Expand each policy section in the list to review the inheritance status (declined or accepted) for each child policy.
-
Indicate whether you have reviewed declined inheritance properties. In the
Policy Section row for a child policy property:
- Click Mark as Read to indicate that you have reviewed a declined property for a child policy.
- Click Mark as Unread to indicate that you have not reviewed a declined property for a child policy.
- Click Mark All as Read to indicate that you have reviewed all declined properties within that heading.
- To enter a comment, click the comment icon in the row. To remove all comments in a section, click Clear All in the heading row for a policy section.
- Click Save to save your changes.
Response page editing
You can review and change the settings on various types of response pages. Response page settings specify the response content that the system sends to the user when the security policy blocks a client request.
Edit Ajax response page settings
Edit CAPTCHA response page settings
Edit CAPTCHA fail response page settings
Edit default response page settings
You use the Default Response Pages screen to view and edit the settings for the default response page, which is one of several response pages. Response page settings specify the content of the response that the system sends to the user when the security policy blocks a client request.
- Go to the Default Response Page screen: click .
- Click a policy name, and then click .
-
Select a Response Type from the list. Your selection
determines the additional settings.
Option Description Default Response The screen displays the default response header and response body. The system sends the response body to the client as shown. You cannot edit these fields. Click Preview On to preview the response. Custom Response The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response. - Click Choose File to select the file containing the response body, and then click Upload to insert it.
- Click Preview On to preview the response.
- If you want to return to the original default response text for the header or the body, click Paste Default Response Header or Paste Default Response Body.
Redirect URL The system redirects the user to a specific web page instead of displaying a response page. You must enter a URL in the Redirect URL field. Soap Fault The system blocks a SOAP request due to an XML-related violation. The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
Click Preview On to preview the response.Erase Cookies The system deletes all client side domain cookies. This is done in order to block web application users once, and not from the entire web application. The system displays this text in the response page. You cannot edit this text. The response header and response body are shown. Click Preview On to preview the response. - When you are finished, save your changes.
Edit failed login honeypot response page settings
Edit cookie hijacking response page settings
Edit mobile application response page settings
Edit login response page settings
- Go to the Login Pages Response Page screen: click .
- Click a policy name, and then click .
-
Select a Response Type from the list. Your selection
determines the additional settings.
Option Description Default Response The screen displays the default response header and response body. The system sends the response body to the client as shown. You cannot edit these fields. Click Preview On to preview the response. Custom Response The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response. - Click Choose File to select the file containing the response body, and then click Upload to insert it.
- Click Preview On to preview the response.
- If you want to return to the original default response text for the header or the body, click Paste Default Response Header or Paste Default Response Body.
Redirect URL The system redirects the user to a specific web page instead of displaying a response page. You must enter a URL in the Redirect URL field. Soap Fault The system blocks a SOAP request due to an XML-related violation. The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
Click Preview On to preview the response.Erase Cookies The system deletes all client side domain cookies. This is done in order to block web application users once, and not from the entire web application. The system displays this text in the response page. You cannot edit this text. The response header and response body are shown. Click Preview On to preview the response. - When you are finished, save your changes.
Edit XML response page settings
- Go to the XML Response Page screen: click .
- Click a policy name, and then click .
-
Select a Response Type from the list. Your selection
determines the additional settings.
Option Description Custom Response The screen displays the default response header and response body which you can edit to create a custom response. Alternatively, for the response body, you can upload a response. - Click Choose File to select the file containing the response body, and then click Upload to insert it.
- Click Preview On to preview the response.
- If you want to return to the original default response text for the header or the body, click Paste Default Response Header or Paste Default Response Body.
Soap Fault The system blocks a SOAP request due to an XML-related violation. The system displays the system-supplied response written in the SOAP fault message structure. You cannot edit this text.
Click Preview On to preview the response. - When you are finished, save your changes.
Edit policy building overview settings
Edit policy building suggestion settings
Edit policy building settings
- Go to the Blocking Settings screen: click .
- Click the name of a policy, and from the list on the left select .
- Click the arrows to open or close each category and display specific violation types available to configure for that category.
- Edit the settings to meet your requirements.
- When you are finished, save your work.
Policy building settings properties
You configure the settings of the security policy to specify how the system responds to a request that contains each type of illegal request.
Blocking Setting | Description |
---|---|
Enforcement Mode | Specify whether blocking is active or inactive for the security policy.
|
Learning Mode | Specify how learning is, or is not, performed.
|
Policy Building Mode | Specify how policy building is performed. The option you select changes the other
settings that are available.
|
Policy Building Device | Specify which central policy building device to use. This option is available
only when central policy building mode is selected. The policy building device is also
a data collection device.
|
Auto-Apply Policy | Specify when learning is automatically applied to the policy.
|
Learning Speed | Select the speed the Policy Builder uses for learning.
|
All Violations | Select the Learn, Alarm or
Block check boxes in this row to have those selections apply
to all the violations in this group. You can select or clear these check boxes in the
violation rows to change the behavior for individual violations, or groups of
violations.
|
Policy General Features | Expand this setting to see the contained violations. Click the information icon
next to each violation for more information about it. Select Learn, Alarm, or Block for each, as appropriate for your policy. |
HTTP protocol compliance failed | Expand this setting to see the sub-violations, and click the information icons
for more information. Either select the Enable or Learn check box at the top of the section to select all HTTP protocol compliance failed sub-violations at once, or select the Enable or Learn check box to the left of each sub-violation to specify that the system enforces the sub-violation. When the check box is cleared, the system does not enforce this sub-violation. This category contains the following sub-violations.
|
Attack Signatures | The system examines HTTP messages for known attacks by comparing them against known attack patterns. Click the Edit Settings link to edit the properties of that signature set. |
Evasion technique detected | Expand this setting to see the evasion technique sub-violations and click
information icons for more information. Either select the Enable or Learn check box at the top of the section to select all sub-violations at once, or select the Enable or Learn check box to the left of each sub-violation to specify that the system enforces the sub-violation. When the check box is cleared, the system does not enforce this sub-violation. This category contains the following sub-violations.
|
File Types | Expand this setting to see the file type sub-violations, and click information
icons for more information. When enabled, the system checks that the requested file
type is configured as a valid file type or not configured as an invalid file type.
This category contains the following sub-violations.
In the Learn New File Types setting, select under which circumstances the Policy Builder adds, or suggests you add, explicit file types to the security policy. As you select the setting, additional information about the setting is displayed below it. In the Maximum Learned File Types setting, type the maximum number. The default value changes based on the value of the Learn New File Types setting. |
URLs | Expand this area to see the URL sub-violations and click the information icons
for more information on each.
|
Parameters | Expand this area to see the parameter sub-violations and click the information
icons for more information on each.
|
Sessions and Logins | Expand this area to see the session and login sub-violations, and click the
information icons for more information on each violation. In the Detect login pages setting, select the Enabled check box to have the Policy Builder detect login pages by examining traffic to the web application. |
Cookies | Expand this area to see the cookie sub-violations and click the information icons
for more information on each violation.
|
Content Profiles | Expand this area to see the content profile sub-violations, and click the
information icons for more information on each violation. In the Collapse many common Content Profiles into one wildcard Content profile setting, you specify, when the Enabled check box is selected, that the system collapses many common content profiles into one wildcard content profile. Type in the field how many explicit content profiles the Policy Builder must detect (the number of occurrences) before collapsing them to one wildcard content profile. |
Web Services Security Failure | Expand this area to see the web services security failure sub-violations. At the top of the list of sub-violations, select either the Enable or Learn check box to select all sub-violations at once, or select the Enable or Learn check box to the left of each sub-violation to specify that individual sub-violation.
|
CSRF Protection | Expand this area to see the cross-site request forgery (CSRF) protection
sub-violations. Cross-site request forgery (CSRF) is an attack that
forces a user to execute unwanted actions on a web application in which the user is
currently authenticated. When this setting is enabled, the system protects the web
application against CSRF attacks. This category contains the following violations.
|
IP Addresses / Geolocations | Expand this area to see the IP address and Geolocation sub-violations, and click the information icons for more information on each violation. |
Headers | Expand this area to see the header sub-violations and click the information icons
for more information on each violation. In the Learn Host Names setting, Select the Enabled check box to specify that the Policy Builder suggests you add host names that have not yet been added to the policy. |
Redirection Protection | Expand this area to see the redirection protection sub-violations, and click the
information icons for more information on each violation. In the Learn New Redirection Domains setting, select under which circumstances the Policy Builder adds, or suggests you add, explicit redirection domains to the policy. As you select the setting, additional information about the setting is displayed below it. In the Maximum Learned Redirection Domains setting, type the largest number of redirection domains that the policy allows. |
Bot Detection | Expand this area to see the WebSocket sub-violations. The Bot Detection category contains the Web scraping detected violation, which detects when the web client, or user agent, does not demonstrate human behavior. |
Data Guard | Expand this area to see the Data Guard sub-violations. The Data Guard category specifies which information the system considers sensitive, including credit card numbers, U.S. Social Security numbers, custom patterns, and file content. This category contains the Data Guard. Information leakage detected violation. |
WebSocket protocol compliance | Expand this area to see the WebSocket protocol compliance sub-violations, and click the information icons for additional information about each violation. |
Antivirus Protection | Expand this area to see the antivirus protection sub-violations, and click the information icons for additional information about each violation. |
Edit policy building process settings
Edit server technologies settings
Edit Data Guard settings
Edit CSRF protection settings
Add or edit brute force attack prevention settings
Add methods
Add or edit HTTP header settings
Edit host name settings
Add or edit cookie settings
Edit redirection protection settings
Edit header character set settings
Edit IP addresses list settings
Edit IP address intelligence settings
Add or edit HTTP URL settings
Add or edit WebSocket URL settings
Edit URL character set settings
Add or edit file types settings
Edit or add JSON content profile settings
Edit or add XML content profile settings
- Navigate to the XML Profiles screen: click .
- Click the name of the policy you want to work with, then, on the left, expand CONTENT PROFILES, and click XML Profiles.
- Click the name of the XML profile to modify, or click Add to create a new one.
- Review the existing name or type a Profile Name for the new profile.
- Review, revise, or type an optional Description for the profile.
-
For the Use XML Blocking Response Page property, select
the type of response page to send when the security policy blocks a client
request that contains URL XML content that does not comply with the settings of
this XML profile.
- To have the system send an XML response page, select the Enabled check box.
- To have the system send the default response page, do not select the Enabled check box.
- To configure the validation and defense settings of an XML profile, expand the XML Firewall Configuration area and modify those settings as needed.
- To configure the system to perform attack signature checks on the XML profile, expand the Attack Signatures area and modify those settings as needed.
- To change the security policy settings for specific meta characters in XML values on the XML profile, expand the Meta Characters area and modify those settings as needed.
- Expand the Sensitive Data Configuration area to program the system to mask sensitive data that appears in an XML document, as shown in the BIG-IP device configuration interface and internal Application Security logs.
- Click Save to save your changes.
Edit or add plain text content profile settings
Edit character set JSON settings
Edit character set plain text settings
Edit character set XML settings
Add or edit parameter settings
Add or edit extraction settings
Edit character set parameter name settings
Edit character set parameter value settings
Add sensitive parameters settings
Configure attack signatures
- Go to the Policies screen: Click .
- Continue to the Attack Signatures Configuration screen: Click the name of a policy, and on the left click Attack Signatures Configuration .
-
Revise the settings as needed.
- To enable staging of signatures, select the Signature Staging Enabled check box.
- To place updated signatures in staging, select the Place updated signatures in staging Enabled check box. New signatures are always placed in staging, regardless of this setting.
- For Attack
Signature Set Assignment, select one or more signature sets
from the list to be assigned to the policy, and then select the appropriate
options for that signature set.
- Select or clear the
Learn, Alarm, and
Block options for each signature set.
- Select Learn to have the security policy learn all requests that match enabled signatures in the signature set.
- Select Alarm to have the security policy logs the request data if a request matches a signature in the signature set.
- Select Block, to have the security policy block all requests that match a signature included in the signature set.
- From the Actions list, select, if needed, whether to enable or enforce signatures in the signature set.
- Select or clear the
Learn, Alarm, and
Block options for each signature set.
- For Apply Response Signatures, select a file type, if needed. The default wildcard character indicates all file types.
- When you are finished, save your work.
View and modify attack signatures
Edit geolocation enforcement settings
Add or edit login page settings
Add or edit logout page settings
Add or edit login enforcement settings
- Click .
- Click the name of the appropriate policy, and on the left click .
-
For the Expiration Time setting, specify whether you
want the login session to expire.
- If you do not want the login session to expire, click Disabled.
- If you want the login URL to be valid for a limited time, click the button to the left of the Seconds field, and type a value, in seconds (1-99999), that indicates how long the session will last. The login session ends after the number of seconds has passed.
-
For the Authenticated URLs setting, specify the target
URLs that users can access only by using the login URL.
- Save your work.
Edit session tracking settings
Adding security policies
Import application security policies
If you replaced an existing policy, the imported security policy completely overwrites the existing security policy. Also, the imported policy is then associated with the virtual server and local traffic policy that was previously associated with the policy you replaced. The replaced policy is automatically archived with the inactive security policies.