Information About Cisco Cloud Web Security
When you enable Cloud Web Security on the ASA, the ASA transparently redirects selected HTTP and HTTPS traffic to the Cloud Web Security proxy servers based on service policy rules. The Cloud Web Security proxy servers then scan the content and allow, block, or send a warning about the traffic based on the policy configured in Cisco ScanCenter to enforce acceptable use and to protect users from malware.
The ASA can optionally authenticate and identify users with Identity Firewall and AAA rules. The ASA encrypts and includes the user credentials (including usernames and user groups) in the traffic it redirects to Cloud Web Security. The Cloud Web Security service then uses the user credentials to match the traffic to the policy. It also uses these credentials for user-based reporting. Without user authentication, the ASA can supply an (optional) default username and group, although usernames and groups are not required for the Cloud Web Security service to apply policy.
You can customize the traffic you want to send to Cloud Web Security when you create your service policy rules. You can also configure a “whitelist” so that a subset of web traffic that matches the service policy rule instead goes directly to the originally requested web server and is not scanned by Cloud Web Security.
You can configure a primary and a backup Cloud Web Security proxy server, each of which the ASA polls regularly to check for availability.
User Identity and Cloud Web Security
You can use user identity to apply policy in Cloud Web Security. User identity is also useful for Cloud Web Security reporting. User identity is not required to use Cloud Web Security. There are other methods to identify traffic for Cloud Web Security policy.
You can use the following methods of determining the identity of a user or of providing a default identity:
-
Identity firewall—When the ASA uses identity firewall with Active Directory (AD), the username and group is retrieved from the AD agent. Users and groups are retrieved when you use them in an ACL in a feature such as an access rule or in your service policy, or by configuring the user identity monitor to download user identity information directly.
-
AAA rules—When the ASA performs user authentication using a AAA rule, the username is retrieved from the AAA server or local database. Identity from AAA rules does not include group information. If you configure a default group, these users are associated with that default group. For information about configuring AAA rules, see the legacy feature guide.
-
Default username and group—For traffic that does not have an associated user name or group, you can configure an optional default username and group name. These defaults are applied to all users that match a service policy rule for Cloud Web Security.
Authentication Keys
Each ASA must use an authentication key that you obtain from Cloud Web Security. The authentication key lets Cloud Web Security identify the company associated with web requests and ensures that the ASA is associated with a valid customer.
You can use one of two types of authentication keys for your ASA: the company key or the group key.
-
Company authentication key—You can use a company authentication key on multiple ASAs within the same company. This key simply enables the Cloud Web Security service for your ASAs.
-
Group authentication key—A Group authentication key is a special key unique to each ASA that performs two functions:
-
Enables the Cloud Web Security service for one ASA.
-
Identifies all traffic from the ASA so you can create ScanCenter policy per ASA.
-
You generate these keys in ScanCenter (https://scancenter.scansafe.com/portal/admin/login.jsp). For more information, see the Cloud Web Security documentation:
ScanCenter Policy
In ScanCenter, traffic is matched against policy rules in order until a rule is matched. Cloud Web Security then applies the configured action for the rule, allowing or blocking the traffic, or warning the user. With warnings, the user has the option to continue on to the web site.
You configure the URL filtering policies in ScanCenter, not in the ASA.
However, part of the policy is to whom the policy applies. User traffic can match a policy rule in ScanCenter based on group association: a directory group or a custom group. Group information is included in the requests redirected from the ASA, so you need to understand what group information you might get from the ASA.
Directory Groups
Directory groups define the group to which traffic belongs. When using the identity firewall, the group, if present, is included in the client’s HTTP request. If you do not use identity firewall, you can configure a default group for traffic matching an ASA rule for Cloud Web Security inspection.
In ScanCenter, when you configure a directory group in a policy, you must enter the group name exactly.
-
Identity firewall group names are sent in the following format.
domain-name\group-name
Note that on the ASA, the format is domain-name\\group-name. However, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter notation when including the group in the redirected HTTP request.
-
The default group name is sent in the following format:
[domain\]group-name
On the ASA, you need to configure the optional domain name to be followed by 2 backslashes (\\); however, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter notation. For example, if you specify “Cisco\\Boulder1,” the ASA modifies the group name to be “Cisco\Boulder1” with only one backslash (\) when sending the group name to Cloud Web Security.
Custom Groups
Custom groups are defined using one or more of the following criteria:
-
ScanCenter Group authentication key—You can generate a Group authentication key for a custom group. Then, if you identify this group key when you configure the ASA, all traffic from the ASA is tagged with the Group key.
-
Source IP address—You can identify source IP addresses in the custom group. Note that the ASA service policy is based on source IP address, so you might want to configure any IP address-based policy on the ASA instead.
-
Username—You can identify usernames in the custom group.
-
Identity firewall usernames are sent in the following format:
domain-name\username
-
AAA usernames, when using RADIUS or TACACS+, are sent in the following format:
LOCAL\username
-
AAA usernames, when using LDAP, are sent in the following format:
domain-name\username
-
For the default username, it is sent in the following format:
[domain-name\]username
For example, if you configure the default username to be “Guest,” then the ASA sends “Guest.” If you configure the default username to be “Cisco\Guest,” then the ASA sends “Cisco\Guest.”
-
How Groups and the Authentication Key Interoperate
Unless you need the per-ASA policy that a custom group plus group key provides, you will likely use a company key. Note that not all custom groups are associated with a group key. You can use non-keyed custom groups to identify IP addresses or usernames, and use them in your policy along with rules that use directory groups.
Even if you do want per-ASA policy and are using a group key, you can also use the matching capability provided by directory groups and non-keyed custom groups. In this case, you might want an ASA-based policy, with some exceptions based on group membership, IP address, or username. For example, if you want to exempt users in the America\Management group across all ASAs:
-
Add a directory group for America\Management.
-
Add an exempt rule for this group.
-
Add rules for each custom group plus group key after the exempt rule to apply policy per-ASA.
-
Traffic from users in America\Management will match the exempt rule, while all other traffic will match the rule for the ASA from which it originated.
Many combinations of keys, groups, and policy rules are possible.
Failover from Primary to Backup Proxy Server
When you subscribe to the Cisco Cloud Web Security service, you are assigned a primary Cloud Web Security proxy server and backup proxy server.
If any client is unable to reach the primary server, then the ASA starts polling the tower to determine availability. (If there is no client activity, the ASA polls every 15 minutes.) If the proxy server is unavailable after a configured number of retries (the default is 5; this setting is configurable), the server is declared unreachable, and the backup proxy server becomes active. The ASA determines availability based on the server's ability to complete the TCP three-way handshake.
After a failover to the backup server, the ASA continues to poll the primary server. If the primary server becomes reachable, then the ASA returns to using the primary server.
You can further refine failover by checking the health of the Cloud Web Security application. In some cases, the server can complete the TCP three-way handshake, yet the Cloud Web Security application on the server is not functioning correctly. If you enable application health checking, the system can fail over to the backup server even if the three-way handshake completes, if the application itself does not respond. This provides a more reliable failover setup.
Health checking involves sending a GET request with a test URL to the Cloud Web Security application. Failure to respond within the configured timeout and retry limits marks the server as down, and the system initiates failover. The backup server is also tested to ensure that it is functioning correctly before it is marked as the active server. After failover, the application on the primary server is retested every 30 seconds until it comes back online and can be marked the active server again.
You can choose how the ASA handles web traffic when it cannot reach either the primary or backup Cloud Web Security proxy server. It can block or allow all web traffic. By default, it blocks web traffic.
Feedback