F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Preventing Session Hijacking and Tracking User Sessions
Manual Chapter : Preventing Session Hijacking and Tracking User Sessions

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Preventing Session Hijacking and Tracking User Sessions

Overview: Preventing session hijacking

Session hijacking, also called cookie hijacking, is the exploitation of a valid computer session to gain unauthorized access to an application. The attacker steals (or hijacks) the cookies from a valid user and attempts to use them for authentication. Application Security Manager™ (ASM™) can prevent session hijacking by tracking clients with a device ID. The device ID is a unique identifier that ASM creates by sending JavaScript to get information about the client device. If the client browser does not accept JavaScript, the client receives a message saying to enable JavaScript to view the page content. Clients that do not accept JavaScript are stopped even when the security policy is in transparent mode.

ASM stores the device ID along with other client data (including the message key or session ID) in a cookie that remains with the client for the length of the HTTP session. The system periodically checks that the device ID of the client is the same one that was assigned when the session started.

If the device ID or message key changes during the session or the session timed out, the system considers that to be an attack and issues an ASM cookie hijacking violation. It looks like an attacker has stolen cookies from a legitimate user and is trying to gain illegal access. Note that the ASM cookie hijacking violation only occurs if you enabled the Learn, Alarm, or Block settings for the violation.

You set up session hijacking along with session tracking. However, you do not have to track user sessions to set up hijacking prevention.

Task Summary

Preventing session hijacking

You can use Application Security Manager™ to prevent session hijacking by tracking the device ID and session ID of each user.

Note: To use device ID for tracking, client browsers accessing your web site must be able to accept JavaScript, or they will be blocked even when working in transparent mode.
  1. On the Main tab, click Security > Application Security > Sessions and Logins > Session Tracking .
    The Session Tracking screen opens.
  2. In the Session Hijacking area, for Detect Session Hijacking by Device ID Tracking, select the Enabled check box.
    Note: When you are using device ID to track traffic, make sure that the Accept XFF setting is enabled in the HTTP profile that is assigned to the virtual server.
  3. Click Save to save your settings.
  4. To set the blocking modes for the hijacking violation, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    1. In the General Settings, set the Enforcement Mode to Blocking.
      This setting blocks all requests that cause violations, and which are set to block.
    2. In the Policy Building Settings, expand Cookies, and for the ASM Cookie Hijacking violation, select Learn, Alarm, and Block.
    3. Click Save.
  5. To put the security policy changes into effect immediately, click Apply Policy.
Any client that does not accept JavaScript is now prevented from reaching the web site. If the system detects session hijacking, it issues the ASM Cookie Hijacking violation. The event log includes a description of why it happened:
  • Message key mismatch between cookies
  • Device ID mismatch
  • Device ID mismatch and message key mismatch between cookies

Because the security policy enforcement mode is set to blocking, the request is blocked and the client receives the cookie hijacking response page. By default, ASM erases the cookies for the session, and redirects the client to the login page. If the client is legitimate, the login should be successful. Attackers that had attempted to hijack the session are blocked.

Configuring the response to cookie hijacking

You can configure the blocking response that the system sends in response to a session (or cookie) hijacking attempt.
  1. On the Main tab, click Security > Application Security > Policy > Response Pages .
    The Response Pages 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. Click Cookie Hijacking Response Page.
  4. For the Response Type setting, select Erase Cookies.
    You can use other options such as the Default Response page, Custom Response page, or SOAP Fault. But Erase Cookies is the recommended and default response to cookie hijacking.

    The system deletes client side domain cookies to block the application user.

  5. Click Save to save your settings.
  6. To put the security policy changes into effect immediately, click Apply Policy.
If the enforcement mode is blocking and a session hijacking attempt is blocked, the system erases the browser cookies, and displays the cookie hijacking response page.

Overview: Tracking user sessions using login pages

You can track user sessions using login pages configured from within Application Security Manager™ (ASM™), or have the policy retrieve the user names from Access Policy Manager®(APM®). This implementation describes how to set up session tracking for a security policy using login pages. The advantage of using session tracking is that you are able to identify the user, session, device ID, or IP address an attack.

Login pages, created manually or automatically, define the URLs, parameters, and validation criteria required for users to log in to the application. User and session information is included in the system logs so you can track a particular session or user. The system can log activity, or block a user or session if either generates too many violations.

If you configure session awareness, you can view the user and session information in the application security charts.

Task Summary

Creating login pages automatically

Login pages specify a login URL that presents a site that users must pass through to gain access to the web application. Your existing security policy can detect and create login pages automatically if you use certain options.
Note: If you are creating a security policy automatically, and selected Enhanced or Comprehensive as the policy type, the default options are already set to create login pages automatically. If you are using the Fundamental or Custom policy types, the steps here explain the options to configure ASM™ to automatically detect and create login pages for your application.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. Ensure that the Learning Mode is set to Automatic.
    The system examines the traffic to the web application, and after processing sufficient legitimate traffic, the system builds the security policy automatically by adding and enforcing elements with minimal manual intervention. A few learning suggestions require your review before they are added.
  3. In the Policy Building Settings area, expand Sessions and Logins and ensure that Detect login pages is selected.
    This setting must be selected if you want to automatically detect login pages.
  4. In the Policy Building Process area, expand Options and ensure that Learn from responses is selected.
  5. Click Save to save your settings.
  6. In the editing context area, click Apply Policy to put the changes into effect.
The security policy looks for login pages by examining traffic to the web application. When a login page is found, the Policy Builder suggests adding the login form to the security policy. Because the suggestion is learned from responses and responses are considered trusted, if the Learning Mode is Automatic, the login page is typically added to the policy right away.

If the Learning Mode is Manual, the login page is added to the learning suggestions on the Traffic Learning screen where you can add it to the policy. The login pages in the security policy are included in the Login Pages List.

You can use the login pages for login enforcement, brute force protection, or session awareness.

Creating login pages manually

Before you can create a login page manually, you need to be familiar with the login URL or URLs the application the security policy is protecting.
In your security policy, you can create a login page manually to specify a login URL that presents a site that users must pass through to gain access to the web application. The login URL commonly leads to the login page of the web application.
Note: You can also have the system create login pages automatically by selecting Detect login pages on the Learning and Blocking Settings screen.
  1. On the Main tab, click Security > Application Security > Sessions and Logins .
    The Login Pages List 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. Click Create.
    The New Login Page screen opens.
  4. For the Login URL setting, specify a URL that users must pass through to get to the application.
    1. From the list, select the type of URL: Explicit or Wildcard.
    2. Select either HTTP or HTTPS based on the type of traffic the web application accepts.
    3. Type an explicit URL or wildcard expression in the field.
      When you click in the field, the system lists URLs that it has seen, and you can select a URL from the list. Or, you can type explicit URLs in the format /login, and wildcard URLs without the slash, such as *.php.
      Wildcard syntax is based on shell-style wildcard characters. This table lists the wildcard characters that you can use so that the entity name can match multiple objects.
      Wildcard Character Matches
      * All characters
      ? Any single character.
      [abcde] Exactly one of the characters listed.
      [!abcde] Any character not listed.
      [a-e] Exactly one character in the range.
      [!a-e} Any character not in the range.
      Note that wildcards do not match regular expressions.
  5. From the Authentication Type list, select the method the web server uses to authenticate the login URL's credentials with a web user.
    Option Description
    None The web server does not authenticate users trying to access the web application through the login URL. This is the default setting.
    HTML Form The web application uses a form to collect and authenticate user credentials. If using this option, you also need to type the user name and password parameters written in the code of the HTML form.
    HTTP Basic Authentication The user name and password are transmitted in Base64 and stored on the server in plain text.
    HTTP Digest Authentication The web server performs the authentication; user names and passwords are not transmitted over the network, nor are they stored in plain text.
    NTLM Microsoft LAN Manager authentication (also called Integrated Windows Authentication) does not transmit credentials in plain text, but requires a continuous TCP connection between the server and client.
    JSON/AJAX Request The web server uses JSON and AJAX requests to authenticate users trying to access the web application through the login URL. For this option, you also need to type the name of the JSON element containing the user name and password.
  6. In the Access Validation area, define at least one validation criteria for the login page response.
    If you define more than one validation criteria, the response must meet all the criteria before the system allows the user to access the application login URL.
    Note: The system checks the access validation criteria on the response of the login URL only if the response has one of the following content-types: text/html, text/xml, application/sgml, application/xml, application/html, application/xhtml, application/x-asp, or application/x-aspx.
  7. Click Create to add the login page to the security policy.
    The new login page is added to the login pages list.
  8. Add as many login pages as needed for your web application.
  9. In the editing context area, click Apply Policy to put the changes into effect.
The security policy now has one or more login pages associated with it. They are included in the Login Pages List.
You can use the login pages you created for login enforcement, brute force protection, or session awareness.

Setting up session tracking

You can use session tracking to track, enforce, and report on user sessions, device IDs, and IP addresses. To perform tracking, you enable session awareness and indicate how to associate the application user name with the session. You can also determine whether to track violations and perform logging or blocking actions based on the number of violations per user, session, and IP address.
  1. On the Main tab, click Security > Application Security > Sessions and Logins > Session Tracking .
    The Session Tracking screen opens.
  2. In the Session Tracking Configuration area, select the Session Awareness check box.
  3. From the Application Username list, select Use All Login Pages to track login sessions for all of the login pages in the security policy.
  4. In the Violation Detection Actions area, select the Track Violations and Perform Actions check box.
  5. In the Violation Detection Period field, type the number of seconds that indicates the sliding time period to count violations for violation thresholds.
    The default is 900 seconds.
  6. If you want the system to block all activity for a user, session, device ID, or IP address when the number of violations exceeds the threshold within the violation detection period, specify one or more of the following settings on the Block All tab.
    Option Description
    Blocked URLs Specify which URLs to block after the number of violations exceeds the enabled thresholds. To block all URLs, select Block all URLs. To block authenticated URLs protected by login pages, select Block Authenticated URLs.
    Username Threshold Select Enable and specify the number of violations allowed before the system starts to block this user's activity.
    Session Threshold Select Enable and specify the number of violations allowed before the system starts to block activity for this HTTP session.
    Device ID Threshold Select Enable and specify the number of violations allowed per device ID before the system starts to block activity for this device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system starts to block the activity for this IP address.
    Block All Period Specify how long to block users, sessions, or IP addresses if the number of violations exceeds the threshold. To block the user, session, or IP address indefinitely, click Infinite. Otherwise, click User-defined and type the number of seconds to block the traffic. The default is 600 seconds.
    Note: For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
  7. If you want the system to log activity when the number of violations for user, session, device ID, or IP address, exceeds the threshold during the violation detection period, specify one or more of the following settings on the Log All Requests tab.
    Option Description
    Username Threshold Select Enable and specify the number of violations allowed before the system starts logging this user's activity for the log all requests period.
    Session Threshold Select Enable and specify the number of violations allowed before the system starts logging activity for this HTTP session for the log all requests period.
    Device ID Threshold Select Enable and specify the number of violations allowed before the system starts to log requests for this device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system starts logging the activity of this IP address for the log all requests period.
    Log All Requests Period Specify how long the system should log all requests when any of the enabled thresholds is reached. Type the number of seconds in the field.
  8. If you want more tolerant blocking for selected violations, such as those prone to false positives, specify one or more of the following settings on the Delay Blocking tab.
    Option Description
    Username Threshold Select Enable and specify the number of violations a user must cause before the system begins blocking this user for the delay blocking period.
    Session Threshold Select Enable and specify the number of violations users must cause (during the violation detection period) before the system begins blocking this HTTP session for the delay blocking period.
    Device ID Threshold Select Enable and specify the number of violations allowed per device ID before the system starts to block illegal requests from the device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system begins blocking this IP address for the delay blocking period.
    Delay Blocking Period Type the number of seconds that the system should block the user, session, or IP address when any of the enabled thresholds is reached.
    Associated Violations Move the violations for which you want delay blocking from the Available list into the Selected list. If the selected violations occur, the system does not block traffic until one of the enabled thresholds is reached. At that point, the system blocks traffic causing those violations for the user, session, or IP address, but allows other transactions to pass.
    Note: For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
  9. Click Save to save your settings.
After you set up session tracking, if any enabled threshold exceeds the number of violations during the detection period, the system starts the configured actions (block all, log all requests, or delay blocking).

Monitoring user and session information

To monitor user and session information, you first need to set up session tracking for the security policy.
You can use the reporting tools in Application Security Manager™ to monitor user and session details, especially when you need to investigate suspicious activity that is occurring with certain users, sessions, or IP addresses.
  1. On the Main tab, click Security Reporting Application Session Tracking Status.
    The Session Tracking Status screen opens and shows the users, sessions, and IP addresses that the system is currently tracking for this security policy.
  2. From the Action list, select the action by which to filter the data.
    Action Description
    All Specifies that the screen displays all entries. This is the default value.
    Block All Specifies that the system displays sessions whose requests the system blocks after the configured threshold was reached.
    Log All Requests Specifies that the system displays sessions whose requests the system logs after the configured threshold was reached.
    Delay Blocking Specifies that the system displays sessions whose requests the system delayed blocking until the configured threshold was reached.
  3. From the Scope list, specify the scope (username, session, or IP address) by which to filter the data.
    Option Description
    Alt Specifies that the screen displays all entries. This is the default value.
    Username Specifies that the system displays usernames whose illegal requests exceeded the security policy’s threshold values.
    Session Specifies that the system displays identification numbers of illegal sessions that exceeded the security policy’s threshold values.
    IP Address Specifies that the system displays IP addresses where illegal requests from these IP addresses exceeded the security policy’s threshold values.
    Device ID Specifies that the system displays device IDs where illegal requests from these devices exceeded the security policy’s threshold values.
  4. If you want to filter the information by value, in the Value field, type the username, session identification number, IP address, device ID, or string. If empty, the screen displays all entries.
  5. When you finish specifying the filter details, click Go.
    The Session Tracking Status list now shows the information specified in the Filter setting.
After you set up session tracking, you can monitor the specific requests that cause violations by examining each request and reviewing graphical charts.

Tracking specific user and session information

To monitor user and session information, you first need to set up session tracking for the security policy.
You can configure Application Security Manager™ to log, block, or delay blocking requests from a specific username, session, or source IP address.
  1. On the Main tab, click Security > Reporting > Application > Session Tracking Status .
    The Session Tracking Status screen opens and shows the users, sessions, and IP addresses that the system is currently tracking for this security policy.
  2. Next to the Session Tracking Status list, click Add.
    The Add Session to Tracking screen opens.
  3. From the Action list, select the action that the system will take if it detects the specified username, session, or IP address.
    Action Description
    Block All Specifies that the system blocks all requests from a specific username, session ID, IP address, or device ID for the configured period of time.
    Log All Requests Specifies that the system blocks all requests from a specific username, session ID, IP address, or device ID for the configured period of time.
    Delay Blocking Specifies that the system will delay blocking the associated violations from a specific username, session ID, IP address, or device ID until the threshold is reached; then they will be blocked for the configured period of time.
  4. From the Scope list, specify whether the system is tracking a specific Username (the default value), Session, IP Address, or device ID.
  5. In the Value field, type the unique username, session identification number, or IP address that you want to track, based on what you selected in the Scope option.
  6. Click Add.
    The system adds the entry to the Session Tracking list and immediately begins to enforce it.
If the system detects the specific username, session, or IP address, it takes that action you configured for it.

Overview: Tracking application security sessions using APM

You can track sessions using login pages configured from within Application Security Manager™ (ASM™), or have the policy retrieve the user names from Access Policy Manager® (APM®). This implementation describes how to set up session tracking for a security policy using APM to verify user credentials. Then, you can set up session awareness from within ASM to identify the user, session, or IP address that instigated an attack.

If you configure session tracking, you can view the user and session information in the application security charts.

Prerequisites for setting up session tracking with APM

In order to set up session tracking from within Application Security Manager™ (ASM™) so that the security policy retrieves the user names from Access Policy Manager ® (APM®), you need to perform basic these system configuration tasks according to the needs of your networking configuration:

  • Run the setup utility and create a management IP address.
  • License and provision ASM, APM, and Local Traffic Manager™ (LTM®).
  • Configure a DNS address ( System > Configuration > Device > DNS ).
  • Configure an NTP server ( System > Configuration > Device > NTP ).
  • Restart ASM (at the command line, type tmsh restart /sys service asm).

Task summary

Use the following tasks to set up application security session tracking with APM authentication integrated.

Creating a VLAN

VLANs represent a logical collection of hosts that can share network resources, regardless of their physical location on the network. You create a VLAN to associate physical interfaces with that VLAN.
  1. On the Main tab, click Network > VLANs .
    The VLAN List screen opens.
  2. Click Create.
    The New VLAN screen opens.
  3. In the Name field, type a unique name for the VLAN.
  4. In the Tag field, type a numeric tag, between 1-4094, for the VLAN, or leave the field blank if you want the BIG-IP system to automatically assign a VLAN tag.
    The VLAN tag identifies the traffic from hosts in the associated VLAN.
  5. If you want to use Q-in-Q (double) tagging, use the Customer Tag setting to perform the following two steps. If you do not see the Customer Tag setting, your hardware platform does not support Q-in-Q tagging and you can skip this step.
    1. From the Customer Tag list, select Specify.
    2. Type a numeric tag, from 1-4094, for the VLAN.
    The customer tag specifies the inner tag of any frame passing through the VLAN.
  6. For the Interfaces setting,
    1. From the Interface list, select an interface number.
    2. From the Tagging list, select Untagged.
    3. Click Add.
  7. Click Finished.
    The screen refreshes, and displays the new VLAN in the list.

Creating a self IP address for a VLAN

Ensure that you have at least one VLAN configured before you create a self IP address.
Self IP addresses enable the BIG-IP® system, and other devices on the network, to route application traffic through the associated VLAN.
  1. On the Main tab, click Network > Self IPs .
  2. Click Create.
    The New Self IP screen opens.
  3. In the Name field, type a unique name for the self IP address.
  4. In the IP Address field, type an IPv4 or IPv6 address.
    This IP address should represent the address space of the VLAN that you specify with the VLAN/Tunnel setting.
  5. In the Netmask field, type the network mask for the specified IP address.

    For example, you can type 255.255.255.0.

  6. From the VLAN/Tunnel list, select the VLAN to associate with this self IP address.
    • On the internal network, select the internal or high availability VLAN that is associated with an internal interface or trunk.
    • On the external network, select the external VLAN that is associated with an external interface or trunk.
  7. Use the default values for all remaining settings.
  8. Click Finished.
    The screen refreshes, and displays the new self IP address.
The BIG-IP system can now send and receive TCP/IP traffic through the specified VLAN.

Creating a local traffic pool for application security

You can use a local traffic pool with Application Security Manager™ system to forward traffic to the appropriate resources.
Note: You can optionally create a pool as part of creating a security policy using the Deployment wizard.
  1. On the Main tab, click Local Traffic > Pools .
    The Pool List screen opens.
  2. Click Create.
    The New Pool screen opens.
  3. In the Name field, type a unique name for the pool.
  4. In the Resources area, for the New Members setting, add to the pool the application servers that host the web application:
    1. Type an IP address in the Address field.
    2. In the Service Port field, type a port number (for example, type 80 for the HTTP service), or select a service name from the list.
    3. Click Add.
  5. Click Finished.
The BIG-IP® system configuration now includes a local traffic pool containing the resources that you want to protect using Application Security Manager™.

Creating a virtual server to manage HTTPS traffic

You can create a virtual server to manage HTTPS traffic.
  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the Create button.
    The New Virtual Server screen opens.
  3. In the Name field, type a unique name for the virtual server.
  4. In the Destination Address/Mask field, type the IP address in CIDR format.
    The supported format is address/prefix, where the prefix length is in bits. For example, an IPv4 address/prefix is 10.0.0.1 or 10.0.0.0/24, and an IPv6 address/prefix is ffe1::0020/64 or 2001:ed8:77b5:2:10:10:100:42/64. When you use an IPv4 address without specifying a prefix, the BIG-IP® system automatically uses a /32 prefix.
    Note: The IP address you type must be available and not in the loopback network.
  5. In the Service Port field, type 443 or select HTTPS from the list.
  6. From the Configuration list, select Advanced.
  7. From the HTTP Profile list, select http.
  8. From the HTTP Compression Profile list, select one of the following profiles:
    • httpcompression
    • wan-optimized-compression
    • A customized profile
  9. Optional: From the Web Acceleration Profile list, select one of the following profiles:
    • optimized-acceleration
    • optimized-caching
    • webacceleration
    • A customized profile
  10. From the Web Acceleration Profile list, select one of the following profiles with an enabled application:
    • optimized-acceleration
    • optimized-caching
    • webacceleration
    • A customized profile
  11. For the SSL Profile (Client) setting, from the Available list, select clientssl, and using the Move button, move the name to the Selected list.
  12. Optional: From the SSL Profile (Server) list, select serverssl.
    Note: This setting ensures that there is an SSL connection between the HTTP virtual server and the external HTTPS server.
  13. From the Source Address Translation list, select Auto Map.
  14. From the Default Pool list, select the pool that is configured for application security.
  15. Click Finished.
The HTTPS virtual server appears in the Virtual Server List screen.

Creating a security policy automatically

Before you can create a security policy, you must perform the minimal system configuration tasks including defining a VLAN, a self IP address, and other tasks required according to the needs of your networking environment.
Application Security Manager™ can automatically create a security policy that is tailored to secure your web application.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the Create button.
    The Deployment wizard opens to the Select Local Traffic Deployment Scenario screen.
  3. For the Local Traffic Deployment Scenario setting, specify a virtual server to use for the security policy.
    • To secure an existing virtual server that has no security policy associated with it, select Existing Virtual Server and click Next.
    • To create a new virtual server and pool with basic configuration settings, select New Virtual Server and click Next.
    • To create an active but unused security policy, select Do not associate with Virtual Server and click Next. No traffic will go through this security policy until you associate it with a virtual server. The Policy Builder cannot begin automatically creating a policy until traffic is going to ASM through the virtual server.
    The virtual server represents the web application you want to protect.
    The Configure Local Traffic Settings screen opens if you are adding a virtual server. Otherwise, the Select Deployment Scenario screen opens.
  4. If you are adding a virtual server, configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, virtual server name, virtual server destination address and port, pool member IP address and port, and the logging profile.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy. Specify the protocol and virtual server.
    • If you selected Do not associate with Virtual Server, you will have to manually associate the security policy with a virtual server at a later time. On the policy properties screen, you need to specify a name for the security policy.
    The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a security policy automatically and click Next.
    The Configure Security Policy Properties screen opens.
  6. In the Security Policy Name field, type a name for the policy.
  7. From the Application Language list, select the language encoding of the application, or use Auto detect and let the system detect the language.
    Important: You cannot change this setting after you have created the security policy.
  8. If the application is not case-sensitive, clear the Security Policy is case sensitive check box. Otherwise, leave it selected.
    Important: You cannot change this setting after you have created the security policy.
  9. If you do not want the security policy to distinguish between HTTP/WebSocket and HTTPS/WebSocket Secure URLs, clear the Differentiate between HTTP/WS and HTTPS/WSS URLs check box. Otherwise, leave it selected.
  10. Click Next.
    The Configure Attack Signatures screen opens.
  11. To configure attack signatures, move the systems used by your web application from the Available Systems list into the Assigned Systems list.
    The system adds the attack signatures needed to protect the selected systems.
  12. For the Signature Staging setting, verify that the default option Enabled is selected.
    Note: Because ASM begins building the security policy in Blocking mode, you can keep signature staging enabled so you can check whether legitimate traffic is being stopped to reduce the chance of false positives.
    New and updated attack signatures remain in staging for 7 days, and are recorded but not enforced (according to the learn, alarm, and block flags in the attack signatures configuration) during that time.
  13. Click Next.
    The Configure Automatic Policy Building screen opens.
  14. For Policy Type, select an option to determine the security features to include in the policy.
    Bulleted lists on the screen describe the exact security features that are included in each type.
    Option Description
    Fundamental Creates a robust security policy that is appropriate for most applications.
    Enhanced Creates a more specific security policy with additional customization such as learning URLs, cookies, and content profiles; includes tracking of user login sessions and brute force protection.
    Comprehensive

    Creates the most secure policy providing the greatest amount of customization, including all the Enhanced features and more traffic classification at the parameter and URL levels, dynamic parameters, and CSRF URLs.
  15. For the Policy Builder Learning Speed setting, select how fast to generate suggestions for the policy.
    Option Description
    Fast Use if your application supports a small number of requests from a small number of sessions; for example, useful for web sites with less traffic. Policy Builder requires fewer unique traffic samples to make decisions in Automatic Learning Mode, or to reach a high learning score. However, choosing this option may present a greater chance of adding false entities to the security policy.
    Medium Use if your application supports a medium number of requests, or if you are not sure about the amount of traffic on the application web site. This is the default setting.
    Slow Use if your application supports a large number of requests from many sessions; for example, useful for web sites with lots of traffic. Policy Builder requires a large amount of unique traffic samples to make decisions in Automatic Learning Mode, or to reach a high learning score. This option creates the most accurate security policy, but it takes Policy Builder longer to collect the statistics.
    Based on the option you select, the system sets greater or lesser values for the number of different user sessions, different IP addresses, and length of time before it adds suggestions to the security policy and if you are using automatic learning, enforces the elements.
  16. For Trusted IP Addresses, select which IP addresses to consider safe:
    Option Description
    All Specifies that the policy trusts all IP addresses. This option is recommended for traffic in a corporate lab or preproduction environment where all of the traffic is trusted. The policy is created faster when you select this option.
    Address List Specifies networks to consider safe. Fill in the IP Address and Netmask fields, then click Add. This option is typically used in a production environment where traffic could come from untrusted sources. The IP Address can be either an IPv4 or an IPv6 address.
    If you leave the trusted IP address list empty, the system treats all traffic as untrusted. In general, it takes more untrusted traffic, from different IP addresses, over a longer period of time to build a security policy.
  17. If you want to display a response page when an AJAX request does not adhere to the security policy, select the AJAX blocking response behavior check box.
  18. Click Next.
    The Security Policy Configuration Summary opens where you can review the settings to be sure they are correct.
  19. Click Finish to create the security policy.
    The Policy Properties screen opens.
ASM™ creates the virtual server with an HTTP profile (or associates an existing one), and on the Security tab, Application Security Policy is enabled and associated with the security policy you created. A local traffic policy is also created and by default sends all traffic for the virtual server to ASM. The Policy Builder automatically begins examining the traffic to the web application and making suggestions for building the security policy (unless you did not associate a virtual server). The system sets the enforcement mode of the security policy to Blocking, but it does not block requests until the Policy Builder processes sufficient traffic, adds elements to the security policy, and enforces the elements.
Tip: This is a good point at which to test that you can access the application being protected by the security policy and check that traffic is being processed correctly by the BIG-IP® system.

Creating an access profile

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  1. On the Main tab, click Access Policy > Access Profiles .
    The Access Profiles List screen opens.
  2. Click Create.
    The New Profile screen opens.
  3. In the Name field, type a name for the access profile.
    Note: An access profile name must be unique among all access profile and any per-request policy names.
  4. From the Profile Type list, select SSL-VPN.
    Additional settings display.
  5. From the Profile Scope list, retain the default value or select another.
    • Profile: Gives a user access only to resources that are behind the same access profile. This is the default value.
    • Virtual Server: Gives a user access only to resources that are behind the same virtual server.
    • Global: Gives a user access to resources behind any access profile that has global scope.
  6. To configure timeout and session settings, select the Custom check box.
  7. In the Inactivity Timeout field, type the number of seconds that should pass before the access policy times out. Type 0 to set no timeout.
    If there is no activity (defined by the Session Update Threshold and Session Update Window settings in the Network Access configuration) between the client and server within the specified threshold time, the system closes the current session.
  8. In the Access Policy Timeout field, type the number of seconds that should pass before the access profile times out because of inactivity.
    Type 0 to set no timeout.
  9. In the Maximum Session Timeout field, type the maximum number of seconds the session can exist.
    Type 0 to set no timeout.
  10. In the Max Concurrent Users field, type the maximum number of users that can use this access profile at the same time.
    Type 0 to set no maximum.
  11. In the Max Sessions Per User field, type the maximum number of concurrent sessions that one user can start.
    Type 0 to set no maximum.
  12. In the Max In Progress Sessions Per Client IP field, type the maximum number of concurrent sessions that one client IP address can support.
    Type 0 to set no maximum.
  13. Select the Restrict to Single Client IP check box to restrict the current session to a single IP address.
    This setting associates the session ID with the IP address.
    Upon a request to the session, if the IP address has changed the request is redirected to a logout page, the session ID is deleted, and a log entry is written to indicate that a session hijacking attempt was detected. If such a redirect is not possible, the request is denied and the same events occur.
  14. To configure logout URIs, in the Configurations area, type each logout URI in the URI field, and then click Add.
  15. In the Logout URI Timeout field, type the delay in seconds before logout occurs for the customized logout URIs defined in the Logout URI Include list.
  16. To configure SSO:
    • For users to log in to multiple domains using one SSO configuration, skip the settings in the SSO Across Authentication Domains (Single Domain mode) area. You can configure SSO for multiple domains only after you finish the initial access profile configuration.
    • For users to log in to a single domain using an SSO configuration, configure settings in the SSO Across Authentication Domains (Single Domain mode) area, or you can configure SSO settings after you finish the initial access profile configuration.
  17. In the Domain Cookie field, specify a domain cookie, if the application access control connection uses a cookie.
  18. In the Cookie Options setting, specify whether to use a secure cookie.
    • If the policy requires a secure cookie, select the Secure check box to add the secure keyword to the session cookie.
    • If you are configuring an LTM access scenario that uses an HTTPS virtual server to authenticate the user and then sends the user to an existing HTTP virtual server to use applications, clear this check box.
  19. If the access policy requires a persistent cookie, in the Cookie Options setting, select the Persistent check box.
    This sets cookies if the session does not have a webtop. When the session is first established, session cookies are not marked as persistent; but when the first response is sent to the client after the access policy completes successfully, the cookies are marked persistent. Persistent cookies are updated for the expiration timeout every 60 seconds. The timeout is equal to session inactivity timeout. If the session inactivity timeout is overwritten in the access policy, the overwritten value will be used to set the persistent cookie expiration.
  20. From the SSO Configurations list, select an SSO configuration.
  21. In the Language Settings area, add and remove accepted languages, and set the default language.
    A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  22. Click Finished.
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.
To add an SSO configuration for multiple domains, click SSO / Auth Domains on the menu bar. To provide functionality with an access profile, you must configure the access policy. The default access policy for a profile denies all traffic and contains no actions. Click Edit in the Access Policy column to edit the access policy.

Configuring an access policy

You configure an access policy to provide authentication, endpoint checks, and resources for an access profile. This procedure configures a simple access policy that adds a logon page, gets user credentials, submits them to an authentication type of your choice, then allows authenticated users, and denies others.
  1. On the Main tab, click Access Policy > Access Profiles .
    The Access Profiles List screen opens.
  2. Click the name of the access profile you want to edit.
  3. On the menu bar, click Access Policy.
  4. For the Visual Policy Editor setting, click the Edit access policy for Profile policy_name link.
    The visual policy editor opens the access policy in a separate window or tab.
  5. Click the (+) icon anywhere in the access policy to add a new action item.
    Note: Only an applicable subset of access policy items is available for selection in the visual policy editor for any access profile type.
    A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
  6. On the Logon tab, select Logon Page and click the Add Item button.
    The Logon Page Agent properties screen opens.
  7. Click Save.
    The Access Policy screen reopens.
  8. On the rule branch, click the plus sign (+) between Logon Page and Deny.
  9. Set up the appropriate authentication and client-side checks required for application access at your company, and click Add Item.
  10. Change the Successful rule branch from Deny to Allow and click the Save button.
  11. If needed, configure further actions on the successful and fallback rule branches of this access policy item, and save the changes.
  12. At the top of the screen, click the Apply Access Policy link to apply and activate your changes to this access policy.
  13. Click the Close button to close the visual policy editor.
To apply this access policy to network traffic, add the access profile to a virtual server.
Note: To ensure that logging is configured to meet your requirements, verify the log settings for the access profile.

Adding the access profile to the virtual server

Before you can perform this task, you need to create an access profile using Access Policy Manager®.

You associate the access profile with the virtual server created for the web application that Application Security Manager™ is protecting.

You associate the access profile with the virtual server so that Access Policy Manager®can apply the profile to incoming traffic.

  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the name of the virtual server that manages the network resources for the web application you are securing.
  3. In the Access Policy area, from the Access Profile list, select the access profile that you configured earlier.
  4. Click Update.
Your access policy is now associated with the virtual server.

Setting up ASM session tracking with APM

You can use session tracking to track, enforce, and report on user sessions and IP addresses. To perform tracking, you enable session awareness and indicate how to associate the application user name with the session.
  1. On the Main tab, click Security > Application Security > Sessions and Logins > Session Tracking .
    The Session Tracking screen opens.
  2. In the Session Tracking Configuration area, select the Session Awareness check box.
  3. From the Application Username list, select Use APM Usernames and Session ID.
  4. In the Violation Detection Actions area, select the Track Violations and Perform Actions check box.
  5. In the Violation Detection Period field, type the number of seconds that indicates the sliding time period to count violations for violation thresholds.
    The default is 900 seconds.
  6. If you want the system to block all activity for a user, session, device ID, or IP address when the number of violations exceeds the threshold within the violation detection period, specify one or more of the following settings on the Block All tab.
    Option Description
    Blocked URLs Specify which URLs to block after the number of violations exceeds the enabled thresholds. To block all URLs, select Block all URLs. To block authenticated URLs protected by login pages, select Block Authenticated URLs.
    Username Threshold Select Enable and specify the number of violations allowed before the system starts to block this user's activity.
    Session Threshold Select Enable and specify the number of violations allowed before the system starts to block activity for this HTTP session.
    Device ID Threshold Select Enable and specify the number of violations allowed per device ID before the system starts to block activity for this device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system starts to block the activity for this IP address.
    Block All Period Specify how long to block users, sessions, or IP addresses if the number of violations exceeds the threshold. To block the user, session, or IP address indefinitely, click Infinite. Otherwise, click User-defined and type the number of seconds to block the traffic. The default is 600 seconds.
    Note: For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
  7. If you want the system to log activity when the number of violations for user, session, device ID, or IP address, exceeds the threshold during the violation detection period, specify one or more of the following settings on the Log All Requests tab.
    Option Description
    Username Threshold Select Enable and specify the number of violations allowed before the system starts logging this user's activity for the log all requests period.
    Session Threshold Select Enable and specify the number of violations allowed before the system starts logging activity for this HTTP session for the log all requests period.
    Device ID Threshold Select Enable and specify the number of violations allowed before the system starts to log requests for this device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system starts logging the activity of this IP address for the log all requests period.
    Log All Requests Period Specify how long the system should log all requests when any of the enabled thresholds is reached. Type the number of seconds in the field.
  8. If you want more tolerant blocking for selected violations, such as those prone to false positives, specify one or more of the following settings on the Delay Blocking tab.
    Option Description
    Username Threshold Select Enable and specify the number of violations a user must cause before the system begins blocking this user for the delay blocking period.
    Session Threshold Select Enable and specify the number of violations users must cause (during the violation detection period) before the system begins blocking this HTTP session for the delay blocking period.
    Device ID Threshold Select Enable and specify the number of violations allowed per device ID before the system starts to block illegal requests from the device.
    IP Address Threshold Select Enable and specify the number of violations allowed before the system begins blocking this IP address for the delay blocking period.
    Delay Blocking Period Type the number of seconds that the system should block the user, session, or IP address when any of the enabled thresholds is reached.
    Associated Violations Move the violations for which you want delay blocking from the Available list into the Selected list. If the selected violations occur, the system does not block traffic until one of the enabled thresholds is reached. At that point, the system blocks traffic causing those violations for the user, session, or IP address, but allows other transactions to pass.
    Note: For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
  9. Click Save to save your settings.
After you set up session tracking, if any enabled threshold exceeds the number of violations during the detection period, the system starts the configured actions for block all, log all requests, and delay blocking.
Test that you can log in to the web application through the Access Policy Manager™ logon page. You can also test that the security policy works by generating violations and reviewing the application security logs.

Monitoring user and session information

To monitor user and session information, you first need to set up session tracking for the security policy.
You can use the reporting tools in Application Security Manager™ to monitor user and session details, especially when you need to investigate suspicious activity that is occurring with certain users, sessions, or IP addresses.
  1. On the Main tab, click Security Reporting Application Session Tracking Status.
    The Session Tracking Status screen opens and shows the users, sessions, and IP addresses that the system is currently tracking for this security policy.
  2. From the Action list, select the action by which to filter the data.
    Action Description
    All Specifies that the screen displays all entries. This is the default value.
    Block All Specifies that the system displays sessions whose requests the system blocks after the configured threshold was reached.
    Log All Requests Specifies that the system displays sessions whose requests the system logs after the configured threshold was reached.
    Delay Blocking Specifies that the system displays sessions whose requests the system delayed blocking until the configured threshold was reached.
  3. From the Scope list, specify the scope (username, session, or IP address) by which to filter the data.
    Option Description
    Alt Specifies that the screen displays all entries. This is the default value.
    Username Specifies that the system displays usernames whose illegal requests exceeded the security policy’s threshold values.
    Session Specifies that the system displays identification numbers of illegal sessions that exceeded the security policy’s threshold values.
    IP Address Specifies that the system displays IP addresses where illegal requests from these IP addresses exceeded the security policy’s threshold values.
    Device ID Specifies that the system displays device IDs where illegal requests from these devices exceeded the security policy’s threshold values.
  4. If you want to filter the information by value, in the Value field, type the username, session identification number, IP address, device ID, or string. If empty, the screen displays all entries.
  5. When you finish specifying the filter details, click Go.
    The Session Tracking Status list now shows the information specified in the Filter setting.
After you set up session tracking, you can monitor the specific requests that cause violations by examining each request and reviewing graphical charts.
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