Copyright Page

Chapter 1. Cisco Cloud Web Security

Finding Feature Information

Prerequisites for Cisco Cloud Web Security

Restrictions for Cisco Cloud Web Security

Information About Cisco Cloud Web Security

Overview of Cisco Cloud Web Security

Whitelists

Cisco Cloud Web Security Headers

Cloud Web Security Tower Telemetry

Default User-Group Support for Authentication

How to Configure Cisco Cloud Web Security

Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

Configuring Whitelisting

Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Configuring Cisco Cloud Web Security

Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

Enabling Out-of-Band Telemetry

Configuration Examples for Cisco Cloud Web Security

Example: Configuring Whitelisting in Cisco IOS Release 15.4(2)T

Example: Configuring Whitelisting

Example: Configuring Cisco Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Example: Configuring Cisco Cloud Web Security

Example: Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

Example: Enabling Out-of-Band Telemetry

Additional References for Cisco Cloud Web Security

Feature Information for Cisco Cloud Web Security

Chapter 2. VRF-Aware Cloud Web Security

Finding Feature Information

Restrictions for VRF-Aware Cloud Web Security

Information About VRF-Aware Cloud Web Security

VRF-Aware Cloud Web Security Overview

VRF-Aware Cloud Web Security Scenarios

How to Configure VRF-Aware Cloud Web Security

Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

Configuring a Cloud Web Security Tower

Configuring VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Configuring VRF-Aware Cloud Web Security

Configuration Examples for VRF-Aware Cloud Web Security

Example: Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

Example: Configuring a Cloud Web Security Tower

Example: VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Example: Configuring VRF-Aware Cloud Web Security

Additional References for VRF-Aware Cloud Web Security

Feature Information for VRF-Aware Cloud Web Security

Chapter 3. Browser-Based Authentication Bypass

Finding Feature Information

Prerequisites for Browser-Based Authentication Bypass

Information About Browser-Based Authentication Bypass

Browser-Based Authentication Bypass Overview

How to Configure Browser-Based Authentication Bypass

Configuring Browser-Based Authentication Bypass

Verifying Browser-Based Authentication Bypass

Configuration Examples for Browser-Based Authentication Bypass

Example: Configuring Browser-Based Authentication Bypass

Additional References for Browser-Based Authentication Bypass

Feature Information for Browser-Based Authentication Bypass

Chapter 4. LDAP Server State

Finding Feature Information

Prerequisites for LDAP Server State

Restrictions for LDAP Server State

Information About LDAP Server State

Overview of LDAP Server State

How to Configure LDAP Server State

Configuring LDAP Server State

Configuration Examples for LDAP Server State

Example: Configuring LDAP Server State

Additional References for LDAP Server State

Feature Information for LDAP Server State

Chapter 5. Cisco Integrated Services Routers Generation 2 with Cisco Cloud Web Security Solution

Information About Cisco Integrated Services Routers Generation 2 and Cisco Cloud Web Security Solution

Overview of Cisco ISR G2 and Cloud Web Security Solution

Benefits of Using the Cisco ISR G2 with Cloud Web Security

Cloud Web Security Licensing

Cloud Web Security Supported Platforms

How Cloud Web Security Works with an ISR G2

Communication Between Cloud Web Security, ISR G2, and Clients

Cisco Cloud Web Security Headers

Bypassing Cloud Web Security Scanning

Working with Multiple ISRs

Configuring Cloud Web Security on Integrated Services Routers Generation 2

Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Configuring Cisco Cloud Web Security

Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

Configuring Whitelisting

Whitelisting HTTP Traffic

Example: Configuring Whitelisting

Configuring Default User Groups

Cloud Web Security Authentication Types

NTLM or HTTP Basic Authentication

Configuring NTLM or HTTP Basic Authentication

Transparent Authentication with NTLM

Bypassing Authentication

Network/IP-Based Authentication Bypass

Browser-Based Authentication Bypass

Authentication Failure

Session States and Time Between Sessions

Domain and Non-Domain Users

Acceptable Use Policy Aggrement

Enabling Nested LDAP for Cloud Web Security

Configuring the Cisco Cloud Web Security Portal

Cloud Web Security Logging Messages

Sample Configuration of Cloud Web Security on ISR G2s

Cloud Web Security Troubleshooting Tips

Packet Drops with Small MTU Value on Interfaces

Cloud Web Security Tower is Located in a Different Location

Host and User Agent-Based Whitelisting Inconsistencies with Asymmetric Routing

Page Loads Differently After Cloud Web Security Warning Page

Virtual Hostname Resolves to Open DNS Server

NTLM Authentication and Browser-Based Authentication Bypass Supports only GET Requests

Clearing the Cache Results in Credential Requests

Multiple NTLM Authentication Requests

Root Bind in LDAP Configuration

Protecting ISR G2s from Layer 4 Forwarding Attacks

ACL Logging not Supported with Whitelisting

Cloud Web Security and Multipath TCP

Additional References for Cisco Cloud Web Security and Integrated Services Routers Solution

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Chapter 1. Cisco Cloud Web Security

The Cisco Cloud Web Security feature provides content scanning of HTTP and secure HTTP (HTTPS) traffic and malware protection services to web traffic. The feature helps devices transparently redirect HTTP and HTTPS traffic to the Cisco Web Security cloud.

This module describes the Cisco Cloud Web Security feature and how to configure it. This module also describes the Cloud Web Security Tower Telemetry and Default User-Group Support for Authentication features.

- Finding Feature Information

- Prerequisites for Cisco Cloud Web Security

- Restrictions for Cisco Cloud Web Security

- Information About Cisco Cloud Web Security

- How to Configure Cisco Cloud Web Security

- Configuration Examples for Cisco Cloud Web Security

- Additional References for Cisco Cloud Web Security

- Feature Information for Cisco Cloud Web Security

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Cisco Cloud Web Security

Ensure that both Wide Area Application Services (WAAS) and the content scanning feature are not applied on the same TCP session in the following scenarios:

- When you enable content scanning on an interface that has WAAS configured.

- When the network connection from a branch office to the Internet is over a Multiprotocol Label Switching (MPLS) cloud.

Restrictions for Cisco Cloud Web Security

- Device-on-a-stick configuration is not supported.

- If Network Address Translation (NAT) is not configured on Cisco Cloud Web Security devices, only 32,000 translation sessions are supported.

- If you configure a host whitelist rule, the sender of an HTTP packet can spoof the Host field of the HTTP header with a whitelisted hostname or whitelist HTTP packets even if the destination HTTP server is not whitelisted. Content scan whitelisting does not verify whether the Host field of an HTTP request matches the destination IP address. Therefore, when providing restricted access to nonauthorized servers, use access control lists (ACLs), which are more effective than whitelists and allow entry to only configured IP addresses.

- If you configure a user agent whitelist rule, the sender of an HTTP packet can spoof the User-Agent field of the HTTP header and the spoofing can result in users accessing a host that is not whitelisted. By using the User-Agent field of the HTTP header, the sender of an HTTP packet can add any HTTP connection request to a whitelist, thus providing unauthorized users access to restricted or nonauthorized servers. Therefore, when providing restricted access to nonauthorized servers, use ACLs, which are more effective than whitelists and allow entry to only configured IP addresses.

- Loadsharing between Cisco Cloud Web Security towers is not supported.

- The web traffic that comes into a branch office is not redirected to Cisco Cloud Web Security for content scanning. Content scanning is configured on the Internet-facing WAN interface, protecting the web traffic that goes out of the branch office.

- When the network connection from a branch office to the Internet is over a Multiprotocol Label Switching (MPLS) cloud, the content scanning feature will not work without split tunneling.

- When Wide-Area Application Services (WAAS) is enabled, the content scanning feature will not work in branch deployments without split tunneling.

Information About Cisco Cloud Web Security

- Overview of Cisco Cloud Web Security

- Whitelists

- Cisco Cloud Web Security Headers

- Cloud Web Security Tower Telemetry

- Default User-Group Support for Authentication

Overview of Cisco Cloud Web Security

The Cisco Cloud Web Security feature provides content scanning of HTTP and secure HTTP (HTTPS) traffic and malware protection service to web traffic. This feature helps devices to transparently redirect HTTP and HTTPS traffic to the cloud. Cloud refers to servers in the Cisco Cloud Web Security data center that are accessible over the public Internet and provide security as a service. Cisco Cloud Web Security servers scan the web traffic content and either allow or block the traffic based on the configured policies and thus protect clients from malware. Servers use credentials such as private IP addresses, usernames, and user groups to identify and authenticate users and redirect the traffic for content scanning.

This feature enables branch offices to intelligently redirect web traffic to the cloud to enforce security and acceptable use of policies over the web traffic. A device authenticates and identifies users who make web traffic requests by using configured authentication and authorization methods such as user credentials (usernames and user groups) available in the traffic that the device redirects to Cisco Cloud Web Security. Cisco Cloud Web Security uses the user credentials to determine the policies that need to be applied to specific users and for user-based reporting. Cisco Cloud Web Security supports all authentication methods such as HTTP Basic, Web Authorization Proxy, and Windows NT LAN Manager (NTLM) (passive or explicit).

A device that cannot determine a client’s credentials uses a default user group name to identify all clients who are connected to a specific interface on that device. Prior to CSCty48221, the user group that was configured using the user-group command in parameter-map type inspect configuration mode had precedence over any default user group that was configured using the user-group default command in interface configuration mode. With the fix for CSCty48221, a device selects a user group in the following order:

- Authentication methods.

- User group configured using the user-group default command on an interface.

- User group configured using the user-group command in parameter-map type inspect configuration mode. Configure the parameter-map type content-scan global command before configuring the user-group command.

You can configure a device in such a way that the approved web traffic does not get scanned by Cisco Cloud Web Security. Instead, the traffic goes directly to the originally requested web server. Clients are any devices that connect to a device, either directly or indirectly. When a client sends an HTTP or HTTPS request, the device receives the request, authenticates the user, and retrieves the group name from the authentication server. The device identifies the user and then consults the whitelist database to determine whether to send the HTTP or HTTPS client response to Cisco Cloud Web Security.

You can configure primary and backup Cisco Cloud Web Security proxy servers. The device regularly polls each of these proxy servers to check their availability.

Whitelists

A whitelist is an approved list of entities that are provided a particular privilege, service, mobility, access, or recognition. Whitelisting means to grant access. You can configure a device in such a way that the approved web traffic does not get redirected to Cisco Cloud Web Security for scanning. When you bypass Cisco Cloud Web Security content scanning, the device retrieves the content directly from the originally requested web server without contacting Cisco Cloud Web Security. Once the device receives a response from the web server, the device sends the data to the client. This process is called whitelisting of web traffic.

You can bypass content scanning based on the following client web traffic properties:

- IP address—You can bypass content scanning for web traffic that matches a configured numbered or named access control list (ACL). Use this method for traffic that is sent to trusted sites, such as intranet servers.

- HTTP-based header fields—You can bypass scanning for web traffic that matches a configured HTTP header field. You can match the host and user agent header fields. Use this method for user agents that do not function properly when scanned or to disable the scanning of traffic that is intended for trusted hosts, such as third-party partners.

Cisco Cloud Web Security Headers

A device that forwards web traffic to Cisco Cloud Web Security proxy servers includes additional HTTP headers in each HTTP and HTTPS request. Cisco Cloud Web Security uses these headers to obtain information about customer deployments, including information about the user who had originally made the client request and the device that sent the request. For security purposes, the information in the headers is encrypted and then hexadecimal encoded.

Cisco Cloud Web Security headers provide both asymmetric cryptography and symmetric cryptography by using industry standard algorithms. Asymmetric encryption is done by using the RSA/ECB/PKCS1Padding algorithm that uses key pairs of 512 bits. Symmetric encryption is done by using the triple “DESede” algorithm with a randomly generated triple Data Encryption Standard (DES) key of 168 bits.

The ISR adds the following CWS HTTP headers:

- X-ScanSafe—This contains a session key that is encrypted using a CWS public key (embedded in the ISR operating system).

- X-ScanSafe-Data—This contains the data CWS needs. It is encrypted with the session key from the X-CWS header.

For example, the headers in a message might look like the following text:

- X-ScanSafe: 35A9C7655CF259C175259A9B980A8DFBF5AC934720BE9374D344F7E584780ECDB9236FF90DF562A79DC4C75 4C3782E7C3D38C76566F0377D5689E25BD62FC5F

- X-ScanSafe-Data: 8D57AEE5D76432ACAB184AA807D94A7392986FA0D3ED9BEB

Cloud Web Security Tower Telemetry

The Cloud Web Security Tower Telemetry feature:

- Tracks the state of the content scan and the state of the device on which the Cisco Cloud Web Security feature is configured.

- Logs debug messages when delays are encountered while accessing a website.

- Identifies the source of performance issues.

Telemetry is an automated communications process in which measurements are made and data that is collected at remote sites is transmitted to receiving equipment for monitoring.

The device on which the Cisco Cloud Web Security feature is configured is monitored, and data is generated periodically. Because most of these devices do not have a large amount of memory or a secondary storage, the generated data is exported to an external device. For the Cisco Cloud Web Security feature, the generated data is stored in the Cloud Web Security tower. The device connects to a URL hosted by the Cloud Web Security tower by using the HTTP POST method to periodically send telemetry data. This method is called out-of-band telemetry.

Because the Cloud Web Security tower does not have information about all whitelisted traffic, a connector (a persistent, out-of-band secure channel between the device and the Cloud Web Security tower) periodically sends all exception rules configured on the device to the tower. Just like telemetry, the connector makes a POST request and pushes all exception rules to a URL. This URL is separate from the telemetry URL.

The Cloud Web Security tower monitors the TCP session between the client browser and the tower and the TCP session between the tower and the device. The tower also collects debug information at HTTP and TCP levels. The tower also collects information and statistics about the parent HTTP session and all subordinate sessions created by the main URL. The TCP session statistics include retransmission count, window update count, window size, duplicate acknowledgments (ACKs), and time stamps of segment arrival and departure.

Default User-Group Support for Authentication

The Default User-Group Support for Authentication feature redirects unauthorized web traffic to the Cloud Web Security server, also called the tower, for content scanning. Prior to the introduction of this feature, any unauthenticated traffic that fails all login attempts to the Cloud Web Security tower was dropped by the IP admission module and the session was moved to the service-deny state.

For the Default User-Group Support for Authentication feature, the Windows NT LAN Manager (NTLM) acts as the authentication module and updates the user-group database (IP and user-group bindings) with the user-group string that is received as authorization data from the authentication, authorization, and accounting (AAA) or Lightweight Directory Access Protocol (LDAP) servers. Port access control lists (PACLs) perform access control of the web traffic. If no PACL is configured on a port, unauthenticated user traffic is allowed. Even if a user fails the NTLM authentication, the user can be given default access based on your PACL configuration. You can configure a PACL to permit unauthorized users access to the Cloud Web Security tower by using the permit command.

The various modules interact with each other to enable the default user-group support, as follows:

- ACL module—Controls port access based on the configured policy.

- Content-Scan—Forwards web traffic from clients to the Cloud Web Security tower for content scanning.

- IP admission or NTLM module—Intercepts the traffic destined to port 80 and port 443 and authenticates users with the Microsoft Active Directory server.

- User-Group database—Maintains the IP and user-group bindings that are received from the LDAP server as part of the authorization data. This database is updated by the IP admission module after the authentication.

How to Configure Cisco Cloud Web Security

In Cisco IOS Release 15.4(2)T, some of the Cloud Web Security commands were replaced by new commands. Releases prior to the Cisco IOS Release 15.4(2)T still use the old commands.

This section consists of tasks that use the commands existing prior to Cisco IOS Release 15.4(2)T and a corresponding task that uses the commands introduced or modified in the Cisco IOS Release 15.4(2)T.

- Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring Whitelisting

- Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring Cisco Cloud Web Security

- Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

- Enabling Out-of-Band Telemetry

Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

User and user-group-based whitelisting is initially done during a TCP synchronization (SYN). No content-scan sessions are created when a session is whitelisted based on an username or user group. The order of whitelisting is: acl, user, user group, header user-agent, header host.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    cws whitelisting

4.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

5.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

6.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

7.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cws whitelisting

Example:

Device(config)# cws whitelisting

Enables whitelisting of incoming traffic and enters Cloud Web Security whitelisting configuration mode.

Step 4

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist acl name whitelistedSubnets

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 5

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist header host regex whitelistedPatterns

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 6

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist user regex whitelistedUsers

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 7

end

Example:

Device(config-cws-wl)# end

Exits Cloud Web Security whitelisting configuration mode and returns to privileged EXEC mode.

Configuring Whitelisting

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

User and user-group-based whitelisting is initially done during a TCP synchronization (SYN). No content-scan sessions are created when a session is whitelisted based on an username or user group. The order of whitelisting is: acl, user, user group, header user-agent, header host.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    content-scan whitelisting

4.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

5.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

6.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

7.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

content-scan whitelisting

Example:

Device(config)# content-scan whitelisting

Enables whitelisting of incoming traffic and enters content-scan whitelisting configuration mode.

Step 4

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist acl name whitelistedSubnets

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 5

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist header host regex whitelistedPatterns

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 6

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist user regex whitelistedUsers

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 7

end

Example:

Device(config-cont-scan-wl)# end

Exits content-scan whitelisting configuration mode and returns to privileged EXEC mode.

Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type cws global

4.    server primary ipv4 ip-address port http port-number https port-number

5.    server secondary ipv4 ip-address port http port-number https port-number

6.    license 7 license-key

7.    source interface type number

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group group-name username username

11.    server on-failure block-all

12.    user-group exclude username

13.    exit

14.    interface type number

15.    cws out

16.    ip virtual-reassembly in

17.    ip virtual-reassembly out

18.    end

19.    show cws

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type cws global

Example:

Device(config)# parameter-map type cws global

Configures a global Cloud Web Security parameter map and enters parameter-map type inspect configuration mode.

Step 4

server primary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server primary ipv4 10.12.34.23 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server secondary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server secondary ipv4 10.21.34.21 port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license 7 license-key

Example:

Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507

Configures an encrypted license key that is sent to Cisco Cloud Web Security for authentication.

Step 7

source interface type number

Example:

Device(config-profile)# source interface fastethernet 0/2

Configures the source interface for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 5

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 3600

Specifies the session inactivity time in seconds.

Step 10

user-group group-name username username

Example:

Device(config-profile)# user-group marketing username superuser

Specifies a default usergroup.

Step 11

server on-failure block-all

Example:

Device(config-profile)# server on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

user-group exclude username

Example:

Device(config-profile)# user-group exclude marketing

Excludes the specified user group.

Step 13

exit

Example:

Device(config-profile)# exit

Exits parameter-map type inspect configuration mode and enters global configuration mode.

Step 14

interface type number

Example:

Device(config)# interface ethernet 0/0

Configures an interface and enters interface configuration mode.

Step 15

cws out

Example:

Device(config-if)# cws out

Configures the egress interface for Cloud Web Security content scanning.

Step 16

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 17

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VFR on the egress.

Step 18

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Step 19

show cws

Example:

Device# show cws

Displays content scanning information.

Example

The following is sample output from the show cws history command:

Device# show cws history 6

Protocol     Source                                                 Destination                                         Bytes                                 URI                                                                 Time
HTTP                     192.168.100.2:1347  209.165.201.4:80    (102:45)               www.google.com            00:01:13
HTTP                     192.168.100.2:1326  209.165.201.6:80    (206:11431)    www.google.com            00:12:55
HTTP                     192.168.100.2:1324  209.165.201.5:80    (206:11449)    www.google.com            00:15:20
HTTP                     192.168.100.2:1318  209.165.201.5:80    (206:11449)    www.google.com            00:17:43
HTTP                     192.168.100.2:1316  209.165.201.4:80    (206:11449)    www.google.com            00:20:04
HTTP                     192.168.100.2:1315  10.254.145.107:80   (575:1547)     alert.scansafe.net  00:21:32

Configuring Cisco Cloud Web Security

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type content-scan global

4.    server scansafe primary ipv4 ip-address port http port-number https port-number

5.    server scansafe secondary ipv4 ip-address port http port-number https port-number

6.    license 7 license-key

7.    source interface type number

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group group-name username username

11.    server scansafe on-failure block-all

12.    user-group exclude username

13.    exit

14.    interface type number

15.    content-scan out

16.    ip virtual-reassembly in

17.    ip virtual-reassembly out

18.    end

19.    show content-scan

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type content-scan global

Example:

Device(config)# parameter-map type content-scan global

Configures a global content-scan parameter map and enters parameter-map type inspect configuration mode.

Step 4

server scansafe primary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server scansafe primary ipv4 10.12.34.23 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server scansafe secondary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server scansafe secondary ipv4 10.21.34.21 port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license 7 license-key

Example:

Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507

Configures an encrypted license key that is sent to Cisco Cloud Web Security for authentication.

Step 7

source interface type number

Example:

Device(config-profile)# source interface fastethernet 0/2

Configures the source interface for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 5

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 3600

Specifies the session inactivity time in seconds.

Step 10

user-group group-name username username

Example:

Device(config-profile)# user-group marketing username superuser

Specifies a default usergroup.

Step 11

server scansafe on-failure block-all

Example:

Device(config-profile)# server scansafe on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

user-group exclude username

Example:

Device(config-profile)# user-group exclude marketing

Excludes the specified user group.

Step 13

exit

Example:

Device(config-profile)# exit

Exits parameter-map type inspect configuration mode and enters global configuration mode.

Step 14

interface type number

Example:

Device(config)# interface ethernet 0/0

Configures an interface and enters interface configuration mode.

Step 15

content-scan out

Example:

Device(config-if)# content-scan out

Configures the egress interface for content scanning.

Step 16

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 17

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VFR on the egress.

Step 18

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Step 19

show content-scan

Example:

Device# show content-scan

Displays content scanning information.

Example

The following is sample output from the show content-scan history command:

Device# show content-scan history 6

Protocol     Source                                                 Destination                                         Bytes                                 URI                                                                 Time
HTTP                     192.168.100.2:1347  209.165.201.4:80    (102:45)               www.google.com            00:01:13
HTTP                     192.168.100.2:1326  209.165.201.6:80    (206:11431)    www.google.com            00:12:55
HTTP                     192.168.100.2:1324  209.165.201.5:80    (206:11449)    www.google.com            00:15:20
HTTP                     192.168.100.2:1318  209.165.201.5:80    (206:11449)    www.google.com            00:17:43
HTTP                     192.168.100.2:1316  209.165.201.4:80    (206:11449)    www.google.com            00:20:04
HTTP                     192.168.100.2:1315  10.254.145.107:80   (575:1547)     alert.scansafe.net  00:21:32

Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type cws global

4.    out-of-band telemetry interval interval

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type cws global

Example:

Device(config)# parameter-map type cws global

Configures a global Cloud Web Security parameter map and enters parameter-map type inspect configuration.

Step 4

out-of-band telemetry interval interval

Example:

Device(config-profile)# out-of-band telemetry interval 60

Enables out-of-band telemetry and content-scan exception rules.

Step 5

end

Example:

Device(config-profile)# end

Exits parameter-map type inspect configuration mode and returns to privileged EXEC mode.

Enabling Out-of-Band Telemetry

Perform this task to enable the storing of content scan data in the Cloud Web Security server:

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type content-scan global

4.    out-of-band telemetry interval interval

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type content-scan global

Example:

Device(config)# parameter-map type content-scan global

Configures a global content-scan parameter map and enters parameter-map type inspect configuration.

Step 4

out-of-band telemetry interval interval

Example:

Device(config-profile)# out-of-band telemetry interval 60

Enables out-of-band telemetry and content-scan exception rules.

Step 5

end

Example:

Device(config-profile)# end

Exits parameter-map type inspect configuration mode and returns to privileged EXEC mode.

Configuration Examples for Cisco Cloud Web Security

- Example: Configuring Whitelisting in Cisco IOS Release 15.4(2)T

- Example: Configuring Whitelisting

- Example: Configuring Cisco Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

- Example: Configuring Cisco Cloud Web Security

- Example: Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

- Example: Enabling Out-of-Band Telemetry

Example: Configuring Whitelisting in Cisco IOS Release 15.4(2)T

Note

This example applies to Cisco IOS Release 15.4(2)T and later releases.

Device# configure terminal
Device(config)# cws whitelisting
Device(config-cws-wl)# whitelist header host regex whitelistedPatterns
Device(config-cws-wl)# whitelist acl name whitelistedSubnets
Device(config-cws-wl)# whitelist user regex whitelistedUsers
Device(config-cws-wl)# whitelist user-group regex whitelistedUserGroups
Device(config-cws-wl)# end

Example: Configuring Whitelisting

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

Device# configure terminal
Device(config)# content-scan whitelisting
Device(config-cont-scan-wl)# whitelist header host regex whitelistedPatterns
Device(config-cont-scan-wl)# whitelist acl name whitelistedSubnets
Device(config-cont-scan-wl)# whitelist user regex whitelistedUsers
Device(config-cont-scan-wl)# whitelist user-group regex whitelistedUserGroups
Device(config-cont-scan-wl)# end

Example: Configuring Cisco Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Note

This example applies to Cisco IOS Release 15.4(2)T and later releases.

In the following example, the Cloud Web Security server IP address is used. The default action in this example is to block all traffic if Cloud Web Security servers are not reachable. This means that if both the primary and secondary Cloud Web Security servers are unreachable, users are not be able to access the Internet.

Device# configure terminal
Device(config)# parameter-map type cws
Device(config-profile)# server primary ipv4 10.12.34.23 port http 8080 https 8080
Device(config-profile)# server secondary ipv4 10.21.34.21 port http 8080 https 8080
Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507
Device(config-profile)# source interface fastethernet 0/2
Device(config-profile)# timeout server 5
Device(config-profile)# timeout session-inactivity 3600
Device(config-profile)# user-group marketing username superuser
Device(config-profile)# server on-failure block-all
Device(config-profile)# user-group exclude marketing
Device(config-profile)# exit
Device(config)# interface ethernet 0/0
Device(config-if)# cws out
Device(config-if)# ip virtual-assembly in
Device(config-if)# ip virtual-assembly out
Device(config-if)# end

In the following example, the Cloud Web Security server name is used instead of the tower IP address. The secure HTTP (HTTPS) port is not specified, which means that all HTTPS traffic will be whitelisted. The default action in this example is to block all traffic if Cloud Web Security servers are not reachable.

Note

Use the tower IP address over the name for faster lookups.

Device# configure terminal
Device(config)# parameter-map type cws
Device(config-profile)# server primary name proxy123.scansafe.net port http 8080
Device(config-profile)# server secondary name proxy456.scansafe.net port http 8080
Device(config-profile)# license 0 AA012345678901234567890123456789
Device(config-profile)# source interface GigabitEthernet 0/0
Device(config-profile)# timeout server 30
Device(config-profile)# user-group ciscogroup username ciscouser
Device(config-profile)# server on-failure block-all
Device(config-profile)# exit

Example: Configuring Cisco Cloud Web Security

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

In the following example, the Cloud Web Security server IP address is used. The default action in this example is to block all traffic if Cloud Web Security servers are not reachable. This means that if both the primary and secondary Cloud Web Security servers are unreachable, users are not be able to access the Internet.

Device# configure terminal
Device(config)# parameter-map type content-scan
Device(config-profile)# server scansafe primary ipv4 10.12.34.23 port http 8080 https 8080
Device(config-profile)# server scansafe secondary ipv4 10.21.34.21 port http 8080 https 8080
Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507
Device(config-profile)# source interface fastethernet 0/2
Device(config-profile)# timeout server 5
Device(config-profile)# timeout session-inactivity 3600
Device(config-profile)# user-group marketing username superuser
Device(config-profile)# server scansafe on-failure block-all
Device(config-profile)# user-group exclude marketing
Device(config-profile)# exit
Device(config)# interface ethernet 0/0
Device(config-if)# content-scan out
Device(config-if)# ip virtual-assembly in
Device(config-if)# ip virtual-assembly out
Device(config-if)# end

Example: Enabling Out-of-Band Telemetry in Cisco IOS Release 15.4(2)T and Later Releases

Note

This example applies to Cisco IOS Release 15.4(2)T and later releases.

Device# configure terminal
Device(config)# parameter-map type cws global
Device(config-profile)# out-of-band telemetry interval 60
Device(config-profile)# end

Example: Enabling Out-of-Band Telemetry

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

Device# configure terminal
Device(config)# parameter-map type content-scan global
Device(config-profile)# out-of-band telemetry interval 60
Device(config-profile)# end

Additional References for Cisco Cloud Web Security

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Firewall commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

Cisco Cloud Web Security solution guide

Cisco ISR Web Security with Cisco ScanSafe Solution Guide

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Cisco Cloud Web Security

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Cisco Cloud Web Security

Feature Name

Releases

Feature Information

Cisco Cloud Web Security

15.2(1)T1

15.2(4)M

15.4(2)T

The Cisco Cloud Web Security feature provides content scanning of HTTP and HTTPS traffic and malware protection services to web traffic. This feature helps a device transparently redirect HTTP and HTTPS traffic to the Cisco Web Security cloud.

The following commands were introduced or modified: clear content-scan, content-scan out, content-scan whitelisting, debug content-scan, ip admission name http-basic, ip admission name method-list, ip admission name ntlm, ip admission name order, ip admission virtual-ip, license (parameter-map), logging (parameter-map), parameter-map type content-scan global, publickey, server scan-safe, show content-scan, show ip admission, source (parameter-map), timeout (parameter-map), user-group (parameter-map), whitelist.
In Cisco IOS Release 15.4(2)T, the following commands were replaced by new commands:

- clear content-scan was replaced by the cws content-scan

- content-scan out was replaced by the cws out

- content-scan whitelisting was replaced by the cws whitelisting

- parameter-map type content-scan global was replaced by the parameter-map type cws global

- server scan-safe was replaced by the server

- show content-scan was replaced by the show cws

Cloud Web Security Tower Telemetry

15.3(3)M

15.4(2)T

The Cloud Web Security Tower Telemetry feature:

- Tracks the state of the content scan and the state of the device on which the Cisco Cloud Web Security feature is configured.

- Logs debug messages when delays are encountered while accessing a website.

- Identifies the source of performance issues.

The following commands were introduced or modified: out-of-band telemetry and test content-scan.

The test content-scan command was replaced by the test cws command in Cisco IOS Release 15.4(2)T.

Default User-Group Support for Authentication

15.3(3)M

The Default User-Group Support for Authentication feature redirects unauthorized web traffic to the Cloud Web Security server for content scanning.

Chapter 2. VRF-Aware Cloud Web Security

The VRF-Aware Cloud Web Security feature adds virtual routing and forwarding (VRF) support to the Cisco Cloud Web Security configuration. VRF instances in IP-based networks enable a device to have multiple instances of the routing table at the same time. Because routing instances are independent of each other, they can use the same IP addresses without any conflict.

This feature describes the VRF-Aware Cloud Web Security feature and explains how to configure it.

- Finding Feature Information

- Restrictions for VRF-Aware Cloud Web Security

- Information About VRF-Aware Cloud Web Security

- How to Configure VRF-Aware Cloud Web Security

- Configuration Examples for VRF-Aware Cloud Web Security

- Additional References for VRF-Aware Cloud Web Security

- Feature Information for VRF-Aware Cloud Web Security

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Restrictions for VRF-Aware Cloud Web Security

- While enabling a virtual routing and forwarding (VRF) instance on a device, configure the content-scan out command only on one interface to ensure that the tower polling mechanism is consistent.

- The VRF-Aware Cloud Web Security feature works only in VRF-Lite scenarios.

- Overlapping IP addresses must be resolved if multiple VRF instances converge into a single VRF.

Information About VRF-Aware Cloud Web Security

- VRF-Aware Cloud Web Security Overview

- VRF-Aware Cloud Web Security Scenarios

VRF-Aware Cloud Web Security Overview

Cisco Cloud Web Security provides content scanning of HTTP and secure HTTP (HTTPS) traffic and malware protection services to web traffic. It also helps devices transparently redirect HTTP and HTTPS traffic to the Cisco Web Security cloud. The VRF-Aware Cloud Web Security feature adds virtual routing and forwarding (VRF) support to Cisco Cloud Web Security.

VRF instances in IP-based networks enable a device to have multiple instances of the routing table at the same time. Because routing instances are independent of each other, they use the same IP addresses without any conflict.

You can use VRFs with or without Multiprotocol Label Switching (MPLS). When VRFs are used without MPLS, it is called VRF-Lite. The VRF-Aware Cloud Web Security feature works only in VRF-Lite scenarios.

During content scan, the egress VRF ID of the interface on which the content-scan out command is configured is used. The VRF ID that is used during communication with the Cloud Web Security tower is same as the VRF ID of the interface on which the content-scan out command is configured. Based on your configuration, include the routes configured in the Cloud Web Security tower in the appropriate VRFs.

The whitelisted traffic flows through the interface on which the VRF that is connected to the Internet is configured. A whitelist is an approved list of entities that are provided a particular privilege, service, mobility, access, or recognition. Whitelisting means to grant access.

VRF-Aware Cloud Web Security Scenarios

This section describes some scenarios in which the VRF-Aware Cloud Web Security is configured:

VRF-Aware Cloud Web Security: Scenario 1

In the illustration above, there are two separate networks, Org1 and Org2. The device provides connectivity to the Internet as a shared service between these organizations. Because each organization has a separate virtual routing and forwarding (VRF) instance, both have their individual routing table entries. The clients on Org1 and Org2 can both have the same IP addresses and still access the internal network of their organization.

Because the Internet VRF is shared, Network Address Translation (NAT) must be configured to distinguish the traffic from both the networks. Also, the respective routes from Org1 and Org2 must be advertised into the Internet VRF and vice versa, for proper routing of traffic. In Scenario 1, you can enable Cisco Cloud Web Security on the VRF-shared Internet. Enabling Cisco Cloud Web Security ensures that the HTTP and secure HTTP (HTTPS) traffic is redirected to the configured Cloud Web Security tower. Traffic is passed to the internal networks of both organizations through whitelisting.

VRF-Aware Cloud Web Security: Scenario 2

In the illustration above, clients belong to a global VRF. The Internet traffic belongs to another VRF, VRF1. Whitelisted traffic also uses VRF1 because the interface that is configured for content scan must be connected to whitelisted sites. When you configure content scan on interfaces, each interface will have a unique VRF.

VRF-Aware Cloud Web Security: Scenario 3

In the illustration above, the client traffic comes into the global VRF. All HTTP and HTTPS traffic is sent to VRF1, and non-HTTP and non-HTTPS traffic is sent to VRF2/global VRF. Content scan redirects the HTTP/HTTPS traffic to the Cloud Web Security tower. The classification of HTTP/HTTPS traffic must be done before content-scan redirection.

How to Configure VRF-Aware Cloud Web Security

In Cisco IOS Release 15.4(2)T, some of the Cloud Web Security commands were replaced by new commands. Releases prior to Cisco IOS Release 15.4(2)T still use the old commands.

This section consists of tasks that use the commands existing prior to Cisco IOS Release 15.4(2)T and a corresponding task that uses the commands introduced or modified in the Cisco IOS Release 15.4(2)T.

- Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring a Cloud Web Security Tower

- Configuring VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring VRF-Aware Cloud Web Security

Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type cws global

4.    server primary ipv4 ipv4-address port http port-number https port-number

5.    server secondary name name port http port-number https port-number

6.    license {0 | 7} authentication-key

7.    source address ipv4 ipv4-address

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group name [username name]

11.    server on-failure {allow-all | block-all}

12.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type cws global

Example:

Device(config)# parameter-map type cws global

Configures a global Cloud Web Security parameter map and enters parameter-map type inspect configuration mode.

Step 4

server primary ipv4 ipv4-address port http port-number https port-number

Example:

Device(config-profile)# server primary ipv4 10.2.2.2 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server secondary name name port http port-number https port-number

Example:

Device(config-profile)# server secondary name example1363.example.net port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license {0 | 7} authentication-key

Example:

Device(config-profile)# license 0 F52409C9DAF22005CF33E64A7BC524C9

Configures an unencrypted license key that is sent to Cisco Cloud Web Security for authentication.

- To configure an encrypted license key, use the 7 keyword and specify an authentication key of 66 hexadecimal characters.

Step 7

source address ipv4 ipv4-address

Example:

Device(config-profile)# source address ipv4 192.168.4.4

Configures the source address for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 20

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 180

Specifies the session inactivity time in seconds.

Step 10

user-group name [username name]

Example:

Device(config-profile)# user-group group1 username user1

Specifies a default user group.

Step 11

server on-failure {allow-all | block-all}

Example:

Device(config-profile)# server on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

end

Example:

Device(config-profile)# end

Exits parameter-map type inspect configuration mode and returns to privileged EXEC mode.

Configuring a Cloud Web Security Tower

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type content-scan global

4.    server scansafe primary ipv4 ipv4-address port http port-number https port-number

5.    server scansafe secondary name name port http port-number https port-number

6.    license {0 | 7} authentication-key

7.    source address ipv4 ipv4-address

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group name [username name]

11.    server scansafe on-failure {allow-all | block-all}

12.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type content-scan global

Example:

Device(config)# parameter-map type content-scan global

Configures a global content-scan parameter map and enters parameter-map type inspect configuration mode.

Step 4

server scansafe primary ipv4 ipv4-address port http port-number https port-number

Example:

Device(config-profile)# server scansafe primary ipv4 10.2.2.2 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server scansafe secondary name name port http port-number https port-number

Example:

Device(config-profile)# server scansafe secondary name example1363.example.net port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license {0 | 7} authentication-key

Example:

Device(config-profile)# license 0 F52409C9DAF22005CF33E64A7BC524C9

Configures an unencrypted license key that is sent to Cisco Cloud Web Security for authentication.

- To configure an encrypted license key, use the 7 keyword and specify an authentication key of 66 hexadecimal characters.

Step 7

source address ipv4 ipv4-address

Example:

Device(config-profile)# source address ipv4 192.168.4.4

Configures the source address for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 20

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 180

Specifies the session inactivity time in seconds.

Step 10

user-group name [username name]

Example:

Device(config-profile)# user-group group1 username user1

Specifies a default user group.

Step 11

server scansafe on-failure {allow-all | block-all}

Example:

Device(config-profile)# server scansafe on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

end

Example:

Device(config-profile)# end

Exits parameter-map type inspect configuration mode and returns to privileged EXEC mode.

Configuring VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip vrf vrf-name

4.    exit

5.    interface type number

6.    ip vrf forwarding name

7.    ip address ip-address mask

8.    cws out

9.    ip virtual-reassembly in

10.    ip virtual-reassembly out

11.    duplex auto

12.    speed auto

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip vrf vrf-name

Example:

Device(config)# ip vrf output

Defines a virtual routing and forwarding (VRF) instance and enters VRF configuration mode.

Step 4

exit

Example:

Device(config-vrf)# exit

Exits VRF configuration mode and enters global configuration mode.

Step 5

interface type number

Example:

Device(config)# interface gigabitethernet 0/0

Configures an interface and enters interface configuration mode.

Step 6

ip vrf forwarding name

Example:

Device(config-if)# ip vrf forwarding output

Associates a VRF instance and configures a VRF forwarding table on an interface.

Step 7

ip address ip-address mask

Example:

Device(config-if)# ip address 192.168.4.4 255.255.255.0

Configures an IP address for an interface.

Step 8

cws out

Example:

Device(config-if)# cws out

Configures the egress interface for Cloud Web Security content scanning.

Step 9

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 10

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VRF on the egress.

Step 11

duplex auto

Example:

Device(config-if)# duplex auto

Enables autonegotiation on an interface.

Step 12

speed auto

Example:

Device(config-if)# speed auto

Configures the speed of an interface.

Step 13

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Configuring VRF-Aware Cloud Web Security

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip vrf vrf-name

4.    exit

5.    interface type number

6.    ip vrf forwarding name

7.    ip address ip-address mask

8.    content-scan out

9.    ip virtual-reassembly in

10.    ip virtual-reassembly out

11.    duplex auto

12.    speed auto

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip vrf vrf-name

Example:

Device(config)# ip vrf output

Defines a virtual routing and forwarding (VRF) instance and enters VRF configuration mode.

Step 4

exit

Example:

Device(config-vrf)# exit

Exits VRF configuration mode and enters global configuration mode.

Step 5

interface type number

Example:

Device(config)# interface gigabitethernet 0/0

Configures an interface and enters interface configuration mode.

Step 6

ip vrf forwarding name

Example:

Device(config-if)# ip vrf forwarding output

Associates a VRF instance and configures a VRF forwarding table on an interface.

Step 7

ip address ip-address mask

Example:

Device(config-if)# ip address 192.168.4.4 255.255.255.0

Configures an IP address for an interface.

Step 8

content-scan out

Example:

Device(config-if)# content-scan out

Configures the egress interface for content scanning.

Step 9

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 10

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VRF on the egress.

Step 11

duplex auto

Example:

Device(config-if)# duplex auto

Enables autonegotiation on an interface.

Step 12

speed auto

Example:

Device(config-if)# speed auto

Configures the speed of an interface.

Step 13

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Configuration Examples for VRF-Aware Cloud Web Security

- Example: Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

- Example: Configuring a Cloud Web Security Tower

- Example: VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

- Example: Configuring VRF-Aware Cloud Web Security

Example: Configuring a Cloud Web Security Tower in Cisco IOS Release 15.4(2)T and Later Releases

Note

This example applies to Cisco IOS Release 15.4(2)T and later releases.

Device# configure terminal
Device(config)# parameter-map type cws global
Device(config-profile)# server primary ipv4 10.2.2.2 port http 8080 https 8080
Device(config-profile)# server secondary name example1363.example.net port http 8080 https 8080
Device(config-profile)# license 0 F52409C9DAF22005CF33E64A7BC524C9
Device(config-profile)# source address ipv4 192.168.4.4
Device(config-profile)# timeout server 20
Device(config-profile)# timeout session-inactivity 180
Device(config-profile)# user-group group1 username user1
Device(config-profile)# server on-failure block-all
Device(config-profile)# end

Example: Configuring a Cloud Web Security Tower

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

Device# configure terminal
Device(config)# parameter-map type content-scan global
Device(config-profile)# server scansafe primary ipv4 10.2.2.2 port http 8080 https 8080
Device(config-profile)# server scansafe secondary name example1363.example.net port http 8080 https 8080
Device(config-profile)# license 0 F52409C9DAF22005CF33E64A7BC524C9
Device(config-profile)# source address ipv4 192.168.4.4
Device(config-profile)# timeout server 20
Device(config-profile)# timeout session-inactivity 180
Device(config-profile)# user-group group1 username user1
Device(config-profile)# server scansafe on-failure block-all
Device(config-profile)# end

Example: VRF-Aware Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Note

This example applies to Cisco IOS Release 15.4(2)T and later releases.

Device# configure terminal
Device(config)# ip vrf output
Device(config-vrf)# exit
Device(config)# interface gigabitethernet 0/0
Device(config-if)# ip vrf forwarding output
Device(config-if)# ip address 192.168.4.4 255.255.255.0
Device(config-if)# cws out
Device(config-if)# ip virtual-reassembly in
Device(config-if)# ip virtual-reassembly out
Device(config-if)# duplex auto
Device(config-if)# speed auto
Device(config-if)# end

Example: Configuring VRF-Aware Cloud Web Security

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

Device# configure terminal
Device(config)# ip vrf output
Device(config-vrf)# exit
Device(config)# interface gigabitethernet 0/0
Device(config-if)# ip vrf forwarding output
Device(config-if)# ip address 192.168.4.4 255.255.255.0
Device(config-if)# content-scan out
Device(config-if)# ip virtual-reassembly in
Device(config-if)# ip virtual-reassembly out
Device(config-if)# duplex auto
Device(config-if)# speed auto
Device(config-if)# end

Additional References for VRF-Aware Cloud Web Security

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Firewall commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here

Feature Information for VRF-Aware Cloud Web Security

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for VRF-Aware Cloud Web Security

Feature Name

Releases

Feature Information

VRF-Aware Cloud Web Security

15.4(1)T

15.4(2)T

The VRF-Aware Cloud Web Security feature adds virtual routing and forwarding (VRF) support to the Cisco Cloud Web Security configuration. VRF instances in IP-based networks enable a device to have multiple instances of the routing table at the same time. Because routing instances are independent of each other, they can use the same IP addresses without any conflict.

The following command was introduced or modified: show content-scan.

In Cisco IOS Release 15.4(2)T, the show content-scan command was replaced by the show cws command.

Chapter 3. Browser-Based Authentication Bypass

The Browser-Based Authentication Bypass feature enables web browsers to bypass authentication methods such as HTTP Basic, Web Authorization Proxy, and Windows NT LAN Manager (NTLM) (passive or explicit). Specific web browsers can be configured for authentication, and other browsers can be configured to bypass authentication.

This module provides information about the feature and how to configure it.

- Finding Feature Information

- Prerequisites for Browser-Based Authentication Bypass

- Information About Browser-Based Authentication Bypass

- How to Configure Browser-Based Authentication Bypass

- Configuration Examples for Browser-Based Authentication Bypass

- Additional References for Browser-Based Authentication Bypass

- Feature Information for Browser-Based Authentication Bypass

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Browser-Based Authentication Bypass

- You must configure at least one of these authentication methods—HTTP Basic, Web Authorization Proxy, or Windows NTLM—with browser-based authentication bypass.

- Use browser-based authentication bypass with the Default User-Group Policy feature.

Information About Browser-Based Authentication Bypass

- Browser-Based Authentication Bypass Overview

Browser-Based Authentication Bypass Overview

While using web browsers, as part of the user authentication, a pop-up or dialog box appears in some web browsers. The Browser-Based Authentication Bypass feature helps to bypass this user authentication and thus avoid the authentication pop-ups.

With the Browser-Based Authentication Bypass feature, you can configure web browsers that must be authenticated and browsers that can bypass user authentication. Bypassing is supported for authentication methods such as HTTP Basic, Web Authorization Proxy, and Windows NT LAN Manager (NTLM) (passive or explicit).

The Browser-Based Authentication Bypass feature supports the following web browsers:

- Chrome

- Firefox

- Internet Explorer 8 (IE8)

- IE9

- Safari

A network administrator configures a list of regular expression (regex) patterns in the IP admission module. When the IP admission module receives the HTTP Get request, the module compares the user-agent string in the HTTP header to the regex pattern that the administrator has configured for the bypass method.

The following rules apply to the Browser-Based Authentication Bypass feature:

- If a configured regex pattern does not match the user-agent field, a web browser is authenticated on the basis of the configured web authentication method.

- If a configured regex pattern matches the user-agent field, authentication is bypassed for the web browser and the HTTP traffic goes through to the Cisco Web Security cloud.

How to Configure Browser-Based Authentication Bypass

- Configuring Browser-Based Authentication Bypass

- Verifying Browser-Based Authentication Bypass

Configuring Browser-Based Authentication Bypass

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type regex regex-map

4.    pattern expression

5.    exit

6.    ip admission name admission-name bypass regex regex-map [absolute-timer minutes]

7.    Perform one of the following tasks:

- ip admission name admission-name ntlm

- ip admission name admission-name http-basic

- ip admission name admission-name proxy http

8.    interface type number

9.    ip admission admission-name

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type regex regex-map

Example:

Device(config)# parameter-map type regex regex-map1

Configures a parameter-map type with a regular expression (regex) to match a specific traffic pattern and enters parameter-map type inspect configuration mode.

Step 4

pattern expression

Example:

Device(config-profile)# pattern Chrome

Configures a matching pattern that compares the user-agent field in the HTTP Get request and the regex pattern.

Step 5

exit

Example:

Device(config-profile)# exit

Exits parameter-map type inspect configuration mode and enters global configuration mode.

Step 6

ip admission name admission-name bypass regex regex-map [absolute-timer minutes]

Example:

Device(config)# ip admission name rule1 bypass regex regex-map1 absolute-timer 10

Creates an IP Network Admission Control (NAC) rule to enable browser-based authentication bypass.

Step 7

Perform one of the following tasks:

- ip admission name admission-name ntlm

- ip admission name admission-name http-basic

- ip admission name admission-name proxy http

Example:

Device(config)# ip admission name rule1 ntlm

Device(config)# ip admission name rule1 http-basic

Device(config)# ip admission name rule1 proxy http

Configures one of the following authentication methods:

- Windows NT LAN Manager (NTLM)

- HTTP Basic

- Web Authorization Proxy

Step 8

interface type number

Example:

Device(config)# interface gigabitethernet0/1/0

Configures an interface and enters interface configuration mode.

Step 9

ip admission admission-name

Example:

Device(config-if)# ip admission rule1

Creates a Layer 3 Network Admission Control (NAC) rule to be applied to the interface.

Step 10

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

What to Do Next

For any parameter-map change to be reflected, remove and configure the ip admission name admission-name bypass regex regex-map [absolute-timer minutes] command in global configuration mode.

Verifying Browser-Based Authentication Bypass

SUMMARY STEPS

1.    enable

2.    show ip admission cache

3.    show ip admission configuration

DETAILED STEPS

Step 1

enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Device> enable

Step 2

show ip admission cache

Displays the current list of network admission entries and verifies the browser authentication bypass.

Example:

Device# show ip admission cache

Client Name N/A, Client IP 172.31.108.123, Port 63142, timeout 60, Time Remaining 60, state ESTAB (Browser Auth Bypass)

Step 3

show ip admission configuration

Displays the Network Admission Control (NAC) configuration.

Example:

Device# show ip admission configuration

Auth-proxy name webauth-profile
!
browser bypass, regex parameter-map name: reg-map inactivity-time 12 minutes absolute-timer 10 minutes

Configuration Examples for Browser-Based Authentication Bypass

- Example: Configuring Browser-Based Authentication Bypass

Example: Configuring Browser-Based Authentication Bypass

Device> enable
Device# configure terminal
Device(config)# parameter-map type regex regex-map1
Device(config-profile)# pattern Chrome
Device(config-profile)# exit
Device(config)# ip admission name rule1 bypass regex regex-map1 absolute-timer 10
Device(config)# ip admission name rule1 ntlm
Device(config)# interface gigabitethernet0/1/0
Device(config-if)# ip admission rule1
Device(config-if)# end

Additional References for Browser-Based Authentication Bypass

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Security commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

Cisco Web Security

"Cisco Web Security" module in the Security Configuration Guide: Zone-Based Policy Firewall

Authenticating and authorizing connections

"Configuring Authentication Proxy" module in the Authentication Proxy Configuration Guide

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here

Feature Information for Browser-Based Authentication Bypass

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Browser-Based Authentication Bypass

Feature Name

Releases

Feature Information

Browser-Based Authentication Bypass

15.3(3)M

The Browser-Based Authentication Bypass feature enables web browsers to bypass authentication methods such as HTTP Basic, Web Authorization Proxy, and Windows NTLM (passive or explicit).

The following command was introduced: ip admission name bypass regex.

Chapter 4. LDAP Server State

The LDAP Server State feature enables users to capture information about Lightweight Directory Access Protocol (LDAP) server reachability before a request is sent to the server.

LDAP provides applications with a standard method for accessing and modifying the information stored in a directory. LDAP is integrated into the Cisco software as an authentication, authorization, and accounting (AAA) protocol alongside the existing AAA protocols such as RADIUS, TACACS+, Kerberos, and Diameter.

- Finding Feature Information

- Prerequisites for LDAP Server State

- Restrictions for LDAP Server State

- Information About LDAP Server State

- How to Configure LDAP Server State

- Configuration Examples for LDAP Server State

- Additional References for LDAP Server State

- Feature Information for LDAP Server State

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for LDAP Server State

The Lightweight Directory Access Protocol (LDAP) server should be marked as DEAD by default to get the exact state of the server and the server group.

Restrictions for LDAP Server State

When configuring a Lightweight Directory Access Protocol (LDAP) server, we assume that the server is in DEAD state and is not reachable. The correct state of the server is obtained after the deadtime (the period during which new authentication requests are not sent to an LDAP server that has failed to respond to a previous request) expiry is reached. Within this time frame, even if the server is reachable, no requests should be sent to the server.

Information About LDAP Server State

- Overview of LDAP Server State

Overview of LDAP Server State

The LDAP Server State feature reduces the load on the network if the servers are not reachable and avoids unnecessary processing of retransmits.

The authentication, authorization, and accounting (AAA) servers are used to validate users or subscribers before they access a network. If one of the servers is not reachable, the next configured server specified in the configuration is contacted.

AAA client components make use of the DEAD and ALIVE states to keep track of each server state to handle protocol transactions effectively. If the state is DEAD, the client component applies a default set of policies to users or subscribers and allows them to access the default web content. If the state is ALIVE, the client component gets the actual policies from the Lightweight Directory Access Protocol (LDAP) server.

If the automate-tester command is configured along with the deadtime command, after every deadtime expiry, the AAA test APIs send a dummy bind request packet to the LDAP server.

- If a bind response is received, the server state is updated as ALIVE and further dummy bind requests are not sent.

- If a bind response is not received, the server state remains as DEAD and after every deadtime expiry, AAA test APIs send dummy bind request packets to the LDAP server.

If the deadtime command is configured when the server is not reachable, the server state remains DEAD until the deadtime expiry is reached, after which the state changes to ALIVE.

Note

If one of the servers in a server group is ALIVE, the server group is marked as ALIVE.

How to Configure LDAP Server State

Perform this task to enable the server state notification functionality in a Lightweight Directory Access Protocol (LDAP) server. By default, all servers are marked as DEAD during configuration.

- Configuring LDAP Server State

Configuring LDAP Server State

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    username user password {0 | 7} password

4.    aaa new-model

5.    ldap server name

6.    deadtime minutes

7.    automate-tester username name probe-on

8.    end

9.    show ldap server

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

username user password {0 | 7} password

Example:

Device(config)# username user1 password 0 pwd1

Configures an unencrypted password that is automatically picked up by the automate-tester command.

Step 4

aaa new-model

Example:

Device(config)# aaa new-model

Enables the authentication, authorization, and accounting (AAA ) access control system.

Step 5

ldap server name

Example:

Device(config)# ldap server server1

Configures a device to use the LDAP protocol and enters LDAP server configuration mode.

Step 6

deadtime minutes

Example:

Device(config-ldap-server)# deadtime 1

Configures the deadtime expiry value (in minutes) for the LDAP server.

Step 7

automate-tester username name probe-on

Example:

Device(config-ldap-server)# automate-tester username user1 probe-on

Assigns the state of the LDAP server as DEAD by default when configured along with the deadtime minutes command.

Step 8

end

Example:

Device(config-ldap-server)# end

Exits LDAP server configuration mode and returns to privileged EXEC mode.

Step 9

show ldap server

Example:

Device# show ldap server

Displays the LDAP server state information and various other counters for the server.

Configuration Examples for LDAP Server State

- Example: Configuring LDAP Server State

Example: Configuring LDAP Server State

Device# configure terminal
Device(config)# username user1 password 0 pwd1
Device(config)# aaa new-model
Device(config)# ldap server server1
Device(config-ldap-server)# deadtime 1
Device(config-ldap-server)# automate-tester username user1 probe-on
Device(config-ldap-server)# end

The following output is displayed on entering the automate-tester username name probe-on command:

*Feb 24 09:14:55.139: LDAP_SERVER 192.0.2.10 Server state is UP

The following sample output from the show ldap server command shows the Lightweight Directory Access Protocol (LDAP) server state information of server1 server and various other counters for the server.

Device# show ldap server server1 summary

Server Information for server1
================================
Server name :server1
Server Address :192.0.2.10
Server listening Port :389
Bind Root-dn :user1
Server mode :Non-Secure
Cipher Suite :0x00
Authentication Seq :Search first. Then Bind/Compare password next
Authentication Procedure:Bind with user password
Request timeout :30
Deadtime in Mins :1
State :ALIVE
No. of active connections :0
---------------------------------

Additional References for LDAP Server State

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Security commands

- Security Command Reference: Commands A to C

- Security Command Reference: Commands D to L

- Security Command Reference: Commands M to R

- Security Command Reference: Commands S to Z

LDAP configuration tasks

“Configuring LDAP” chapter in AAA LDAP Configuration Guide

Standards and RFCs

Standard/RFC

Title

RFC 4511

Lightweight Directory Access Protocol (LDAP)

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here

Feature Information for LDAP Server State

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for LDAP Server State

Feature Name

Releases

Feature Information

LDAP Server State

15.4(2)T

The LDAP Server State feature enables users to capture information about LDAP server reachability before a request is sent to the server.

The following commands were introduced or modified: automate-tester, deadtime.

Chapter 5. Cisco Integrated Services Routers Generation 2 with Cisco Cloud Web Security Solution

The Cisco Integrated Services Routers Generation 2 (ISR G2) with Cloud Web Security solution enables branch offices to intelligently redirect web traffic to the cloud to enforce granular security and acceptable use policies over user web traffic. With this solution, you can deploy a market-leading web security quickly and easily to protect branch office users from web-based threats such as viruses, while saving bandwidth, money, and resources.

This module explains how to configure Cloud Web Security on ISR G2.

- Information About Cisco Integrated Services Routers Generation 2 and Cisco Cloud Web Security Solution

- Configuring Cloud Web Security on Integrated Services Routers Generation 2

- Sample Configuration of Cloud Web Security on ISR G2s

- Cloud Web Security Troubleshooting Tips

- Additional References for Cisco Cloud Web Security and Integrated Services Routers Solution

Information About Cisco Integrated Services Routers Generation 2 and Cisco Cloud Web Security Solution

- Overview of Cisco ISR G2 and Cloud Web Security Solution

- How Cloud Web Security Works with an ISR G2

Overview of Cisco ISR G2 and Cloud Web Security Solution

The Cisco Integrated Services Router Generation 2 (ISR G2) family delivers numerous security services, including firewall, intrusion prevention, and VPN. These security capabilities are extended with Cisco Cloud Web Security for a web security and web filtering solution that does not require any additional hardware or client software.

The Cisco ISR G2 with Cloud Web Security solution can enable branch offices to intelligently redirect web traffic to the cloud to enforce granular security and acceptable use policies over user web traffic. With this solution, you can deploy web security quickly and easily to protect branch office users from web-based threats such as viruses, and save bandwidth and resources.

Cisco ISR G2 integration with Cloud Web Security provides the following features:

- Enforces granular security and acceptable use policies for branch office users without using on-premise hardware or without backhauling all branch office traffic to the headquarters.

- Provides a zero-day threat protection that is driven by Cisco Outbreak Intelligence, which uses dynamic reputation- and behavior-based analysis of web pages to stop malware from entering a network.

After configuring the ISR G2 router with Cloud Web Security, use the Cloud Web Security portal to create, edit, and manage Cloud Web Security accounts and policies.

- Benefits of Using the Cisco ISR G2 with Cloud Web Security

- Cloud Web Security Licensing

- Cloud Web Security Supported Platforms

Benefits of Using the Cisco ISR G2 with Cloud Web Security

The following benefits apply to the Cisco Integrated Service Routers Generation 2 (ISR G2) and Cisco Cloud Web Security solution:

- Lower total cost of ownership: Helps customers avoid costs associated with deployment and maintenance of on-premise software and hardware.

- Leading security: Real-time cloud-based scanning blocks malware and inappropriate content before it enters the network.

- Scalability and availability: The global network processes high volumes of web content at high speeds.

- Integration with other Cisco security products: Cisco ISR G2 with Cloud Web Security integrates Cisco AnyConnect to offer a web security solution for users both on and off the network.

- Consistent, unified policy: Acceptable use policy (AUP) that can be applied to all users regardless of their location, simplifying management.

For more information on configuring and using the Cloud Web Security Portal, see the Cisco CWS Portal Administrator Guide.

Cloud Web Security Licensing

The Cloud Web Security feature on the Cisco Integrated Services Routers Generation 2 (ISR G2) is available with the Security SECK9 license bundle. For more information on configuring the Security SECK9 license bundle, refer to the Cisco ISR G2 Licensing and Packaging white paper.

Cloud Web Security Supported Platforms

The following table lists the Cisco Integrated Services Routers Generation 2 (ISR G2) platforms compatible with Cloud Web Security:

Supported Platforms

Product

Supported Platforms

Cisco 800 Series Integrated Service Routers

Cisco 819, 860VAE, 880VA, 881, 881W, 887V, 888E, 888EA, 888, 888W, 891, 891W, 892, 892F, 892FW, 892W

Cisco 1900 Series Integrated Service Routers

Cisco 1905, 1921, 1941, 1941W

Cisco 2900 Series Integrated Service Routers

Cisco 2901, 2911, 2921, 2951

Cisco 3900 Series Integrated Service Routers

Cisco 3925, 3925E, 3945, 3945E

The Cisco ISR G2 and Cloud Web Security Design Guide provides details of supported architectures and best practices.

How Cloud Web Security Works with an ISR G2

When Cisco Cloud Web Security is enabled on a Cisco Integrated Services Routers Generation 2 (ISR G2) and the router is configured to redirect web traffic to the Cloud Web Security server, the ISR G2 router transparently redirects HTTP and secure HTTP (HTTPS) traffic to the Cloud Web Security proxy servers based on the destination IP address and port number. The Cloud Web Security proxy servers scan the content and either allow or block the traffic based on the configured policies, to enforce an acceptable use and protect clients from malwares.

The ISR G2 router authenticates and identifies users who make web traffic requests using the configured authentication and authorization methods. The router encrypts user information and includes the information (user name and user groups) in the traffic that it redirects to the Cloud Web Security server. Cloud Web Security uses user credentials to determine the web policies to apply to users and for user-based reporting.

You can configure the ISR G2 router to direct web traffic directly to the originally requested web server and avoid the scanning of web traffic by Cloud Web Security. For more information, see the section “Bypassing Cisco Cloud Web Security Scanning”.

You can configure a primary and a backup Cloud Web Security proxy servers. The ISR G2 router polls each server regularly to check for their availability.

- Communication Between Cloud Web Security, ISR G2, and Clients

- Cisco Cloud Web Security Headers

- Bypassing Cloud Web Security Scanning

- Working with Multiple ISRs

Communication Between Cloud Web Security, ISR G2, and Clients

Clients are any devices that can connect to a Cisco Integrated Services Routers Generation 2 (ISR G2), either directly or indirectly. When a client sends an HTTP or secure HTTP (HTTPS) request, the ISR G2 router receives the request and forwards it to the Cloud Web Security proxy server. If authentication is configured, the ISR G2 router first authenticates the user, and then retrieves the group name from the authentication server. The router maintains the IP address-to-user-name mapping for future reference. After identifying the user (if applicable), the ISR G2 router determines whether to send the HTTP or HTTPS client request to the Cloud Web Security server by checking the Cisco IOS Firewall Port to Application Mapping (PAM) and whitelist database.

For information about PAM, see the “Configuring Port to Application Mapping" chapter in the Context-Based Access Control Firewall configuration Guide.

When the ISR G2 router sends a client request to Cloud Web Security servers, the router acts as an intermediary between the client and Cloud Web Security by creating a separate connection with the Cloud Web Security proxy server. When the ISR G2 router communicates with Cloud Web Security, it changes the destination IP address and destination port in the client request. It also adds Cloud Web Security-specific HTTP headers, which includes information about the username and user group, and then sends the modified request to Cloud Web Security.

You can configure how the ISR G2 router handles web traffic when it cannot reach either the primary or backup Cloud Web Security proxy server. It can either block or allow all web traffic. By default, it blocks web traffic.

When Cloud Web Security receives an HTTP or HTTPS request from an ISR G2 router, it uses the information in the request and user credentials in the Cloud Web Security HTTP headers to apply the appropriate policies to the user. After applying the configured policies, Cloud Web Security allows, blocks, or presents a warning message before allowing the client request:

- Allow—When Cloud Web Security allows a client request, it contacts the originally requested server and retrieves data. Cloud Web Security forwards the server response to the ISR G2 router, which then forwards the response to the client. The ISR G2 changes the source and destination IP addresses and ports in the response.

- Block—When Cloud Web Security blocks a client request, it sends an HTTP 302 “Moved Temporarily” response that redirects the client application to a web page hosted by Cloud Web Security. This page notifies the user that access has been blocked. The ISR G2 router forwards the 302 response to the client changing the source and destination IP addresses and port numbers.

Note

Administrators can customize the block page by using the Cloud Web Security portal.

- Warn—Sometimes, web sites that do not fully comply with a company's policies are not completely blocked. In these cases, Cloud Web Security first presents a page hosted by Cloud Web Security with a warning message and an “accept” button. Users who click the accept button, is allowed access to these sites.

Note

ISR G2 routers do not have the ability to detect apps on mobile devices, even if the apps are web-based. As a result, traffic from apps launched on mobile devices and tablets may not be blocked/warned by the configured Cloud Web Security policies. However, if the content is accessed through a web browser, the content is blocked/warned according to specified policies. For example, Facebook access is blocked by the configured Cloud Web Security policies of a company. Employees of this company will not be able to access Facebook through Safari on an Apple iPad; however, they may be able to access Facebook through the Facebook app that is installed on the Apple iPad.

Cisco Cloud Web Security Headers

A device that forwards web traffic to Cisco Cloud Web Security proxy servers includes additional HTTP headers in each HTTP and HTTPS request. Cisco Cloud Web Security uses these headers to obtain information about customer deployments, including information about the user who had originally made the client request and the device that sent the request. For security purposes, the information in the headers is encrypted and then hexadecimal encoded.

Cisco Cloud Web Security headers provide both asymmetric cryptography and symmetric cryptography by using industry standard algorithms. Asymmetric encryption is done by using the RSA/ECB/PKCS1Padding algorithm that uses key pairs of 512 bits. Symmetric encryption is done by using the triple “DESede” algorithm with a randomly generated triple Data Encryption Standard (DES) key of 168 bits.

The ISR adds the following CWS HTTP headers:

- X-ScanSafe—This contains a session key that is encrypted using a CWS public key (embedded in the ISR operating system).

- X-ScanSafe-Data—This contains the data CWS needs. It is encrypted with the session key from the X-CWS header.

For example, the headers in a message might look like the following text:

- X-ScanSafe: 35A9C7655CF259C175259A9B980A8DFBF5AC934720BE9374D344F7E584780ECDB9236FF90DF562A79DC4C75 4C3782E7C3D38C76566F0377D5689E25BD62FC5F

- X-ScanSafe-Data: 8D57AEE5D76432ACAB184AA807D94A7392986FA0D3ED9BEB

Bypassing Cloud Web Security Scanning

You can configure Cisco Integrated Services Routers Generation 2 (ISR G2) to bypass Cloud Web Security scanning of approved web traffic. When Cloud Web Security scanning is bypassed, the ISR G2 router retrieves the content directly from the originally requested web server without contacting Cloud Web Security. When the router receives a response from the web server, it sends the data directly to the client.

You can bypass Cloud Web Security scanning based on the following client web traffic properties:

- IP address—Bypass the scanning of traffic that matches a numbered or named access control list (ACL) that is configured in the global parameter map on the ISR G2 router. Configure Cloud Web Security traffic for trusted sites, such as intranet servers.

- HTTP header fields—Bypass the scanning of web traffic that matches an HTTP header field that is configured in a global parameter map on the ISR G2 router. You can configure a match based on Host or User-Agent header fields for user agents that do not function properly when scanned. Or, you can bypass scanning traffic that is intended for trusted hosts, such as third- party partners. Note: When HTTP header-based whitelisting is enabled, the ISR G2 router automatically disables/removes TCP options such as windows scaling and timestamps.

- Username or User group—Bypass the scanning for web traffic that matches a username or the user group a user belongs to. You can bypass scanning for a subset of trusted users.

Use the commandscontent-scan whitelisting and whitelist to create a whitelist database for traffic that can bypass scanning.

Working with Multiple ISRs

A typical branch office uses one Cisco Integrated Services Routers Generation 2 (ISR G2) to route network traffic to the headquarter and redirect web traffic to Cloud Web Security for security scanning. Some organizations can have multiple branch offices with one ISR G2 router in each office.

These ISR G2 routers may force users to authenticate before granting access to the network. The ISR G2 authentication sends user-group information about the user who makes the web request from an authentication server. When the ISR G2 router do not enforce authentication, no user group information is sent from the authentication server. Use the command user-group to configure a default user-group name for all web traffic, while configuring Cloud Web Security on the ISR G2 router. All ISR G2 routers must be configured with a license (authentication key) in the Cloud Web Security portal. The Cloud Web Security portal supports company and group authentication keys.

If your network has multiple ISR G2 routers, you can choose the type of Cloud Web Security authentication key the you need to create and use when you configure each ISR G2 router. Configure the authentication key based on whether the ISR G2 router enforces authentication or not.

- No authentication on the ISR G2 router—Cloud Web Security applies the same web policies to all traffic originating from a single ISR G2 router. To apply different web policies for traffic from different ISR G2 routers, generate a group key in the Cloud Web Security portal for each ISR G2 router. Configure a different group key as the license in each ISR G2 router configuration. To apply the same web policies for traffic from all ISR G2 routers, generate a company key in the Cloud Web Security portal and configure it as the license in each ISR G2 router configuration. A company key is a key used by an organization.

- Authentication on the ISR G2 router—When an ISR G2 router enforces authentication, it sends user-group information from an authentication server in the redirected web traffic. Cloud Web Traffic enables you to apply different web policies for different user groups. Generate a company key in the Cloud Web Security portal and configure the key as the license in each ISR G2 router configuration. You can apply either the same Cloud Web Security policy or different policies to different user groups.

Configuring Cloud Web Security on Integrated Services Routers Generation 2

In Cisco IOS Release 15.4(2)T release, some Cloud Web Security commands were replaced. The releases prior to Cisco IOS Release 15.4(2)T still use the old commands.

This section consists of tasks that use the commands existing prior to Cisco IOS Release 15.4(2)T and a corresponding task that uses the commands introduced or modified in the Cisco IOS Release 15.4(2)T.

To use Cisco Cloud Web Security with Cisco Integrated Services Routers Generation 2 (ISR G2), you must configure the following products:

- Cisco ISR G2 router that uses Cisco IOS Release 15.3(3)M or later releases.

Note

The recommend image is Cisco IOS Release15.3(3)M or later releases, however, Cloud Web Security works on Cisco IOS Releases 15.2(1)T1 and later releases.

- Cisco Cloud Web Security Portal.

- Before you enable Cloud Web Security on an ISR G2 router, create a company or group key in the Cloud Web Security portal.

To configure Cloud Web Security on an ISR G2 router, perform the following tasks:

- Configuring Cisco Cloud Web Security Features

- Enabling Cisco Cloud Web Security on the ISR G2

- Configuring Whitelisting

- Configuring a Default-User Group

- Configuring Authentication with Cloud Web Security

- Configuring NTLM or HTTP Basic Authentication

- Transparent Authentication with NTLM

- Domain and Non-Domain Users

- Configuring the Cisco Cloud Web Security Portal

- Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring Cisco Cloud Web Security

- Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

- Configuring Whitelisting

- Configuring Default User Groups

- Cloud Web Security Authentication Types

- Authentication Failure

- Acceptable Use Policy Aggrement

- Enabling Nested LDAP for Cloud Web Security

- Configuring the Cisco Cloud Web Security Portal

- Cloud Web Security Logging Messages

Configuring Cloud Web Security in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type cws global

4.    server primary ipv4 ip-address port http port-number https port-number

5.    server secondary ipv4 ip-address port http port-number https port-number

6.    license 7 license-key

7.    source interface type number

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group group-name username username

11.    server on-failure block-all

12.    user-group exclude username

13.    exit

14.    interface type number

15.    cws out

16.    ip virtual-reassembly in

17.    ip virtual-reassembly out

18.    end

19.    show cws

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type cws global

Example:

Device(config)# parameter-map type cws global

Configures a global Cloud Web Security parameter map and enters parameter-map type inspect configuration mode.

Step 4

server primary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server primary ipv4 10.12.34.23 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server secondary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server secondary ipv4 10.21.34.21 port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license 7 license-key

Example:

Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507

Configures an encrypted license key that is sent to Cisco Cloud Web Security for authentication.

Step 7

source interface type number

Example:

Device(config-profile)# source interface fastethernet 0/2

Configures the source interface for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 5

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 3600

Specifies the session inactivity time in seconds.

Step 10

user-group group-name username username

Example:

Device(config-profile)# user-group marketing username superuser

Specifies a default usergroup.

Step 11

server on-failure block-all

Example:

Device(config-profile)# server on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

user-group exclude username

Example:

Device(config-profile)# user-group exclude marketing

Excludes the specified user group.

Step 13

exit

Example:

Device(config-profile)# exit

Exits parameter-map type inspect configuration mode and enters global configuration mode.

Step 14

interface type number

Example:

Device(config)# interface ethernet 0/0

Configures an interface and enters interface configuration mode.

Step 15

cws out

Example:

Device(config-if)# cws out

Configures the egress interface for Cloud Web Security content scanning.

Step 16

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 17

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VFR on the egress.

Step 18

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Step 19

show cws

Example:

Device# show cws

Displays content scanning information.

Example

The following is sample output from the show cws history command:

Device# show cws history 6

Protocol     Source                                                 Destination                                         Bytes                                 URI                                                                 Time
HTTP                     192.168.100.2:1347  209.165.201.4:80    (102:45)               www.google.com            00:01:13
HTTP                     192.168.100.2:1326  209.165.201.6:80    (206:11431)    www.google.com            00:12:55
HTTP                     192.168.100.2:1324  209.165.201.5:80    (206:11449)    www.google.com            00:15:20
HTTP                     192.168.100.2:1318  209.165.201.5:80    (206:11449)    www.google.com            00:17:43
HTTP                     192.168.100.2:1316  209.165.201.4:80    (206:11449)    www.google.com            00:20:04
HTTP                     192.168.100.2:1315  10.254.145.107:80   (575:1547)     alert.scansafe.net  00:21:32

Configuring Cisco Cloud Web Security

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    parameter-map type content-scan global

4.    server scansafe primary ipv4 ip-address port http port-number https port-number

5.    server scansafe secondary ipv4 ip-address port http port-number https port-number

6.    license 7 license-key

7.    source interface type number

8.    timeout server seconds

9.    timeout session-inactivity seconds

10.    user-group group-name username username

11.    server scansafe on-failure block-all

12.    user-group exclude username

13.    exit

14.    interface type number

15.    content-scan out

16.    ip virtual-reassembly in

17.    ip virtual-reassembly out

18.    end

19.    show content-scan

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

parameter-map type content-scan global

Example:

Device(config)# parameter-map type content-scan global

Configures a global content-scan parameter map and enters parameter-map type inspect configuration mode.

Step 4

server scansafe primary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server scansafe primary ipv4 10.12.34.23 port http 8080 https 8080

Configures a Cisco Cloud Web Security primary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 5

server scansafe secondary ipv4 ip-address port http port-number https port-number

Example:

Device(config-profile)# server scansafe secondary ipv4 10.21.34.21 port http 8080 https 8080

Configures a Cisco Cloud Web Security secondary server for content scanning.

- The default Cisco Cloud Web Security port for the proxied HTTP and HTTPS traffic is 8080.

- You can use either the HTTP port or the HTTPS port or both.

Step 6

license 7 license-key

Example:

Device(config-profile)# license 7 D5D4A545D7A53222E706D1A5D3B5D4E345E5B25737A737B6613724257425A507

Configures an encrypted license key that is sent to Cisco Cloud Web Security for authentication.

Step 7

source interface type number

Example:

Device(config-profile)# source interface fastethernet 0/2

Configures the source interface for content scan redirection.

Step 8

timeout server seconds

Example:

Device(config-profile)# timeout server 5

Specifies a server keepalive time in seconds.

Step 9

timeout session-inactivity seconds

Example:

Device(config-profile)# timeout session-inactivity 3600

Specifies the session inactivity time in seconds.

Step 10

user-group group-name username username

Example:

Device(config-profile)# user-group marketing username superuser

Specifies a default usergroup.

Step 11

server scansafe on-failure block-all

Example:

Device(config-profile)# server scansafe on-failure block-all

Blocks all traffic to a web server when communication between the web server and the Cisco Cloud Web Security server fails.

Step 12

user-group exclude username

Example:

Device(config-profile)# user-group exclude marketing

Excludes the specified user group.

Step 13

exit

Example:

Device(config-profile)# exit

Exits parameter-map type inspect configuration mode and enters global configuration mode.

Step 14

interface type number

Example:

Device(config)# interface ethernet 0/0

Configures an interface and enters interface configuration mode.

Step 15

content-scan out

Example:

Device(config-if)# content-scan out

Configures the egress interface for content scanning.

Step 16

ip virtual-reassembly in

Example:

Device(config-if)# ip virtual-reassembly in

Enables Virtual Fragment Reassembly (VFR) on the ingress.

Step 17

ip virtual-reassembly out

Example:

Device(config-if)# ip virtual-reassembly out

Enables VFR on the egress.

Step 18

end

Example:

Device(config-if)# end

Exits interface configuration mode and enters privileged EXEC mode.

Step 19

show content-scan

Example:

Device# show content-scan

Displays content scanning information.

Example

The following is sample output from the show content-scan history command:

Device# show content-scan history 6

Protocol     Source                                                 Destination                                         Bytes                                 URI                                                                 Time
HTTP                     192.168.100.2:1347  209.165.201.4:80    (102:45)               www.google.com            00:01:13
HTTP                     192.168.100.2:1326  209.165.201.6:80    (206:11431)    www.google.com            00:12:55
HTTP                     192.168.100.2:1324  209.165.201.5:80    (206:11449)    www.google.com            00:15:20
HTTP                     192.168.100.2:1318  209.165.201.5:80    (206:11449)    www.google.com            00:17:43
HTTP                     192.168.100.2:1316  209.165.201.4:80    (206:11449)    www.google.com            00:20:04
HTTP                     192.168.100.2:1315  10.254.145.107:80   (575:1547)     alert.scansafe.net  00:21:32

Configuring Whitelisting in Cisco IOS Release 15.4(2)T and Later Releases

Note

This task applies to Cisco IOS Release 15.4(2)T and later releases.

User and user-group-based whitelisting is initially done during a TCP synchronization (SYN). No content-scan sessions are created when a session is whitelisted based on an username or user group. The order of whitelisting is: acl, user, user group, header user-agent, header host.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    cws whitelisting

4.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

5.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

6.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

7.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

cws whitelisting

Example:

Device(config)# cws whitelisting

Enables whitelisting of incoming traffic and enters Cloud Web Security whitelisting configuration mode.

Step 4

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist acl name whitelistedSubnets

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 5

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist header host regex whitelistedPatterns

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 6

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cws-wl)# whitelist user regex whitelistedUsers

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 7

end

Example:

Device(config-cws-wl)# end

Exits Cloud Web Security whitelisting configuration mode and returns to privileged EXEC mode.

Configuring Whitelisting

Note

This task applies to releases prior to Cisco IOS Release 15.4(2)T.

User and user-group-based whitelisting is initially done during a TCP synchronization (SYN). No content-scan sessions are created when a session is whitelisted based on an username or user group. The order of whitelisting is: acl, user, user group, header user-agent, header host.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    content-scan whitelisting

4.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

5.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

6.    whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

7.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

content-scan whitelisting

Example:

Device(config)# content-scan whitelisting

Enables whitelisting of incoming traffic and enters content-scan whitelisting configuration mode.

Step 4

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist acl name whitelistedSubnets

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 5

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist header host regex whitelistedPatterns

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 6

whitelist {acl {aclist | extended-acl-list | acl-name} | header {host | user-agent} regex regex-host | notify-tower}

Example:

Device(config-cont-scan-wl)# whitelist user regex whitelistedUsers

Configures whitelisting of traffic based on the access control list (ACL) or the HTTP request whose header matches the configured regular expression.

Step 7

end

Example:

Device(config-cont-scan-wl)# end

Exits content-scan whitelisting configuration mode and returns to privileged EXEC mode.

- Whitelisting HTTP Traffic

- Example: Configuring Whitelisting

Whitelisting HTTP Traffic

By default, Cloud Web Security forwards both HTTP and secure HTTP (HTTPS) traffic to the Cloud Web Security server. However, you can use whitelisting to bypass HTTPS traffic from Cloud Web Security redirection.

To whitelist HTTPS traffic, first create an access control list (ACL) that matches the HTTPS traffic, and add this ACL to the Cloud Web Security whitelist

ip access-list extended matchHTTPS
permit ip any any eq 443
!
content-scan whitelisting
whitelist acl name matchHTTPS
!

Or you can remove the HTTPS port configuration in the Cloud Web Security parameter map.

parameter-map type content-scan global
server scansafe primary ipv4 72.37.244.147 port http 8080
server scansafe secondary ipv4 80.254.145.147 port http 8080
!

Example: Configuring Whitelisting

Note

This example applies to releases prior to Cisco IOS Release 15.4(2)T.

Device# configure terminal
Device(config)# content-scan whitelisting
Device(config-cont-scan-wl)# whitelist header host regex whitelistedPatterns
Device(config-cont-scan-wl)# whitelist acl name whitelistedSubnets
Device(config-cont-scan-wl)# whitelist user regex whitelistedUsers
Device(config-cont-scan-wl)# whitelist user-group regex whitelistedUserGroups
Device(config-cont-scan-wl)# end

Configuring Default User Groups

You can configure a default user group on the egress interface to assign to clients when Integrated Services Routers Generation 2 (ISR G2) cannot determine the credentials users. Define a default user group using the following commands:

interface GigabitEthernet 0/1
user-group default user-group1

The ISR G2 uses the default user-group name to identify all clients who are connected to an interface, when it cannot determine the user credentials. Define a default user group so that all traffic that is redirected to the Cloud Web Security proxy servers are assigned a user group to ensure that Cloud Web Security policies are appropriately applied. Only one user group can be defined per interface.

The order of user groups is as follows:

1. User group information from authentication methods (example, AD group information)

2. Interface default user group

3. Parameter-map default user group

If no user group information is gathered during authentication, the default-user group information configured on the interface is used. If a default-user group is not configured on the interface, the ISR G2 router uses the default user group information configured in a parameter map to forward traffic to the Cloud Web Security tower.

Cloud Web Security Authentication Types

Cloud Web Security on Integrated Services Routers Generation 2 (ISR G2) supports three types of authentication—NT LAN Manager (NTLM), HTTP Basic, and Web authentication. The following tables provides a list of authentication types supported in various Cisco IOS Releases:

Cisco IOS Release

Authentication Type Supported

15.2(1)T1, 15.2(1)T2, 15.2(2)T1

Web and HTTP Basic authentication

15.2(4)M and later

NTLM, HTTP Basic, Web Auth

To configure web authentication, refer to the “Configuring Authentication Proxy” module of the Authentication Proxy Configuration Guide.

- NTLM or HTTP Basic Authentication

- Configuring NTLM or HTTP Basic Authentication

- Transparent Authentication with NTLM

- Bypassing Authentication

- Network/IP-Based Authentication Bypass

- Browser-Based Authentication Bypass

NTLM or HTTP Basic Authentication

Cisco Integrated Services Routers Generation 2 (ISR-G2) uses Windows NT Lan Manager (NTLM) to retrieve user credentials transparently from the client application without prompting end users for authentication. If the client application cannot send user credentials transparently, ISR G2 prompts users to enter credentials.

When using NTLM authentication, you can choose two modes: active or passive. The default mode for NTLM authentication is active. To enable passive mode, configure the command ip admission name rule1 ntlm passive.

In NTLM active mode, ISR G2 routers gather both the username and password from the client during the TCP handshake process and verify these against the Active Directory domain controller. In NTLM passive mode, ISR G2 routers only query for the user group information and do not verify the password, which reduces the number of transactions between ISR G2 routers and the domain controller.

During HTTP basic authentication, client applications always prompt users to enter their credentials.

Configuring NTLM or HTTP Basic Authentication

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    aaa new-model

4.    ldap server name

5.    ipv4 ip-address

6.    bind authenticate root-dn password [0 string | 7 string] string

7.    base-dn string

8.    authentication bind-first

9.    exit

10.    ldap attribute-map map-name

11.    map type ldap-attr-type aaa-attr-type

12.    exit

13.    aaa group server ldap group-name

14.    aaa authentication login list-name

15.    ip admission admission-name

16.    ip admission virtual-ip ip-address virtual-host hostname

17.    interface type number

18.    ip admission admission-name

19.    exit

20.    ip http server

21.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa new-model

Example:

Device(config)# aaa new-model

Enables the authentication, authorization, and accounting (AAA) functionality on the device.

- Note:   Once you enable the aaa new-model command, it cannot be disabled.

Step 4

ldap server name

Example:

Device(config)# ldap server server1

Defines a Lightweight Directory Access Protocol (LDAP) server and enters LDAP server configuration mode.

Step 5

ipv4 ip-address

Example:

Device(config-ldap-server)# ipv4 10.1.1.1

Specifies the LDAP server IP address using IPv4.

Step 6

bind authenticate root-dn password [0 string | 7 string] string

Example:

Device(config-ldap-server)# bind authenticate root-dn “cn=administrator,cn=users,dc=nac-blr2,dc=example,dc=com password”

Specifies a shared secret text string used between the device and an LDAP server.

- Use the 0 line option to configure an unencrypted shared secret.

- Use the 7 line option to configure an encrypted shared secret.

- Note:   If passive NTLM authentication is used, this command is mandatory.

Step 7

base-dn string

Example:

Device(config-ldap-server)#  base-dn "dc=sns,dc=example,dc=com"

(Optional) Configures the base distinguished name to use for search operations in the LDAP server.

Step 8

authentication bind-first

Example:

Device(config-ldap-server)# authentication bind-first

Configures the sequence of search and bind operations for an authentication request.

Step 9

exit

Example:

Device(config-ldap-server)# exit

Exits mode and returns to global configuration mode.

Step 10

ldap attribute-map map-name

Example:

Device(config)# ldap attribute-map map1

Configures a dynamic LDAP attribute map and enters attribute-map configuration mode.

Step 11

map type ldap-attr-type aaa-attr-type

Example:

Device(config-attr-map)# map type department hr-group

Defines an attribute map.

Step 12

exit

Example:

Device(config-attr-map)# exit

Exits attribute-map configuration mode and returns to global configuration mode.

Step 13

aaa group server ldap group-name

Example:

Device(config)# aaa group server ldap name1

Defines the AAA server group with a group name and enters LDAP server group configuration mode. All members of a group must be the of same type, that is, RADIUS, LDAP, or TACACS+.

Step 14

aaa authentication login list-name

Example:

Device(config)# aaa authentication login userauthen

Sets AAA authentication at login. The default keyword uses the listed authentication methods that follow this keyword as the default list of methods when a user logs in.

Step 15

ip admission admission-name

Example:

Device(config)# ip admission webauth

Creates a global policy that can be applied on a network access device.

Step 16

ip admission virtual-ip ip-address virtual-host hostname

Example:

Device(config)# ip admission virtual-ip 10.2.2.2 virtual-host webproxy

Configures a web-based proxy authentication virtual IP address.

- This command is required only for transparent authentication with NTLM.

- The IP address should not correspond to an existing device on the network and should not have the same IP as any interface on the Cisco Integrated Service Routers Generation 2 (ISR G2). The virtual proxy hostname is a single-word, non-qualified domain name.

Step 17

interface type number

Example:

Device(config)# interface gigabitethernet 0/0

Configures an interface and enters interface configuration mode.

Step 18

ip admission admission-name

Example:

Device(config-if)# ip admission webproxy

Creates a Layer 3 network admission control rule to be applied to the interface.

Step 19

exit

Example:

Device(config-if)# exit

Exits interface configuration mode and returns to global configuration mode.

Step 20

ip http server

Example:

Device(config)# ip http server

Enables the HTTP server on your IP system.

- Credentials can be passed using HTTPS instead of HTTP with the command ip http secure-server. With HTTPS, clients may encounter SSL certificate errors as the ISR G2 routers use a test certificate server. To avoid SSL certificate errors, replace the certificate on ISR G2 routers with a certificate signed by a trusted certificate authority.

Step 21

end

Example:

Device(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Transparent Authentication with NTLM

An Integrated Services Routers Generation 2 (ISR G2) that uses Windows NT LAN Manager (NTLM) to authenticate users tries to retrieve user credentials transparently from the client application without prompting users for authentication. If the client application cannot send user credentials transparently, then the ISR G2 prompts users to enter their username and password.

During NTLM authentication, an ISR G2 router redirects the client browser from the originally requested URL to a virtual proxy URL (either by using the configured IP address or hostname) configured on the ISR G2 router. After the browser redirects users to the virtual proxy URL, the users are prompted for authentication credentials. Successfully authenticated users are redirected to the requested URL.

Users are transparently authenticated by using NTLM when they access the web using a web browsers on the Windows operating system. For example, users are transparently authenticated through Microsoft Internet Explorer, Mozilla Firefox, and Google Chrome on Windows; however, the users are prompted for authentication credentials when using Apple Safari on an Apple Macintosh or Opera on any operating system.

To ensure that users are transparently authenticated using Microsoft Internet Explorer, Mozilla Firefox, and Chrome on the Windows operating system, perform the following steps:

1. Define a virtual proxy URL on the ISR G2 router using the ip admission command.

ip admission virtual-ip 10.1.1.1 virtual-host webproxy

Note

You can specify a single-word hostname as the virtual proxy hostname. The virtual proxy IP address must not be used by any other device or configured on the ISR G2 router.

2. Configure the third-party authentication software to transparently authenticate users by using the virtual proxy URL.

- If you are using Microsoft Internet Explorer or Google Chrome, perform the following step:

- If a virtual proxy hostname is defined, create a Domain Name System (DNS) record that resolves the virtual proxy hostname to the virtual proxy IP address specified in Step 1 (10.1.1.1). Microsoft Internet Explorer and Google Chrome consider a single word hostname as a local intranet server.

- Microsoft Internet Explorer: Add the virtual proxy URL to the Microsoft Internet Explorer Local Intranet Zone. If only the virtual proxy IP address is defined, add the IP address (for example, http://10.1.1.1) to the Local Intranet Zone. If the virtual proxy hostname is defined, add it (for example, http://webproxy) to the Local Intranet Zone. For more information on adding a URL to the Internet Explorer Local Intranet Zone, see the Internet Explorer documentation.

- Mozilla Firefox: Edit the Mozilla Firefox preferences that determines the sites that are automatically authenticated by using NTLM and add the virtual proxy URL configured in Step 1. The “network.automatic-ntlm-auth.trusted-uris” is the configuration setting that you have to edit. For more information on editing the Firefox configuration, see the Mozilla Firefox documentation.

Bypassing Authentication

Use network/IP-based authentication or browser-based authentication bypass to disable the authentication to users.

Network/IP-Based Authentication Bypass

To configure Cisco Integrated Services Routers Generation 2 (ISRvG2) to bypass authentication for certain subnets and users, you must either know the IP addresses of the users you do want to authenticate, or the IP addresses of users you do not want to authenticate. Create an access control list (ACL) that permits users who are authenticated and denies users who bypasses authentication access to the network. The ACL rule must associated with the ip admission command.

The following example shows how to authenticate users whose IP addresses are known:

ip access-list extended authenticationACL
permit ip 10.0.0.0 0.0.0.255 any any  !! users in this IP range will be asked to authenticate first. everyone else bypasses authentication [implicit deny for all others]
!
ip admission name ntlm-rule ntlm list authenticationACL

The following example shows how not to authenticate users whose IP addresses are known:

ip access-list extended authenticationACL
deny ip 10.0.0.0 0.0.0.255 any any  !! users in this IP range will be NOT be asked to authenticate. everyone else must authenticate first
permit ip any any
!
ip admission name ntlm-rule ntlm list authenticationACL

Note

This configuration is mostly used only in proof-of-concept or pilot phases where only a subset of users access Cisco Cloud Web Security. For production deployments, typically all corporate users are asked for authentication. For guest users, it is recommended to have a separate VLAN or a network that does not apply authentication. The bypass authentication configuration should only be used if a separate guest VLAN/network is not possible.

Browser-Based Authentication Bypass

Transparent authentication can be done through NTLM authentication. However, some web browsers that do not support transparent NTLM authentication, such as Mozilla Firefox or Apple Safari, will use authentication prompts.

The Browser-Based Authentication Bypass features uses the user agent string sent by the web browser to bypass authentication. A list of user agent strings can be configured on the web browser. Before the authentication, the Cisco Integrated Services Routers Generation 2 (ISR G2) checks if the user agent string from a user’s device matches the configured list. If there is a match, authentication is bypassed, and the user can access the Internet with guest Cloud Web Security policies. If there is no match, user authentication is required. Web browsers that support transparent NTLM authentication, the authentication happens in the background, and users are not prompted for credentials.

The ISR G2 router does a match on the user agent string configured on the router with the user agent string sent by the web browser. Web browsers may change the user agent string that is used to identify the browser. A best practice is for the Network administrators to periodically update the list of user agent strings on the ISR G2 router. To find the user agent string that your web browser is sending, go to http://whatsmyuseragent.com. A list of user agent strings is also available at http://techpatterns.com/forums/about304.html

A sample user agent string for an iPad 3 would be the following: “Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3”

Typically most smartphones or tablets have the following user agent strings:

Mobile =
iphone|ipod|android|blackberry|opera|mini|windows\sce|palm|smartphone|iemobile
Tablet =
ipad|android|android|xoom|sch-i800|playbook|tablet|kindle

The following is a sample parameter map (to match common bring-your-own devices) that uses the user agent strings given above:

parameter-map type regex byod
pattern .*iPad*
pattern .*andriod*
pattern .*kindle*

Authentication Failure

Prior to the Cisco IOS Release 15.2(4)M3, if a user failed authentication, the default behavior was to block all Internet access for that IP address. In Cisco IOS Release 15.2(4)M3 and later release, if a user fails authentication, the configured guest access policies are applied.

Note

The following are the causes of user authentication failures:

- Username, password, or both are incorrect in active NTLM authentication mode.

- Username is incorrect in passive NTLM authentication mode.

- LDAP server is not reachable and the user must make 5 attempts or the configured number of login attempts, before the authentication fails.

Default guest access is enabled by default. However, you can configure the maximum number of login attempts that are required before a user can fall back to the default guest access policy. The default maximum login attempt value is 5. This means that a user must fail five consecutive login attempts before falling back to the default access policy.

To change the maximum login attempt value, configure the following command:

ip admission max-login-attempt 2

While determining the maximum login attempt value, understand the risks of corporate users entering wrong username and password. If the value is too less, some corporate users may be moved to the default guest policy with the multiple authentication pop-up messages. We recommend that you configure a maximum login attempt value of at least two to prevent corporate users from being authenticated as guests very often.

- Session States and Time Between Sessions

- Domain and Non-Domain Users

Session States and Time Between Sessions

If a user fails authentication, that user is authenticated as a guest user by using the configured default guest policy; however the session state will show SERVICE_DENIED. The session will remain in SERVICE_DENIED state for a default of 2 minutes, after which the session is moved to the initialized (INIT) state and the user will be prompted for credentials.

To adjust the time between authentication prompts, enable a watch list and configure watch-list timeout:

ip admission watch-list enable
ip admission watch-list expiry-time 1440

We recommend not to set the watch-list expiry timer to a very high value so that users are not prompted for credentials frequently. Setting zero (time of forever) is also not recommended as the user is never prompted for authentication and will have granular user policies applied.

Domain and Non-Domain Users

Domain users who use transparent Windows NT Lan Manager (NTLM) authentication with supported browsers cannot login to the domain with invalid credentials. Because the device/domain will not let a user login to a network with invalid credentials, the domain will always have the correct username and user group, which ensures that the user always receives the granular user policies defined in the Cloud Web Security portal. If the password of a user expires, the user must log off and relogin to the domain with the new password.

The default guest access policy is available to users who use non-transparent NTLM authentication methods and fail authentication.

The following users are considered as non-domain users:

- Domain users who do not use either Microsoft Internet Explorer or Google Chrome (These web browsers supports transparent NTLM by default.).

- A user who locally logs into a device (for example, workgroup machines that support local sign-on).

- Guest users

During authentication, non-domain users must specify the domain name (cisco\user1) and the password. If a user enters only the username and password, the client PC considers the hostname/computer name as the domain name and the user may not be authenticated, even when proper credentials were given.

For example, a corporate user User1 who uses a Mozilla Firefox web browser (that does not support transparent NTLM authentication by default) belongs to the “humanresources” domain. User1 must log into the domain with the username “humanresources\user1” to be recognized as a corporate user who has access to corporate policies configured on Cloud Web Security. If User1 logs in as just "user1", the user is authenticated as a guest user and only the default policy is applied.

Acceptable Use Policy Aggrement

You can configure the Cisco Integrated Services Routers Generation 2 (ISR G2) to authenticate users who access the web to agree to an acceptable use policy before browsing the web. This authentication helps warn users that their web traffic is scanned by Cisco Cloud Web Security.

Acceptable use policy (AUP) agreement enforcement works with and without authentication. However, the only authentication type supported with AUP on ISR G2 routers is web authentication. NTLM or HTTP basic authentication is not supported.

For users to agree to the acceptable use policy agreement use the Consent feature. For more information, see the Consent Feature for Cisco IOS Routers.

Enabling Nested LDAP for Cloud Web Security

In Cisco IOS Release 15.3(3)M and later releases, nested Lightweight Directory Access Protocol (LDAP) is supported with HTTP basic, Web, and NTLM authentication. With this support, the LDAP client module can fetch both direct and nested user-group information for a user.

An LDAP search query retrieves the authorization profile of a user from an LDAP server to find direct user group members. Each of these direct user groups can be part of multiple groups and thus form a nested-user group.

Perform the following task to enable nested LDAP search:

Device(config)# ldap server server1
Device(config-lap-server)# search-type nested

Configuring the Cisco Cloud Web Security Portal

To configure Cisco Cloud Web Security to work with Cisco Integrated Services Routers Generation 2 (ISR G2), you must complete the following steps in the Cloud Web Security web-based GUI portal:

1. Create a Cloud Web Security authentication key.In the Cloud Web Security portal, navigate to the Admin page and create either a company or a group authentication key. The type of key that you create depends on your network environment. For more information on the type of key to create, see the section “Working with Multiple ISRs”. For more information on how to create keys in the Cloud Web Security portal, see the “Authentication” section in the “Administration” chapter of the Cloud Web Security Portal Administrator Guide.

2. Define Cloud Web Security user groups.If ISR G2 routers enforce authentication and you need to create different web policies for each user group, or configure a different group key for different ISR routers, you must define user groups in the Cloud Web Security portal. You can define the following groups:

- Directory—Directory groups can be Windows Active Directory (AD) groups or LDAP groups.

- Custom—Custom groups enable you to create a group containing any users, regardless of their AD or LDAP group.

In the Cloud Web Security Admin page, create user groups. For more information, see the “User Management” section in the “Administration” chapter of the Cloud Web Security Portal Administrator Guide.

3. Create Cloud Web Security web policies.The Web Filtering Service of the Cloud Web Security portal enables you to create different web policies to enforce acceptable use policies for web traffic. To create a policy, you must first configure web filters and schedules that apply to policies. Web filters control the content coming into a network and schedules determine when policy rules are applied. For more information on configuring web filters, see the “Web Filtering Service” chapter in the Cloud Web Security Portal Administrator Guide

4. Configure the Malware Service options in the Cloud Web Security portal. For more information, see the Malware Service chapter in the Cloud Web Security Portal Administrator Guide.

5. View reports. For more information, see the Reporting chapter in the Cloud Web Security Portal Administrator Guide.

Cloud Web Security Logging Messages

To enable the logging of Cloud Web Security messages, configure the logging command under the parameter-map type content-scan global command.

The following table displays the Cloud Web Security syslog messages:

Cloud Web Security Syslog Messages

Message

Description

%CONT_SCAN-6-START_SESSION

Indicates that a flow is created by the content-scanning process. This syslog message is rate-limited.

%CONT_SCAN-6-STOP_SESSION

Indicates that a flow is removed by the content-scanning process. This syslog message is rate-limited.

%CONT_SCAN-3-CONNECTIVITY

Indicates that the primary or secondary Cloud Web Security proxy server is up or down. When the server is up, the “is up” message only appears after the configured timeout value, which by default is 300 seconds.

%CONT_SCAN-3-UNREACHABLE

Indicates that both the primary and secondary Cloud Web Security proxy servers are down and the content scanning process is disabled.

%CONT_SCAN-3-TOWER-CHANGE

Indicates that a new Cloud Web Security proxy server is selected as the primary server.

%CONT_SCAN-6-WHITE_LIST

Indicates that a flow is scanned by Cloud Web Security because the original client request matched the configured whitelist. The message includes the reason for the client request matching the whitelist. This syslog message is rate-limited.

Sample Configuration of Cloud Web Security on ISR G2s

The following is a sample Cloud Web Security configuration on Cisco Integrated Services Routers Generation 2 (ISR G2) with NTLM authentication:

!Configuring Cloud Web Security parameter-map features
parameter-map type content-scan global
server scansafe primary ipv4 209.165.201.1 port http 8080 https 8080
server scansafe secondary ipv4 209.165.202.129 port http 8080 https 8080
license 0 5D22AA983ABC544AF92F83A51A507262 ---! Enter your license. This is a sample.
source interface GigabitEthernet0/0
timeout server 30
user-group cisco username ciscouser
server scansafe on-failure block-all
!
!Enabling Cloud Web Security on the outbound interface.
interface GigabitEthernet 0/0
description outbound interface
content-scan out
!
!Enabling content-scan whitelisting.
content-scan whitelisting
whitelist acl name whitelistedSubnets
whitelist header host regex whitelist
!
!Enabling a whitelist pattern parameter-map.
parameter-map type regex whitelist
pattern google
pattern cisco
!
!Enabling a whitelist access control list.
ip access-list standard whitelistedSubnets
permit 10.1.0.0 0.0.0.255
!
!Defining an LDAP attribute map.
ldap attribute-map ad-map
map type sAMAccountName username
!
!Configuring an LDAP server
ldap server ss
ipv4 10.0.0.1
attribute map ad-map
bind authenticate root-dn CN=CiscoScansafe,OU=Global, DC=Cisco,DC=com password 0 secretpassword ! optional
base-dn DC=Cisco,DC=com
!
! Enabling authentication.
aaa new-model
!
!Defining AAA group and adding LDAP server to the group.
aaa group server ldap ss-grp
server ss
!
!Defining AAA authentication and authentication groups.
aaa authentication login aaa-ss group ss-grp
aaa authorization network aaa-ss group ss-grp
!
!Defining ip admission rules. Here, NTLM authentication and specific subnet of IPs subject to authentication only are defined.
ip admission name ntlm-rule ntlm absolute-timer 60 list authlist
ip admission name ntlm-rule method-list authentication aaa-ss authorization aaa-ss
!
!Enabling authentication on inbound interface.
interface GigabitEthernet0/1
description inbound interface
ip admission ntlm-rule
!
!Defining  maximum login attempts. A user must fail login 2x attempts before falling back to the default guest policy.
ip auth-proxy max-login-attempts 2
!
!Enabling the ip admission watch-list.
ip admission watch-list enable
!
!Defining a watch-list timer. Users on a watch-list are not prompted again for authentication within 24 hours.
ip admission watch-list expiry-time 1440
!
!Defining a virtual IP address and a virtual hostname for NTLM transparent authentication.
ip admission virtual-ip 10.5.5.1 virtual-host CWSwebproxy
!
!Configuring Cloud Web Security authentication bypass. ACL bypasses defined subnets for authentication only. Cloud Web Security is still applied for these networks.
ip access-list extended authlist
permit ip 10.0.1.0 0.0.0.255 any any ! these subnets have to do authentication
[implicit deny for all others] ! all other IPs bypassed
!

Cloud Web Security Troubleshooting Tips

- Packet Drops with Small MTU Value on Interfaces

- Cloud Web Security Tower is Located in a Different Location

- Host and User Agent-Based Whitelisting Inconsistencies with Asymmetric Routing

- Page Loads Differently After Cloud Web Security Warning Page

- Virtual Hostname Resolves to Open DNS Server

- NTLM Authentication and Browser-Based Authentication Bypass Supports only GET Requests

- Clearing the Cache Results in Credential Requests

- Multiple NTLM Authentication Requests

- Root Bind in LDAP Configuration

- Protecting ISR G2s from Layer 4 Forwarding Attacks

- ACL Logging not Supported with Whitelisting

- Cloud Web Security and Multipath TCP

Packet Drops with Small MTU Value on Interfaces

When you configure a smaller Maximum Transmission Unit (MTU) value size using the ip mtu mtu-value command on an interface in the network, it may prevent web browsing. If the packet size is greater than the MTU size configured on an interface, packets may drop, which prevents web browsing, and the packets are sent with a Do Not Fragment (DF) bit set. This issue happens rarely.

As a workaround for this issue, configure ip tcp adjust-mss segment-size command on the interface along with the ip mtu mtu-value. The value for the segment size must be less than the configured MTU value.

Example:

interface FastEthernet 4
ip mtu 100
ip tcp adjust-mss 55
!

Cloud Web Security Tower is Located in a Different Location

The Cisco Cloud Web Security usually chooses the tower nearest to your geographical location, sometimes a tower may not exist in the same country as the user. In this case, web pages that use localization features or have a local server may not display these features properly.

For example, if a user is located in the United States but the tower is located in the United Kingdom, when the user enters www.yahoo.com, the user is redirected to www.yahoo.co.uk because the returning traffic from the Cloud Web Security tower originates in the United Kingdom.

The workaround for this issue is to enter the county-specific URL. For example, in the above situation, enter www.us.yahoo.com to open the local Yahoo! web site.

Host and User Agent-Based Whitelisting Inconsistencies with Asymmetric Routing

The host and user agent-based whitelisting may not work properly with asymmetrical routing because the returning synchronize (SYN) and acknowledge (ACK) messages take a different path than the initiating SYN message.

As a workaround, use IP-based whitelisting instead of header-based whitelisting.

Page Loads Differently After Cloud Web Security Warning Page

When the Warning option is used, the destination page may load differently than normal after the user clicks “Accept.”

This is a known issue. The functionality of the page is not lost; only the appearance is affected.

Virtual Hostname Resolves to Open DNS Server

If you configure the virtual hostname incorrectly, the virtual hostname is resolved to the open Domain Name System (DNS) server. This issue does not impact the Cloud Web Security functionality, this is a security risk in some circumstances.

To avoid this issue, ensure that the virtual IP address and virtual hostname is correctly configured.

NTLM Authentication and Browser-Based Authentication Bypass Supports only GET Requests

Windows NT Lan Manager (NTLM) authentication and browser-based authentication bypass on Cisco Integrated Services Routers Generation 2 (ISR G2) currently supports only the GET method in the HTTP request. Other methods like POST, PUT, and so on are not supported. The ISR G2 router will close connections if one of the unsupported methods are received prior to the authentication of a user. If the authentication timer expires while a user is completing a form, the form may not be submitted correctly.

To avoid this issue, open another page or link by using the GET method.

Clearing the Cache Results in Credential Requests

When a network administrator configures the clear ip admission cache command on the Cisco Integrated Services Router Generation 2 (ISR G2), all established sessions are cleared for a particular user or for everyone, depending on the configuration. In this case, if NTLM authentication is configured, some users may see additional pop-up messages that requests for authentication credentials. This issue is more noticeable when authentication timers are configured for longer periods of time.

To reduce the number of users getting pop-up message requests for credentials, configure the clear ip admission cache command during non-peak hours. To clear the sessions of specific users, configure their IP address using the clear ip admission cache ip-address command to avoid clearing all other sessions.

Multiple NTLM Authentication Requests

If a virtual IP address is not configured, the NTLM authentication may not appear transparent to users. In such cases, users may get multiple authentication requests.

To avoid this issue, configure a virtual IP address and virtual hostname, and ensure that they are resolvable through the Domain Name System (DNS).

Root Bind in LDAP Configuration

You must configure the root bind command,bind authenticate root-dn attributes available in the LDAP server configuration mode for NTLM passive authentication to work. With NTLM active authentication, the root bind configuration is optional.

Protecting ISR G2s from Layer 4 Forwarding Attacks

The Cloud Web Security connector on Cisco Integrated Services Routers Generation 2 (ISR G2) is prone to Layer 4 TCP attacks.

To protect ISR G2 routers from Layer 4 attacks, configure features like the Zone-Based Policy Firewall or Intrusion Prevention System.

ACL Logging not Supported with Whitelisting

The access control list (ACL) for Cloud Web Security IP-based whitelisting does not support ACL logging. For example, you cannot configure an ACL statement such as the following:

permit ip host 10.1.1.1 any log

Configure ACL statements without the log keyword.

Cloud Web Security and Multipath TCP

Cloud Web Security currently do not support multipath TCP. Devices that use multipath TCP such as Apple devices running iOS 7, the multipath TCP feature may be disabled.

Additional References for Cisco Cloud Web Security and Integrated Services Routers Solution

Related Documents

Related Topic

Document Title

IOS commands

Cisco IOS Master Command List, All Releases

Security commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

Cloud Web Security: FAQs

Cisco Cloud Web Security On ISR-G2 - FAQ

Cisco ScanCenter administrator guide

Cisco ScanCenter Administrator Guide

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here