The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Cloud Web Security provides web security and web filtering services through the Software-as-a-Service (SaaS) model. Enterprises with the ASA in their network can use Cloud Web Security services without having to install additional hardware.
When Cloud Web Security is enabled on the ASA, the ASA transparently redirects selected HTTP and HTTPS traffic to the Cloud Web Security proxy servers. 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 (IDFW) and AAA rules. The ASA encrypts and includes the user credentials (including usernames and/or 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/or 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.
Note This feature is also called “ScanSafe,” so the ScanSafe name appears in some commands.
This chapter includes the following sections:
This section includes the following topics:
When an end user sends an HTTP or HTTPS request, the ASA receives it and optionally retrieves the user and/or group information. If the traffic matches an ASA service policy rule for Cloud Web Security, then the ASA redirects the request to the Cloud Web Security proxy servers. The ASA acts as an intermediary between the end user and the Cloud Web Security proxy server by redirecting the connection to the proxy server. The ASA changes the destination IP address and port in the client requests and adds Cloud Web Security-specific HTTP headers and then sends the modified request to the Cloud Web Security proxy server. The Cloud Web Security HTTP headers include various kinds of information, including the username and user group (if available).
User identity can be used 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.
The ASA supports the following methods of determining the identity of a user, or of providing a default identity:
For information about configuring IDFW, see the general operations configuration guide.
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 valid customer.
You can use one of two types of authentication keys for your ASA: the company key or the group key.
A Company authentication key can be used on multiple ASAs within the same company. This key simply enables the Cloud Web Security service for your ASAs. The administrator generates this key in ScanCenter ( https://scancenter.scansafe.com/portal/admin/login.jsp); you have the opportunity to e-mail the key for later use. You cannot look up this key later in ScanCenter; only the last 4 digits are shown in ScanCenter. For more information, see the Cloud Web Security documentation: http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html.
A Group authentication key is a special key unique to each ASA that performs two functions:
For information about using the Group authentication key for policy, see ScanCenter Policy).
The administrator generates this key in ScanCenter ( https://scancenter.scansafe.com/portal/admin/login.jsp); you have the opportunity to e-mail the key for later use. You cannot look up this key later in ScanCenter; only the last 4 digits are shown in ScanCenter. For more information, see the Cloud Web Security documentation: http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html.
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. User traffic can match a policy rule in ScanCenter based on group association: a directory group or a custom group.
Directory groups define the group to which traffic belongs. The group, if present, is included in the HTTP header of the client request. The ASA includes the group in the HTTP header when you configure IDFW. If you do not use IDFW, you can configure a default group for traffic matching an ASA rule for Cloud Web Security inspection.
When you configure a directory group, you must enter the group name exactly.
When the ASA learns the IDFW group name, the format on the ASA is domain-name \\ group-name. However, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter notation.
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 are defined using one or more of the following criteria:
– IDFW usernames are sent in the following format:
– AAA usernames, when using RADIUS or TACACS+, are sent in the following format:
– AAA usernames, when using LDAP, are sent in the following format:
– For the default username, it is sent in the following format:
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.”
Unless you need the per-ASA policy that a custom group+group key provides, you will likely use a company key. Note that not all custom groups are associated with a group key. Non-keyed custom groups can be used to identify IP addresses or usernames, and can be used 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:
1. Add a directory group for America\Management.
2. Add an exempt rule for this group.
3. Add rules for each custom group+group key after the exempt rule to apply policy per-ASA.
4. 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.
After applying the configured policies, Cloud Web Security either blocks, allows, or sends a warning about the user request:
You can also 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.
If you use AAA rules or IDFW, you can configure the ASA so that web traffic from specific users or groups that otherwise match the service policy rule is not redirected to the Cloud Web Security proxy server for scanning. When you bypass Cloud Web Security scanning, the ASA retrieves the content directly from the originally requested web server without contacting the proxy server. When it receives the response from the web server, it sends the data to the client. This process is called “whitelisting” traffic.
Although you can achieve the same results of exempting traffic based on user or group when you configure the class of traffic using ACLs to send to Cloud Web Security, you might find it more straightforward to use a whitelist instead. Note that the whitelist feature is only based on user and group, not on IP address.
Cloud Web Security currently supports only IPv4 addresses. If you use IPv6 internally, NAT 64 must be performed for any IPv6 flows that need to be sent to Cloud Web Security.
The following table shows the class map traffic that is supported by Cloud Web Security redirection:
|
|
---|---|
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 miniutes.) 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.
If a client or the ASA can reach the server at least twice consecutively before the retry count is reached, the polling stops and the tower is determined to be reachable.
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.
|
|
---|---|
Strong Encryption (3DES/AES) License to encrypt traffic between the ASA and the Cloud Web Security server. |
On the Cloud Web Security side, you must purchase a Cisco Cloud Web Security license and identify the number of users that the ASA handles. Then log into ScanCenter, and generate your authentication keys.
(Optional) User Authentication Prerequisites
To send user identity information to Cloud Web Security, configure one of the following on the ASA:
(Optional) Fully Qualified Domain Name Prerequisites
If you use FQDNs in ACLs for your service policy rule, or for the Cloud Web Security server, you must configure a DNS server for the ASA according to the general operations configuration guide.
Supported in single and multiple context modes.
In multiple context mode, the server configuration is allowed only in the system, and the service policy rule configuration is allowed only in the security contexts.
Each context can have its own authentication key, if desired.
Supported in routed firewall mode only. Does not support transparent firewall mode.
Does not support IPv6. See IPv4 and IPv6 Support.
The public key is embedded in the ASA software, so there is no need for you to configure it.
|
|
|
---|---|---|
|
||
server primary { ip ip_address | fqdn fqdn} [ port port ] |
Configures the fully qualified domain name or IP address of the primary Cloud Web Security proxy server. By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not change this value unless directed to do so. |
|
server backup { ip ip_address | fqdn fqdn} [ port port ] hostname(cfg-scansafe)# server backup fqdn server.example.com |
(Optional) Configures the fully qualified domain name or IP address of the backup Cloud Web Security proxy server. By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not change this value unless directed to do so. |
|
|
(Optional) Enters the value for the number of consecutive polling failures to the Cloud Web Security proxy server before determining the server is unreachable. Polls are performed every 30 seconds. Valid values are from 2 to 100, and the default is 5. |
|
|
Configures the authentication key that the ASA sends to the Cloud Web Security proxy servers to indicate from which organization the request comes. The authentication key is a 16-byte hexidecimal number. See Authentication Keys. |
The following example configures a primary and backup server:
In multiple context mode, you must allow Cloud Web Security per context. For more information, see the general operations configuration guide.
Note You must configure a route pointing to the Scansafe towers in both; the admin context and the specific context. This ensures that the Scansafe tower does not become unreachable in the Active/Active failover scenario.
The following sample configuration enables Cloud Web Security in context one with the default license and in context two with the license key override:
See “Service Policy Using the Modular Policy Framework,” for more information about service policy rules.
(Optional) If you need to use a whitelist to exempt some traffic from being sent to Cloud Web Security, first create the whitelist according to the (Optional) Configuring Whitelisted Traffic so you can refer to the whitelist in your service policy rule.
|
|
|
---|---|---|
policy-map type inspect scansafe name1 hostname(config)# policy-map type inspect scansafe cws_inspect_pmap1 |
Creates an inspection policy map so you can configure essential parameters for the rule and also optionally identify the whitelist. An inspection policy map is required for each class of traffic that you want to send to Cloud Web Security. The policy_map_name argument can be up to 40 characters in length. |
|
|
Parameters lets you configure the protocol and the default user or group. You enter parameters configuration mode. |
|
|
You can only specify one service type for this inspection policy map, either http or https. |
|
default { [user username ] [ group groupname ]} |
Specifies that if the ASA cannot determine the identity of the user coming into the ASA, then the default user and/or group is included in the HTTP header. |
|
|
Identifies the whitelist class map name that you created in the (Optional) Configuring Whitelisted Traffic. |
|
|
||
policy-map type inspect scansafe name2 default { [user user ] [ group group ]} hostname(config)# policy-map type inspect scansafe cws_inspect_pmap2 hostname(config-pmap)# parameters hostname(config-pmap-p)# default group2 default_group2 |
Repeat Step 1 to Step 6 to create a separate class map for HTTPS traffic (for example). You can create an inspection class map for each class of traffic you want to send to Cloud Web Security. You can reuse an inspection class map for multiple classes of traffic if desired. |
|
access-list access_list_name [ line line_number ] extended { deny | permit } tcp [ user_argument ] [ security_group_argument ] source_address_argument [ port_argument ] dest_address_argument [ port_argument ] hostname(config)# object network cisco1 hostname(config-object-network)# fqdn www.cisco.com hostname(config)# object network cisco2 hostname(config-object-network)# fqdn tools.cisco.com hostname(config)# access-list SCANSAFE_HTTP extended deny tcp any4 object cisco1 eq 80 hostname(config)# access-list SCANSAFE_HTTP extended deny tcp any4 object cisco2 eq 80 hostname(config)# access-list SCANSAFE_HTTP extended permit tcp any4 any4 eq 80 |
Identifies the class of traffic you want to send to Cloud Web Security. Create an ACL consisting of one or more access control entries (ACEs). For detailed information about ACLs, see the general operations configuration guide. Cloud Web Security only operates on HTTP and HTTPS traffic. Each type of traffic is treated separately by the ASA. Therefore, you need to create HTTP-only ACLs and HTTPS-only ACLs. Create as many ACLs as needed for your policy. A permit ACE sends matching traffic to Cloud Web Security. A deny ACE exempts traffic from the service policy rule, so it is not sent to Cloud Web Security. When creating your ACLs, consider how you can match appropriate traffic that is destined for the Internet, but not match traffic that is destined for other internal networks. For example, to prevent inside traffic from being sent to Cloud Web Security when the destination is an internal server on the DMZ, be sure to add a deny ACE to the ACL that exempts traffic to the DMZ. FQDN network objects might be useful in exempting traffic to specific servers. The user_argument lets you specify the IDFW username or group, either inline or by referring to an object group. The security_group_argument lets you specify the TrustSec security group, either inline or by referring to an object group. Note that although you can match traffic to send to Cloud Web Security by security group, the ASA does not send security group information to Cloud Web Security in the HTTP header; Cloud Web Security cannot create policy based on the security group. |
|
|
Creates a class map to identify the traffic for which you want to enable Cloud Web Security filtering. |
|
|
Specifies an ACL created in Step 8. Although you can use other match statements for this rule, we recommend using the match access-list command because it is the most versatile for identifying HTTP or HTTPS-only traffic. See Identifying Traffic (Layer 3/4 Class Maps) for more information. |
|
|
(Optional) Creates an additional class map, for example for HTTPS traffic. You can create as many classes as needed for this service policy rule. |
|
|
Adds or edits a policy map that sets the actions to take with the class map traffic. The policy map in the default global policy is called global_policy. You can edit this policy, or create a new one. You can only apply one policy to each interface or globally. |
|
|
Identifies the class map created in Step 9. |
|
inspect scansafe scansafe_policy_name1 [ fail-open | fail-close ] hostname(config-pmap-c)# inspect scansafe cws_inspect_pmap1 fail-open |
Enables Cloud Web Security inspection on the traffic in this class. Specify the inspection class map name that you created in Step 1. Specify fail-open to allow traffic to pass through the ASA if the Cloud Web Security servers are unavailable. Specify fail-close to drop all traffic if the Cloud Web Security servers are unavailable. fail-close is the default. |
|
inspect scansafe scansafe_policy_name2 [ fail-open | fail-close ] hostname(config-pmap)# class cws_class2 hostname(config-pmap-c)# inspect scansafe cws_inspect_pmap2 fail-open |
(Optional) Identifies a second class map that you created in Step 11, and enables Cloud Web Security inspection for it. |
|
service-policy policymap_name {global | interface interface_name } |
Activates the policy map on one or more interfaces. global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface. See Applying Actions to an Interface (Service Policy) for more information. |
The following example configures two classes: one for HTTP and one for HTTPS. Each ACL exempts traffic to www.cisco.com and to tools.cisco.com, and to the DMZ network, for both HTTP and HTTPS. All other traffic is sent to Cloud Web Security, except for traffic from several whitelisted users and groups. The policy is then applied to the inside interface.
If you use user authentication, you can exempt some traffic from being filtered by Cloud Web Security based on the username and/or groupname. When you configure your Cloud Web Security service policy rule, you can reference the whitelisting inspection class map. Both IDFW and AAA user credentials can be used with this feature.
Although you can achieve the same results of exempting traffic based on user or group when you configure the service policy rule, you might find it more straightforward to use a whitelist instead. Note that the whitelist feature is only based on user and group, not on IP address.
The following example whitelists the same users and groups for the HTTP and HTTPS inspection policy maps:
When you use IDFW, the ASA only downloads user identity information from the AD server for users and groups included in active ACLs; the ACL must be used in a feature such as an access rule, AAA rule, service policy rule, or other feature to be considered active. Because Cloud Web Security can base its policy on user identity, you may need to download groups that are not part of an active ACL to get full IDFW coverage for all your users. For example, although you can configure your Cloud Web Security service policy rule to use an ACL with users and groups, thus activating any relevant groups, it is not required; you could use an ACL based entirely on IP addresses.The user identity monitor feature lets you download group information directly from the AD agent.
The ASA can only monitor a maximum of 512 groups, including those configured for the user identity monitor and those monitored through active ACLs.
After you configure the ASA service policy rules, launch the ScanCenter Portal to configure Web content scanning, filtering, malware protection services, and reports.
Go to: https://scancenter.scansafe.com/portal/admin/login.jsp.
For more information, see the Cisco ScanSafe Cloud Web Security Configuration Guides:
http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html
The show scansafe server command shows whether or not the Cloud Web Security proxy servers are reachable:
The show scansafe statistics command shows information about Cloud Web Security activity, such as the number of connections redirected to the proxy server, the number of current connections being redirected, and the number of whitelisted connections:
The show service policy inspect scansafe command shows the number of connections that are redirected or whitelisted by a particular policy:
The following example shows a complete configuration for Cisco Cloud Web Security:
We recommend that you split the traffic by creating separate HTTP and HTTPS class maps so that you know how many HTTP and HTTPS packets have gone through.
Then, if you need to troubleshoot you can run debug commands to distinguish how many packets have traversed each class map and find out if you are pushing through more HTTP or HTTPS traffic:
Configure Inspection Policy Maps
Configure Cloud Web Security on the ASA
The following example enables Cloud Web Security in context one with the default license and in context two with the authentication key override:
Configure what access-list traffic should be sent to Cloud Web Security:
To configure the whitelist to ensure user1 is in this access-list range to bypass Cloud Web Security:
To attach class-maps to the Cloud Web Security Policy map:
After creating this inspect policy, attach it to the policy map to be assigned to the service group:
Then attach the policy map to a service-policy to make it in effect globally or by ASA interface:
This section contains various example configurations for directory integration.
The following example shows how to configure the Active Directory server on your ASA using LDAP:
The following example shows how to configure the Active Directory Agent on your ASA using RADIUS:
The following example shows how to create the ASA as a client on the Active Directory agent server:
The following example shows how to create a link between the Active Directory Agent and all DCs for which you want to monitor logon/logoff events:
Running the last command should show the status as “UP.”
For the AD_Agent to monitor logon/logoff events, you need to ensure that these are logged on ALL DCs that are actively being monitored. To do this, choose:
Start > Administrative Tools > Domain Controller Security Policy
Local policies > Audit Policy > Audit account logon events (success and failure)
The following example shows how to configure the test Active Directory Agent so that it can communicate with the ASA:
See also the following command: show user-identity ad-agent.
The following example shows how to configure the identity options on the ASA:
The following example shows how to configure the user identity options that send user credentials to the ASA and enable granular user reporting from the proxy server:
If you are using more than one domain, then enter the following command:
The following example shows how to configure Active Directory groups to be monitored:
The following command updates the specified import user group database by querying the Active Directory server immediately without waiting for the expiration of poll-import-user-group-timer:
The following example shows how to manually start the download of the database from the Active Directory Agent if you think the user database is out of sync with Active Directory:
The following example shows how to show the Active users:
There are two download modes with Identify Firewall: Full download and On-demand.
The following example shows how to configure Cloud Web Security with Identity Firewall on the ASA:
|
|
---|---|
http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html |
Table 21-1 lists each feature change and the platform release in which it was implemented.