Manual Chapter :
Preventing Session Hijacking and Tracking User Sessions
Applies To:
Show VersionsBIG-IP ASM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0
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.
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.
- On the Main tab, click.The Session Tracking screen opens.
- In the Session Hijacking area, forDetect Session Hijacking by Device ID Tracking, select theEnabledcheck box.When you are using device ID to track traffic, make sure that theAccept XFFsetting is enabled in the HTTP profile that is assigned to the virtual server.
- ClickSaveto save your settings.
- To set the blocking modes for the hijacking violation, click.
- In the General Settings, set theEnforcement ModetoBlocking.This setting blocks all requests that cause violations, and which are set to block.
- In the Policy Building Settings, expand Cookies, and for theASM Cookie Hijackingviolation, selectLearn,Alarm, andBlock.
- ClickSave.
- To put the security policy changes into effect immediately, clickApply 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.
- On the Main tab, click.The Response Pages screen opens.
- In theCurrent edited security policylist near the top of the screen, verify that the security policy shown is the one you want to work on.
- ClickCookie Hijacking Response Page.
- For theResponse Typesetting, selectErase Cookies.You can use other options such as theDefault Responsepage,Custom Responsepage, orSOAP Fault. ButErase Cookiesis the recommended and default response to cookie hijacking.The system deletes client side domain cookies to block the application user.
- ClickSaveto save your settings.
- To put the security policy changes into effect immediately, clickApply 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.If you are creating a security policy automatically and
selected
Comprehensive
as
the policy template, the default options are already set to create login pages
automatically. If you are using the Fundamental
policy template, the steps here explain the options to
configure ASM to automatically detect and create login pages for your application.
For brute force protection to work, ensure that the policy's
enforcement mode is set to Blocking. If a policy's enforcement mode is set to
Transparent, no brute force mitigation action will be performed.
- On the Main tab, click.The Learning and Blocking Settings screen opens.
- Ensure that theLearning Modeis set toAutomatic.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.
- In the Policy Building Settings area, expandSessions and Loginsand ensure thatBrute Force: Maximum login attempts are exceededis enabled for both Alarm and Block.
- In the Policy Building Process area, expandOptionsand ensure thatLearn from responsesis selected.
- ClickSaveto save your settings.
- In the editing context area, clickApply Policyto 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.
You can also have the system create login pages automatically by
selecting
Detect login pages
on the Learning and Blocking
Settings screen.- On the Main tab, click.The Login Pages List screen opens.
- In theCurrent edited security policylist near the top of the screen, verify that the security policy shown is the one you want to work on.
- ClickCreate.The New Login Page screen opens.
- For theLogin URLsetting, specify a URL that users must pass through to get to the application.
- From the list, select the type of URL:ExplicitorWildcard.
- Select eitherHTTPorHTTPSbased on the type of traffic the web application accepts.
- 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 CharacterMatches*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.
- From theAuthentication Typelist, select the method the web server uses to authenticate the login URL's credentials with a web user.OptionDescriptionNoneThe web server does not authenticate users trying to access the web application through the login URL. This is the default setting.HTML FormThe 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 AuthenticationThe user name and password are transmitted in Base64 and stored on the server in plain text.HTTP Digest AuthenticationThe web server performs the authentication; user names and passwords are not transmitted over the network, nor are they stored in plain text.NTLMMicrosoft 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 RequestThe 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.
- 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.The system checks the access validation criteria on the response according to the content-type of the login URL. Supported content-types are text/*, application/x-javascript, application/sgml, application/xml, application/x-asp, application/x-aspx, application/xhtml+xml, application/json, application/x-shockwave-flash. You can use the internal parameteruser_defined_accum_typeto add supported content-types.
- ClickCreateto add the login page to the security policy.The new login page is added to the login pages list.
- Add as many login pages as needed for your web application.
- In the editing context area, clickApply Policyto 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.
- On the Main tab, click.The Session Tracking screen opens.
- In the Session Tracking Configuration area, select theSession Awarenesscheck box.
- From theApplication Usernamelist, selectUse All Login Pagesto track login sessions for all of the login pages in the security policy.
- In the Violation Detection Actions area, select theTrack Violations and Perform Actionscheck box.
- In theViolation Detection Periodfield, type the number of seconds that indicates the sliding time period to count violations for violation thresholds.The default is900seconds.
- 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.OptionDescriptionBlocked URLsSpecify which URLs to block after the number of violations exceeds the enabled thresholds. To block all URLs, selectBlock all URLs. To block authenticated URLs protected by login pages, selectBlock Authenticated URLs.Username ThresholdSelectEnableand specify the number of violations allowed before the system starts to block this user's activity.Session ThresholdSelectEnableand specify the number of violations allowed before the system starts to block activity for this HTTP session.Device ID ThresholdSelectEnableand specify the number of violations allowed per device ID before the system starts to block activity for this device.IP Address ThresholdSelectEnableand specify the number of violations allowed before the system starts to block the activity for this IP address.Block All PeriodSpecify 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, clickInfinite. Otherwise, clickUser-definedand type the number of seconds to block the traffic. The default is600seconds.For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
- 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.OptionDescriptionUsername ThresholdSelectEnableand specify the number of violations allowed before the system starts logging this user's activity for the log all requests period.Session ThresholdSelectEnableand specify the number of violations allowed before the system starts logging activity for this HTTP session for the log all requests period.Device ID ThresholdSelectEnableand specify the number of violations allowed before the system starts to log requests for this device.IP Address ThresholdSelectEnableand 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 PeriodSpecify how long the system should log all requests when any of the enabled thresholds is reached. Type the number of seconds in the field.
- 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.OptionDescriptionUsername ThresholdSelectEnableand specify the number of violations a user must cause before the system begins blocking this user for the delay blocking period.Session ThresholdSelectEnableand 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 ThresholdSelectEnableand specify the number of violations allowed per device ID before the system starts to block illegal requests from the device.IP Address ThresholdSelectEnableand specify the number of violations allowed before the system begins blocking this IP address for the delay blocking period.Delay Blocking PeriodType the number of seconds that the system should block the user, session, or IP address when any of the enabled thresholds is reached.Associated ViolationsMove the violations for which you want delay blocking from theAvailablelist into theSelectedlist. 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.For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
- ClickSaveto 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.
- On the Main tab, clickSecurityReportingApplicationSession 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.
- From theActionlist, select the action by which to filter the data.ActionDescriptionAllSpecifies that the screen displays all entries. This is the default value.Block AllSpecifies that the system displays sessions whose requests the system blocks after the configured threshold was reached.Log All RequestsSpecifies that the system displays sessions whose requests the system logs after the configured threshold was reached.Delay BlockingSpecifies that the system displays sessions whose requests the system delayed blocking until the configured threshold was reached.
- From theScopelist, specify the scope (username, session, or IP address) by which to filter the data.OptionDescriptionAltSpecifies that the screen displays all entries. This is the default value.UsernameSpecifies that the system displays usernames whose illegal requests exceeded the security policy’s threshold values.SessionSpecifies that the system displays identification numbers of illegal sessions that exceeded the security policy’s threshold values.IP AddressSpecifies that the system displays IP addresses where illegal requests from these IP addresses exceeded the security policy’s threshold values.Device IDSpecifies that the system displays device IDs where illegal requests from these devices exceeded the security policy’s threshold values.
- If you want to filter the information by value, in theValuefield, type the username, session identification number, IP address, device ID, or string. If empty, the screen displays all entries.
- When you finish specifying the filter details, clickGo.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.
- On the Main tab, click.The Session Tracking Status screen opens and shows the users, sessions, and IP addresses that the system is currently tracking for this security policy.
- Next to the Session Tracking Status list, clickAdd.The Add Session to Tracking screen opens.
- From theActionlist, select the action that the system will take if it detects the specified username, session, or IP address.ActionDescriptionBlock AllSpecifies 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 RequestsSpecifies that the system blocks all requests from a specific username, session ID, IP address, or device ID for the configured period of time.Delay BlockingSpecifies 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.
- From theScopelist, specify whether the system is tracking a specific Username (the default value), Session, IP Address, or device ID.
- In theValuefield, type the unique username, session identification number, or IP address that you want to track, based on what you selected in theScopeoption.
- ClickAdd.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 ().
- Configure an NTP server ().
- Restart ASM (at the command line, typetmsh 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.- On the Main tab, click.The VLAN List screen opens.
- ClickCreate.The New VLAN screen opens.
- In theNamefield, type a unique name for the VLAN.
- In theTagfield, 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.
- If you want to use Q-in-Q (double) tagging, use theCustomer Tagsetting to perform the following two steps. If you do not see theCustomer Tagsetting, your hardware platform does not support Q-in-Q tagging and you can skip this step.
- From theCustomer Taglist, selectSpecify.
- Type a numeric tag, from 1-4094, for the VLAN.
The customer tag specifies the inner tag of any frame passing through the VLAN. - For theInterfacessetting,
- From theInterfacelist, select an interface number.
- From theTagginglist, selectUntagged.
- ClickAdd.
- For theHardware SYN Cookiesetting, select or clear the check box.When you enable this setting, the BIG-IP system triggers hardware SYN cookie protection for this VLAN.Enabling this setting causes additional settings to appear. These settings appear on specific BIG-IP platforms only.
- For theSyncache Thresholdsetting, retain the default value or change it to suit your needs.TheSyncache Thresholdvalue represents the number of outstanding SYN flood packets on the VLAN that will trigger the hardware SYN cookie protection feature.When theHardware SYN Cookiesetting is enabled, the BIG-IP system triggers SYN cookie protection in either of these cases, whichever occurs first:
- The number of TCP half-open connections defined in the LTM settingGlobal SYN Check Thresholdis reached.
- The number of SYN flood packets defined in thisSyncache Thresholdsetting is reached.
- For theSYN Flood Rate Limitsetting, retain the default value or change it to suit your needs.TheSYN Flood Rate Limitvalue represents the maximum number of SYN flood packets per second received on this VLAN before the BIG-IP system triggers hardware SYN cookie protection for the VLAN.
- ClickFinished.The screen refreshes, and it 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.
- On the Main tab, click.
- ClickCreate.The New Self IP screen opens.
- In theNamefield, type a unique name for the self IP address.
- In theIP Addressfield, type an IPv4 or IPv6 address.This IP address should represent the address space of the VLAN that you specify with theVLAN/Tunnelsetting.
- In theNetmaskfield, type the network mask for the specified IP address.For example, you can type255.255.255.0.
- From theVLAN/Tunnellist, 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.
- Use the default values for all remaining settings.
- ClickFinished.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.
Instead of doing it now, you can optionally create a pool if creating a virtual
server during security policy creation.
- On the Main tab, click.The Pool List screen opens.
- ClickCreate.The New Pool screen opens.
- In theNamefield, type a unique name for the pool.
- In the Resources area, for theNew Memberssetting, add to the pool the application servers that host the web application:
- Type an IP address in theAddressfield.
- In theService Portfield, type a port number (for example, type80for the HTTP service), or select a service name from the list.
- ClickAdd.
- ClickFinished.
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.
- On the Main tab, click.The Virtual Server List screen opens.
- ClickCreate.The New Virtual Server screen opens.
- In theNamefield, type a unique name for the virtual server.
- In theService Portfield, type443or selectHTTPSfrom the list.
- From theConfigurationlist, selectAdvanced.
- From theHTTP Profilelist, selecthttp.
- For theSSL Profile (Client)setting, from theAvailablelist, selectclientssl, and using the Move button, move the name to theSelectedlist.
- From theSSL Profile (Server)list, selectserverssl.This setting ensures that there is an SSL connection between the HTTP virtual server and the external HTTPS server.
- From theSource Address Translationlist, selectAuto Map.
- From theDefault Poollist, select the pool that is configured for application security.
- ClickFinished.
The HTTPS virtual server appears in the Virtual Server List screen.
Creating a virtual server to manage HTTP/2 traffic
You can create a virtual server to manage HTTP/2
traffic. An HTTP/2 virtual server provides security checks for vulnerabilities that are
specific to HTTP/2. You can also configure a virtual server for HTTP/2 traffic at part
of a policy configuration.
- On the Main tab, click.
- ClickCreate...The New Virtual Server... screen opens.
- Enter a unique name for the virtual server.
- In theConfigurationsection:
- ForHTTP Profile (Client), selectHTTP.
- ForSSL Profile (Client), selectclientssl-secure.
- ForSSL Profile (Server), selectserverssl-secure.
- In theAccelerationsection:
- ForHTTP/2 Profile (Client), selecthttp2.
- ForHTTP/2 Profile (Server), selecthttp2.
- SelectHTTP MRF Router.
- Continue with any other needed virtual server configurations.
- ClickFinished.
The HTTPS virtual server appears in the Virtual
Server List screen. You can view configured HTTP/2 profiles at
.Creating a simple security policy
Before you can create a security
policy, you must perform the minimal system configuration tasks required according to
the needs of your networking environment.
You can use Application Security Manager to create a robust, yet simple, security policy
that is tailored to protect your web application. This is the easiest way to create a
security policy.
- On the Main tab, click.The Policies List screen opens.
- ClickCreate New Policy.You only see this button when no policy is selected.
- In thePolicy Namefield, type a name for the policy.
- LeavePolicy Type, set toSecurity.
- ForPolicy Template, selectFundamental.
- ForVirtual Server, clickConfigure new virtual serverto specify where to direct application requests.
- ForWhat type of protocol does your application use?, selectHTTP,HTTPS, or both.
- In theVirtual Server Namefield, type a unique name.
- In theHTTP/HTTPS Virtual Server Destinationfield, type the address in IPv4 (10.0.0.1) or IPv6 (2001:ed8:77b5:2:10:10:100:42/64) format, and specify the service port.If you want multiple IP addresses to be directed here, use theNetworksetting.
- In theHTTP/HTTPS Pool Membersetting, specify the addresses of the back-end application servers.
- If you have chosen HTTPS protocol, in theSSL Profile (Client)field, select clientssl to enable theHTTP/2 Profile (Client)field.
- If you have chose HTTPS protocol, in theSSL Profile (Server)field, select serverssl to enable theHTTP/2 Profile (Server)field.
- From theLogging Profilelist, select a profile such asLog illegal requeststo determine which events are logged on the system.
- In the upper right corner, clickAdvanced.You can use default values for the Advanced settings but it's a good idea to take a look at them.
- If you selectedFundamentalorComprehensivefor thePolicy Template,Learning Modeis set toAutomaticandEnforcement Modeis set toBlocking.If you need to change these values, set application language to a value other thanAuto detect.
- If you know theApplication Language, select it or useUnicode (utf-8).
- To add specific protections (enforcing additional attack signatures) to the policy, forServer Technologies, select the technologies that apply to the back-end application servers.
- You can configure trusted IP addresses that you want the security policy to consider safe.
- ClickCreate Policyto create the security policy.
ASM creates a
security policy that immediately starts protecting your application. The enforcement
mode of the security policy is set to Blocking. Traffic that is considered to be an
attack such as traffic that is not compliant with HTTP protocol, has malformed payloads,
uses evasion techniques, performs web scraping, contains sensitive information or
illegal values is blocked. Other potential violations are reported but not
blocked.
The system examines the traffic to the web application making suggestions
for more specifically building the security policy. The Policy Builder selectively
learns new entities like file types, parameters, and cookies used in requests to the
application. When ASM processes sufficient traffic, it automatically adds the
entities to the security policy, and enforces them.
The system applies a basic
set of attack signatures to the security policy and puts them in staging (by
default, for 7 days). If you specified server technologies, additional attack
signatures are included. ASM reports common attacks discovered by comparison to the
signatures but does not block these attacks until the staging period is over and
they are enforced. That gives you a chance to be sure that these are actual attacks
and not legitimate requests.
This is a good point at
which send some traffic 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. Send the traffic to the virtual server
destination address.
Creating an access profile
You create an access profile to provide the access policy configuration for a
virtual server that establishes a secured session.
- On the Main tab, click.The Access Profiles (Per-Session Policies) screen opens.
- ClickCreate.The New Profile screen opens.
- In theNamefield, type a unique name for the access profile.
- From theProfile Typelist, selectSSL-VPN.Additional settings display.
- From theProfile Scopelist, retain the default value or select another.
- Profile: Gives an user access only to resources that are behind the same access profile. This is the default value.
- Virtual Server: Gives an user access only to resources that are behind the same virtual server.
- Global: Gives an user access to resources behind any access profile that has global scope.
- Named: Gives an SSL Orchestrator user access to resources behind any access profile that has global scope.
- ForCustomization Type, selectModern.You can also useStandardbutModerncustomization is simpler and provides better compatibility for modern cross-platform and cross-device applications.
- To configure timeout and session settings, select theCustomcheck box.
- In theInactivity Timeoutfield, type the number of seconds that should pass before the access policy times out. Type0to set no timeout.If there is no activity (defined by theSession Update ThresholdandSession Update Windowsettings in the Network Access configuration) between the client and server within the specified threshold time, the system closes the current session.
- In theAccess Policy Timeoutfield, type the number of seconds that should pass before the access profile times out because of inactivity.Type0to set no timeout.
- In theMaximum Session Timeoutfield, type the maximum number of seconds the session can exist.Type0to set no timeout.
- In theMinimum Authentication Failure Delayfield, type the minimum number of seconds to delay before displaying an error after authentication failure. The default value is 2. Delay affects the following authentication types: Active Directory, HTTP, Kerberos, LDAP, local user database, one-time password verification, Oracle Access Manager, RADIUS, SecurID, and TACACS+.
- In theMaximum Authentication Failure Delayfield, type the maximum number of seconds of delay before displaying an error after authentication failure. The default value is 5.Set this value to no more than one-half the Access Policy Timeout setting value and no more than 65 seconds greater than the value of the Minimum Authentication Failure Delay setting.
- In theMax Concurrent Usersfield, type the maximum number of users that can use this access profile at the same time.Type0to set no maximum.
- In theMax Sessions Per Userfield, type the maximum number of concurrent sessions that one user can start.Type0to set no maximum.Only a user in the administrator, application editor, manager, or resource administrator role has access to this field.
- In theMax In Progress Sessions Per Client IPfield, type the maximum number of concurrent sessions that can be in progress for a client IP address.When setting this value, take into account whether users will come from a NAT-ed or proxied client address and, if so, consider increasing the value accordingly. The default value is 128.Only a user in the administrator, application editor, manager, or resource administrator role has access to this field.F5 does not recommend setting this value to0(unlimited).
- Select theRestrict to Single Client IPcheck box to restrict the current session to a single IP address.This setting associates the session ID with the IP address.Only a user in the administrator, application editor, manager, or resource administrator role has access to this field.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.
- To redirect users attempting to access the root URI in a validated session with a webtop, selectRedirect client to webtop on root URI access.Users are redirected to the webtop in this case. Otherwise, requests are forwarded.
- To configure logout URIs, in the Configurations area, type each logout URI in theURIfield, and then clickAdd.
- In theLogout URI Timeoutfield, type the delay in seconds before logout occurs for the customized logout URIs defined in theLogout URI Includelist.
- 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.
- In theDomain Cookiefield, specify a domain cookie, if the application access control connection uses a cookie.
- In theCookie Optionssetting, specify whether to use a secure cookie.
- If the policy requires a secure cookie, select theSecurecheck box to add thesecurekeyword 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.
- If the access policy requires a persistent cookie, in theCookie Optionssetting, select thePersistentcheck 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.
- From theSSO Configurationlist, select an SSO configuration.
- 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.
- ClickFinished.
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.
- On the Main tab, click.The Access Profiles (Per-Session Policies) screen opens.
- Click the name of the access profile you want to edit.
- On the menu bar, clickAccess Policy.
- For theVisual Policy Editorsetting, click theEdit access policy for Profilelink.policy_nameThe visual policy editor opens the access policy in a separate window or tab.
- Click the(+)icon anywhere in the access policy to add a new item.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.
- On the Logon tab, selectLogon Pageand click theAdd Itembutton.The Logon Page Agent properties screen opens.
- ClickSave.The Access Policy screen reopens.
- On the rule branch, click the plus sign(+)betweenLogon PageandDeny.
- Set up the appropriate authentication and client-side checks required for application access at your company, and clickAdd Item.
- Change the Successful rule branch fromDenytoAllowand click theSavebutton.
- If needed, configure further actions on the successful and fallback rule branches of this access policy item, and save the changes.
- At the top of the screen, click theApply Access Policylink to apply and activate your changes to this access policy.
- Click theClosebutton to close the visual policy editor.
To
apply this access policy to network traffic, add the access profile to a virtual
server.
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
- On the Main tab, click.The Virtual Server List screen opens.
- Click the name of the virtual server you want to modify.
- In the Access Policy area, from theAccess Profilelist, select the access profile that you configured earlier.
- ClickUpdateto save the changes.
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.
- On the Main tab, click.The Session Tracking screen opens.
- In the Session Tracking Configuration area, select theSession Awarenesscheck box.
- From theApplication Usernamelist, selectUse APM Usernames and Session ID.
- In the Violation Detection Actions area, select theTrack Violations and Perform Actionscheck box.
- In theViolation Detection Periodfield, type the number of seconds that indicates the sliding time period to count violations for violation thresholds.The default is900seconds.
- 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.OptionDescriptionBlocked URLsSpecify which URLs to block after the number of violations exceeds the enabled thresholds. To block all URLs, selectBlock all URLs. To block authenticated URLs protected by login pages, selectBlock Authenticated URLs.Username ThresholdSelectEnableand specify the number of violations allowed before the system starts to block this user's activity.Session ThresholdSelectEnableand specify the number of violations allowed before the system starts to block activity for this HTTP session.Device ID ThresholdSelectEnableand specify the number of violations allowed per device ID before the system starts to block activity for this device.IP Address ThresholdSelectEnableand specify the number of violations allowed before the system starts to block the activity for this IP address.Block All PeriodSpecify 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, clickInfinite. Otherwise, clickUser-definedand type the number of seconds to block the traffic. The default is600seconds.For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
- 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.OptionDescriptionUsername ThresholdSelectEnableand specify the number of violations allowed before the system starts logging this user's activity for the log all requests period.Session ThresholdSelectEnableand specify the number of violations allowed before the system starts logging activity for this HTTP session for the log all requests period.Device ID ThresholdSelectEnableand specify the number of violations allowed before the system starts to log requests for this device.IP Address ThresholdSelectEnableand 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 PeriodSpecify how long the system should log all requests when any of the enabled thresholds is reached. Type the number of seconds in the field.
- 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.OptionDescriptionUsername ThresholdSelectEnableand specify the number of violations a user must cause before the system begins blocking this user for the delay blocking period.Session ThresholdSelectEnableand 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 ThresholdSelectEnableand specify the number of violations allowed per device ID before the system starts to block illegal requests from the device.IP Address ThresholdSelectEnableand specify the number of violations allowed before the system begins blocking this IP address for the delay blocking period.Delay Blocking PeriodType the number of seconds that the system should block the user, session, or IP address when any of the enabled thresholds is reached.Associated ViolationsMove the violations for which you want delay blocking from theAvailablelist into theSelectedlist. 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.For the system to block requests, the security policy Enforcement Mode must be set to blocking and some violations must be set to block.
- ClickSaveto 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.
- On the Main tab, clickSecurityReportingApplicationSession 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.
- From theActionlist, select the action by which to filter the data.ActionDescriptionAllSpecifies that the screen displays all entries. This is the default value.Block AllSpecifies that the system displays sessions whose requests the system blocks after the configured threshold was reached.Log All RequestsSpecifies that the system displays sessions whose requests the system logs after the configured threshold was reached.Delay BlockingSpecifies that the system displays sessions whose requests the system delayed blocking until the configured threshold was reached.
- From theScopelist, specify the scope (username, session, or IP address) by which to filter the data.OptionDescriptionAltSpecifies that the screen displays all entries. This is the default value.UsernameSpecifies that the system displays usernames whose illegal requests exceeded the security policy’s threshold values.SessionSpecifies that the system displays identification numbers of illegal sessions that exceeded the security policy’s threshold values.IP AddressSpecifies that the system displays IP addresses where illegal requests from these IP addresses exceeded the security policy’s threshold values.Device IDSpecifies that the system displays device IDs where illegal requests from these devices exceeded the security policy’s threshold values.
- If you want to filter the information by value, in theValuefield, type the username, session identification number, IP address, device ID, or string. If empty, the screen displays all entries.
- When you finish specifying the filter details, clickGo.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.