Applies To:

Show Versions Show Versions

Manual Chapter: New Visual Policy Editor actions
Manual Chapter
Table of Contents   |   << Previous Chapter

About date and time

You can use the Date Time action to check the date or the time to specify time-based access. This action provides two default branch rules: Weekend (defined as Saturday and Sunday) and Business Hours (defined as 8:00am to 5:00pm).

You can modify and delete the existing rules and create new ones using the available conditions:

  • Time From Specifies a time of day. The condition is true at or after the specified time.
  • Time To Specifies a time of day. This condition is true before or at the specified time.
  • Date From Specifies a date. This condition is true at or after the specified date.
  • Date To Specifies a date. This condition is true before or at the specified date
  • Day of Week Specifies a day. The condition is true for the entire day (local time zone).
  • Day of Month Specifies the numeric day of month. This condition is true for this day every month (local time zone).

About license check

You can use the License Check action to create branch rules based on license use. heck for the number of remaining licenses against an absolute value or the percentage of licenses remaining against a threshold. You can run a license check for access licenses, connectivity licenses, and concurrent users.

The License Check action supplies a default branch you that you must change to meet your requirements. You can define this action using the available conditions:

  • Remaining Global Access License count is above absolute value Checks number of remaining global access licenses against the number that you specify.
  • Remaining Global Access License count is above percentage threshold Checks percentage of global access licenses that remain against the threshold that you specify.
  • Remaining Global Connectivity License count is above absolute value Checks number of remaining global connectivity licenses against the number that you specify.
  • Remaining Global Connectivity License count is above percentage threshold Checks percentage of global connectivity licenses that remain against the threshold that you specify
  • Remaining Concurrent User count is above absolute value Checks number of remaining concurrent user licenses against the number that you specify
  • Remaining Concurrent User count is above percentage threshold Checks percentage of concurrent user licenses that remain against the threshold that you specify

If the license check does not match the specified conditions, the access policy sends the user to the fallback branch.

About IP reputation check

When you include an IP Reputation Check action in an access policy, Access Policy Managersearches for the IP address in the IP intelligence database. The IP intelligence database contains only IP addresses that are considered untrustworthy, along with a category for each that describes why it is not trusted.

APM provides these default branch rules for the IP Reputation Check action.

Bad
The IP address exists in the IP intelligence database. The expression for this branch rule includes every IP reputation category. For example, the rule includes expressions such as IP Reputation is: Spam Sources OR IP Reputation is: Proxy, and so on. If any IP reputation category is acceptable at your site, you should update this rule or create and use another rule.
Good
The IP address is not found in the IP intelligence database.
fallback
The IP intelligence database is inaccessible for some reason. This can be due to a misconfiguration or a problem with a license or Internet connectivity.

About IP address subnet match

Use the IP Subnet Match action to check whether the client IP address matches an IP subnet. You can define the action with this option:

IP Subnet Match Specifies a subnet, such as 10.0.0.0/8.

About NTLM authentication result check

If NTLM authentication occurs, it happens before the access policy runs. Use the NTLM Auth Result Check action to check whether NTLM authentication occurred. You can configure branch rules with the available condition, NTLM Auth Passed.

About one-time password generation

You can use an OTP Generate action to generate a one-time use time-limited password that you can send to a user. You can define the OTP Generate action with these elements:

OTP length
Specifies the length of the one-time password. Select from the values provided. Defaults to 6.
OTP timeout
Specifies the number of seconds that the password is valid. Defaults to 300.

About one-time password verification

In an access policy, the OTP Verify action checks for a match between a user-entered password and the one-time password generated previously by the OTP Generate action. The OTP Verify action also checks whether the one-time password has expired. You can define the OTP Verify action with this element:

Max Logon Attempts Allowed
Limits the number of logon attempts. Select from the values provided. Defaults to 3.

About SAML authentication

Use the SAML Auth action for authenticating against an external SAML Identity Provider (IdP). Use this action only when the BIG-IP system is configured as a SAML service provider and supports connections initiated at SAML service providers. You can define the action with the following options:

  • AAA server Specifies an external SAML IdP. (IdPs are specified in SAML IdP connector configurations).
  • Branch Rules Configure the rule using the available condition, SAML Auth Passed.

Overview: Preventing a known bad IP address from starting a session

You can prevent an IP address with a bad reputation from starting a session by configuring an IP Reputation Check action in an access policy.

Note: To put the access policy to use, assign the corresponding access profile to a virtual server.

How do I know whether malicious clients are running sessions?

If IP address intelligence is enabled on the BIG-IP system, you can obtain IP reputation information from these Access Policy Manager reports:

  • All Sessions - Displays an IP Reputation column for each session. When IP address intelligence is not enabled, the IP reputation value is Unknown.
  • Bad IP Reputation Sessions - Lists only those sessions for which the IP address has a reputation. When IP address intelligence is not enabled, the report contains no data.

Task summary

Task list

Enabling IP address intelligence

The requirements for using IP address intelligence are:
  • The system must have an IP Intelligence license.
  • The system must have an Internet connection either directly or through an HTTP proxy server.
  • The system must have DNS configured (go to System > Configuration > Device > DNS).
Important: IP address intelligence is enabled by default. You only need to enable it if it was previously disabled.
To enable IP address intelligence on the BIG-IP system, you enable auto-update to connect the system to the IP intelligence database.
  1. Log in to the command line for the BIG-IP system.
  2. To determine whether IP intelligence is enabled, type the following command: tmsh list sys db iprep.autoupdate If the value of the iprep.autoupdate variable is disable, IP intelligence is not enabled. If it is enable, your task is complete.
  3. At the prompt, type tmsh modify sys db iprep.autoupdate value enable The system downloads the IP intelligence database and stores it in the binary file, /var/IpRep/F5IpRep.dat. It is updated every 5 minutes.
  4. If the BIG-IP system is behind a firewall, make sure that the BIG-IP system has external access to vector.brightcloud.com using port 443. That is the IP Intelligence server from which the system gets IP Intelligence information.
  5. Optional: If the BIG-IP system connects to the Internet using a forward proxy server, set these system database variables.
    1. Type tmsh modify sys db proxy.host value hostname to specify the host name of the proxy server.
    2. Type tmsh modify sys db proxy.port value port_number to specify the port number of the proxy server.
    3. Type tmsh modify sys db proxy.username value username to specify the user name to log in to the proxy server.
    4. Type tmsh modify sys db proxy.password value password to specify the password to log in to the proxy server.
The IP address intelligence feature remains enabled unless you disable it with the command tmsh modify sys db iprep.autoupdate value disable.

Adding an IP reputation check to an access policy

Before you can add an IP Reputation Check action to an access policy, your system must have IP address intelligence enabled. Before you can edit an access policy, you must create an access profile.
You add an IP reputation check to an access policy to be able to stop malicious clients from starting sessions.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. From the Server Side Checks list, select IP Reputation Check.
  5. Click Add Item. The screen is not active while the visual policy editor creates the action. The screen closes and a Properties screen displays.
  6. In the Name field, type a name for the access policy item. This name is displayed in the action field for the access policy.
  7. Click Save. The properties screen closes. The visual policy editor is displayed.
  8. Add actions to the fallback branch to specify what to do if the IP intelligence database is unavailable. For example, add an email action to send a message to an administrator and add an authentication action to let the session proceed or add a Message Box action and deny access. By default, the fallback action ending is Deny.
This adds an IP Reputation Check action to the access policy.
IP reputation check with good, bad, and fallback branches Example access policy that includes an IP reputation check
Complete the access policy with additional actions and appropriate endings on each branch, and apply it. To put an access policy into effect, add it to a virtual server.

IP address intelligence categories

Along with the IP address, the IP intelligence database stores the category that explains the reason that the IP address is considered untrustworthy.

Category Description
Windows exploits IP addresses that have exercised various exploits against Windows resources using browsers, programs, downloaded files, scripts, or operating system vulnerabilities.
Web attacks IP addresses that have launched web attacks of various forms.
Botnets IP addresses of computers that are infected with malicious software and are controlled as a group, and are now part of a botnet. Hackers can exploit botnets to send spam messages, launch various attacks, or cause target systems to behave in other unpredictable ways.
Scanners IP addresses that have been observed to perform port scans or network scans, typically to identify vulnerabilities for later exploits.
Denial of Service IP addresses that have launched Denial of Service (DoS) attacks. These attacks are usually requests for legitimate services, but occur at such a fast rate that targeted systems cannot respond and become bogged down or unable to service legitimate clients.
Infected Sources IP addresses that issue HTTP requests with a low reputation index score, or are known malware sites.
Phishing IP addresses that are associated with phishing web sites that masquerade as legitimate web sites.
Proxy IP addresses that are associated with web proxies that shield the originator's IP address (such as anonymous proxies).

About agents to use to send a one-time password over SMS or SMTP

Access Policy Manager supports sending a one-time password to a user through email or text messaging.

To send email from an access policy, use the Email agent action. To use this agent, you must have an external SMTP server.

To send a text message from an access policy, you can use either of these agents:

  • Email. To use this agent, configure your external SMTP server to deliver the OTP to an SMS gateway.
  • HTTP Auth. To use this agent, configure an HTTP AAA server type in APM that uses form-based authentication.

Overview: Providing a one-time password using email

Access Policy Manager supplies an OTP Generate action that generates a one-time time-sensitive password and an OTP Verify action that verifies that a user entered the correct password before that password expired. In between the two actions, you must configure an action that delivers the one-time password to the user. To send the password in an email message, use the Email agent. You must have an external SMTP server and you must create an SNMP server configuration for it on the BIG-IP system.

Related access policy macro

A macro template to configure OTP over email is available for use in an access policy. Look at the macro, AD auth query OTP by email and resources, from the visual policy editor to determine whether to use it to help you configure the access policy more quickly.

Task summary

Creating an SMTP server configuration

To send emails through an SMTP server, you first need to specify the SMTP server configuration.
  1. On the Main tab, click System > Configuration > Device > SMTP.
  2. Click the Create button. The New SMTP Configuration screen opens.
  3. In the Name field, type a name for the SMTP server that you are creating.
  4. In the SMTP Server Host Name field, type the fully qualified domain name for the SMTP server host.
  5. In the SMTP Server Port Number field, type a port number. For no encryption or TLS encryption, the default is 25. For SSL encryption, the default is 465.
  6. In the Local Host Name field, type the host name used in the SMTP headers in the form of a fully qualified domain name. This host name is not the same as the BIG-IP system's host name.
  7. In the From Address field, type the email address that you want displayed as the reply-to address for the email.
  8. From the Encrypted Connection list, select the encryption level required for the SMTP server.
  9. To require that the SMTP server validates users before allowing them to send email, select the Use Authentication check box and type the user name and password required to validate the user.
  10. Click the Finish button.
You can now configure the system to use this SMTP server to send emails.

Creating an access policy to send an OTP using email

Before you start this task, configure an access profile.
Create an access policy like this when you need to generate and send a one-time password over email.
Note: Look at the macro, AD query auth OTP by email and resources, to determine whether to use it to configure an access policy similar to this one.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Add actions to authenticate the user and find an email address and a mobile phone number.
    1. Click the (+) sign anywhere in your access profile to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. Select AD Auth and click Add Item. A popup properties screen displays.
    3. From the Server list, select a server and click Save. The properties screen closes.
    4. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    5. Select AD Query and click Add Item. An AD Query is only one way to find the email address for a user. If users normally log on to your system with an email address as their username, you can get the email address using a Logon Page action. A popup properties screen displays.
    6. From the Server list, select a server.
    7. Click Add new entry. An empty entry displays under Required Attributes (optional).
    8. Type mobile into the Required Attributes (optional) field After the query, the session.ad.last.attr.mobile variable holds the value.
    9. Click Add new entry. An empty entry displays under Required Attributes (optional).
    10. Type mail into the Required Attributes (optional) field After the query, the session.ad.last.attr.mail variable holds the value.
    11. Click Save. The properties screen closes.
  4. Generate a one-time password.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the Authentication are, select OTP Generate and click Add Item.
    3. Click Save. The properties window closes and the visual policy editor is displayed.
  5. Send the OTP to the user through the Email agent.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the General Purpose area, select Email and click Add Item.
    3. From the SMTP Configuration list, select a configuration. The configuration specifies an external SMTP server to send the email.
    4. In the From field, type an email address on the system.
    5. In the To field, type an email address, a session variable, or a session variable and a string. For example, type %{session.ad.last.attr.mobile}@providerservice.com where providerservice.com is supplied by a mobile phone provider.
    6. Type a subject in the Subject field.
    7. In the Message field, type the one-time password and anything else the user should know. One Time Passcode: %{session.otp.assigned.val} Expires after use or in %{session.otp.assigned.ttl} seconds
    8. Click Save. The properties window closes and the visual policy editor is displayed.
  6. Add a Logon Page action that requests the one-time password only.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the General Purpose, select Logon Page and click Add Item. A popup properties screen displays.
    3. From the Logon Page Agent area, on line 1 select none from the Type column to remove the user name input field from the logon page; do not change line 2 (password).
    4. From the Customization area in Logon Page Input Field # 2, type a prompt for the field. For example, type One-Time Passcode.
    5. Click Save. The properties window closes and the visual policy editor is displayed.
  7. Verify the one-time password.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the Authentication are, select OTP Verify and click Add Item.
    3. Click Save. The properties window closes and the visual policy editor is displayed.
  8. Optional: Add any other branches and actions that you need to complete the access policy.
  9. Change the Successful rule branch from Deny to Allow and click the Save button.
  10. At the top of the window, click the Apply Access Policy link to apply and activate your changes to this access policy.
  11. Click the Close button to close the visual policy editor.
You have an access policy that provides a user with a one-time time-based password over SMTP.
To put the access policy into effect, you must attach it to a virtual server.

Overview: Providing a one-time password using an external SMS

Access Policy Manager supplies an OTP Generate action that generates a one-time time-sensitive password and an OTP Verify action that verifies that a user entered the correct password before it expired. In between the two actions, you must configure an action that delivers the one-time password to the user. To send the password in a text message, you can use a form-based HTTP authentication agent (if you do not want to use an Email agent). You pass the one-time password in hidden parameters to a form action. You must create a form action that sends the OTP using an external SMS.

Configuration process

Configuration flow for OTP over SMS using HTTP authenticationCreating a configuration to send an OTP over SMS using HTTP authentication

Related access policy macro

A macro template to configure an OTP and use the HTTP Auth agent to deliver it is available for use in an access policy. Look at the macro, AD query auth OTP by HTTP and resources, from the visual policy editor to determine whether to use it to help you configure the access policy more quickly.

Task summary

Configuring HTTP form-based authentication to deliver a one-time password

Configure an AAA HTTP server to use a form action that you configured previously to send a one-time password through an external SMS.
  1. Select Access Policy > AAA Servers > HTTP. The HTTP Servers screen displays.
  2. Click Create. The New Server properties screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. From the Configuration area, select Form Based for the Authentication Type.
  5. Let the Form Method remain at the default setting, POST.
  6. In the Form Action field, type the complete destination URL to process the form. Specify a URL for a form action that you created to send a user a one-time password using an SMS.
  7. In the Hidden Form Parameters/Values field, type parameters and values for the one-time password, the phone number, and any other values that the form action requires. Here is an example. otp_http_mobile "%{session.ad.last.attr.mobile}" otp_http_email "%{session.ad.last.attr.mail}" otp_http_body "One Time Passcode: %{session.otp.assigned.val} Expires after use or in %{session.otp.assigned.ttl} seconds"
  8. From the Successful Logon Detection Match Type list, select the method that the authenticating server uses.
  9. In the Successful Logon Detection Match Value field, type the value that denotes successful logon. Type a cookie name, a URL, or a string, depending on the successful logon detection match type you selected.
  10. Click Finished to add the new server to the configuration, and return to the main screen.
An HTTP server for form-based authentication with a one-time password is ready for use.

Creating an access policy to send an OTP using an SMS

Before you start this task, configure an access profile and configure a form action that uses an external SMS to send the one-time password.
Create an access policy like this when you need to generate and send a one-time password as a text message and you do not want to send it using email.
Note: The macro, AD auth query OTP by HTTP and resources, is available from the visual policy editor and might be useful to configure an access policy similar to this one.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Add actions to authenticate the user and find a mobile phone number.
    1. Click the (+) sign anywhere in your access profile to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. Select AD Auth and click Add Item. A pop-up properties screen displays.
    3. From the Server list, select a server and click Save. The properties screen closes.
    4. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    5. Select AD Query and click Add Item. A pop-up properties screen displays.
    6. From the Server list, select a server.
    7. Click Add new entry. An empty entry displays under Required Attributes (optional).
    8. Type mobile into the Required Attributes (optional) field
    9. Click Save. The properties screen closes.
  4. Generate a one-time password.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the Authentication area, select OTP Generate and click Add Item.
    3. Click Save. The properties window closes and the visual policy editor is displayed.
  5. Make the OTP secure.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. In the General Purpose area, select Variable Assign and click Add Item. A properties screen opens.
    3. Click Add new entry. An Empty entry appears.
    4. Click the change link in the new entry. A popup screen opens.
    5. From the Unsecure list, select Secure.
    6. In the Custom Variable text box, type session.user.otp.pwd.
    7. In the Custom Expression text box, type expr { [mcget {session.user.otp.pw}]}.
    8. Click Finished. The pop-up screen closes.
  6. Send the OTP through the HTTP Auth agent.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the Authentication area, select HTTP Auth and click Add Item.
    3. From the AAA server list, select the HTTP form-based server that you configured previously.
    4. Click Save. The properties window closes and the visual policy editor is displayed.
  7. Add a Logon Page action that requests only the one-time password.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the General Purpose, select Logon Page and click Add Item. A pop-up properties screen displays.
    3. From the Logon Page Agent area, on line 1 select password from the Type column and change the post and session variable names. The variable name password is acceptable.
    4. From the Customization area in Logon Page Input Field # 1, type a prompt for the field. For example, type One-Time Passcode.
    5. Click Save. The properties window closes and the visual policy editor is displayed.
  8. Verify the one-time password.
    1. On the Successful branch after the previous action, click the (+) sign. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
    2. From the Authentication area, select OTP Verify and click Add Item.
    3. Click Save. The properties window closes and the visual policy editor is displayed.
  9. Optional: Add any other branches and actions that you need to complete the access policy.
  10. Change the Successful rule branch from Deny to Allow and click the Save button.
  11. At the top of the window, click the Apply Access Policy link to apply and activate your changes to this access policy.
  12. Click the Close button to close the visual policy editor.
You have an access policy that uses HTTP authentication to provide a user with a one-time time-based password over SMS.
To put the access policy into effect, you must attach it to a virtual server.

Session variables reference

This table includes session variables and related reference information.

Session variables for access policy action items

Agent Session Variable Type Description
OTP Generate session.otp.assigned.val string Generated one-time password value to send to the end user. Example message: One-Time Passcode: %{session.otp.assigned.val}
session.otp.assigned.expire string Internally used timestamp; OTP expiration in seconds since this date and time: (00:00:00 UTC, January 1, 1970)
session.otp.assigned.ttl string OTP time-to-live; configurable as OTP timeout in seconds. Example message: OTP expires after use or in %{session.otp.assigned.ttl} seconds
OTP Verify session.otp.verify.last.authresult bool Result of OTP authentication attempt: 0 - Failed 1 - Passed
Logon Page (CAPTCHA challenge) session.logon.captcha.tracking unsigned integer The unsigned integer is treated as a bitmask. Determines whether to track successful/unsuccessful logon attempts by IP (bit in 0 position) and/or by username (bit in 1 position) when CAPTCHA is enabled. Should not be used by external modules because it is intended for very specific purposes.
Table of Contents   |   << Previous Chapter

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)