We recommend the use of Zone-Based Policy Firewalls with CWS)
CWS on ISR-G2 Limitation
Guidelines for IPv6 Web Traffic: Admin Guide:
Unless an exception for an IPv6 address, domain name, address range, or wildcard is specified, IPv6 web traffic is sent to the scanning proxy. The scanning proxy performs a DNS lookup to see if there is an IPv4 address for the URL that the user is trying to reach. If the scanning proxy finds an IPv4 address, it uses it for the connection. If no IPv4 address is found, the connection is dropped.
To enable all IPv6 traffic to bypass the scanning proxies, add ::/0 static exception for all IPv6 traffic. This exception makes all IPv6 traffic bypass all scanning proxies; therefore, IPv6 traffic is not protected by Web Security.
|Cisco 800 series ISR||
819, 841M-4X/8X, 860VAE, 880VA, 881, 881W, 887V, 888E, 888EA, 888, 888W, 891, 891F, 891W, 892, 892F, 892FW, 892W, C892FSP-K9, C-881
Cisco 1900 Series ISR
1905, 1921, 1941, 1941W
Cisco 2900 Series ISR
2901, 2911, 2921 and 2951
Cisco 3900 Series ISR
3925, 3925E, 3945, 3945E
Cisco IOS Release 15.2(1) T1 and later releases support CWS. As of May 30th 2014, the most stable image is 15.3(3) M3; however periodically check Cisco.com for the latest updates.
Yes. Presently the images that support VRF are 15.4(1)T, 15.4(1)T1, 15.4(2)T, 15.5(1)T, 15.4(3)M or above.
No. There are no SNMP MIBs for CWS connector on ISR, ASA or WSA presently.
The source interface or IP address is used to poll the CWS tower status using TCP ping on port 8080. This is a mandatory command under the content-scan global parameter-map, with out this command we can’t enable the content feature on the box.
In dual-WAN scenarios, we recommend that you configure a loopback interface and configure it as the source interface/IP address under the parameter-map. In this case, if one link goes down and comes back, there is no impact on the CWS feature. Network Address Translation (NAT) or routing rules must be configured correctly to ensure that the loopback address is routable outside the network. Route tracking needs to be configured to detect ISP failure.
GST stands for Gold Standard Test, This test will make sure that we are redirecting all the traffic to the actual CWS Tower instead of misconfigured or fake IP Address. ISR-G2 sends two special bytes while validating the license which can recognized only by the CWS Tower, if this check fails tower wouldn’t come up.
HTTP traffic is only allowed on ports 80, 81, 70, 84, 210, 280, 488, 591, 777, and 1025-65535. HTTPS traffic is only allowed on ports 443, 444, 563, 4005, and 8443. Traffic from any other ports are rejected by the CWS Tower.
CWS Tower is not capable of scanning the traffic initiated from Andriod/iOS applications. Example: if you have a policy in the CWS Tower, which is configured to block Facebook, that policy will be applicable only for the traffic initiated from the Web browsers. If you use Facebook Apps on Android/iOS, these policies doesn’t get applied which means you will be able to access the Facebook content using those Apps.
Traffic can be directly forwarded to the actual Web server instead of redirecting it to the CWS Tower. Traffic can be controlled by using IP (through ACLs), host-based (using regex), user-agent (Mozilla, Chrome, Safari and so on) user and user-group-based whitelisting.
Header-based (host) whitelisting is best suited for intranet sites. Example: wwwin*; however it is not recommended to block the real internet websites which are dynamic in nature may not give us the desired results.
Whitelisting is nowhere related to authentication, someone expects when they whitelist the traffic that traffic is not subjected to authentication as well, which is wrong, both are orthogonal features. If the customer wants to bypass the authentication they need to associate an ACL/user-agent to the ip admission rule. Please refer this link: https://supportforums.cisco.com/docs/DOC-34596#Whitelisting_optional
Configure only the HTTP port number under content-scan parameter-map configuration for both primary & secondary towers, so that only HTTP traffic is redirected and all the HTTPS traffic will be whitelisted.
Replace the following lines in the config
server scansafe primary name proxy1442.scansafe.net port http 8080 https 8080 server scansafe secondary name proxy1443.scansafe.net port http 8080 https 8080
server scansafe primary name proxy1442.scansafe.net port http 8080 server scansafe secondary name proxy1443.scansafe.net port http 8080
The following are the different types of whitelisting configuration supported on the box in the order of precedence:
No. Authentication methods and CWS redirections are two independent features on the ISR-G2, Users can club these features together for user granular policy. Previously, authentication methods were used to restrict the user access by downloading per-user ACL/Downloadable ACL, However, with CWS solution authentication methods are primarily used for user/user-group granular policy applications.
If an organization has unique IT security policy then configure a single global policy on the CWS Tower using the company key.
If an organization needs different policies for different set of users, then they can deploy any one of the authentication methods like (Webauth, HTTP-Basic Auth, or NLTM) based on their requirements and then configure the policies on the CWS Tower based on the user-groups.
Follow this link to configure webauth or auth-proxy based authentication:
There are two options for AUP.
1. AUP on the ISR side
Yes, AUP is supported using the "ip admission name <test>> consent" command without any authentication using the . Users just need to accept the consent policies (Terms & Conditions) then they are allowed to access the web content, which will be scanned through the CWS towers.
Refer the below link to configure AUP on the ISR:
2. AUP on the Tower side
AUP is supported/tested only with Windows/Linux based connectors. AUP is browser and cookie based. So if the browser does not support 3rd party cookies AUP feature may not work even on the Windows/Linux connector. Since this is browser and cookie based, this AUP on the tower side is not supported on the ISR connector.
Only HTTP requests will be intercepted by the ip admission rule [NTLM/WebAuth] and only HTTP web requests will be triggered for authentication. HTTPS web requests are not intercepted.
If the initial web request from a user is an HTTPS request, that request will not trigger any authentication. As the web request does not have any user granularity, the request will receive the default policy from the CWS Tower. This behavior applies until the user accesses an HTTP-based website. When the user accesses an HTTP request, the request is intercepted by the ip admission rule. After entering valid user credentials the session moves to ESTABLISHED state and subsequent HTTPS web requests will not have the user granularity issue.
In active mode, user validation and fetching of corresponding user-groups as part of authorization are done. In passive mode, user validation is not done; however, fetching of user-group as part of authorization from the LDAP server is carried out.
aaa new-model aaa group server ldap ss-ldap-gr server ss-ldap aaa authentication login default group ss-ldap-gr aaa authentication login CONSOLE none aaa authorization network default group ss-ldap-gr aaa session-id common ip admission name ntlma ntlm ip http server ip http access-class 23 no ip http secure-server ip http max-connections 16 ldap attribute-map att_map map type uid username map type groupmembership supplicant-group ldap server ss-ldap ipv4 10.10.129.204 attribute map att_map timeout retransmit 20 base-dn ou=active,ou=employees,o=cisco.com authentication bind-first interface Vlan1 ip admission ntlma
When you configure the ip admission name http-basic command, client applications always prompt users to enter their credentials. Refer this link:
Router(config)# ip admission name admission1 http-basic
aaa new-model aaa authentication login default group tacacs tacacs-server host 172.31.54.143 tacacs-server key cisco ip http server ip http authentication aaa access-list 61 deny any ip http access-class 61 ip auth-proxy auth-cache-time 60 ip auth-proxy name HQ_users http interface ethernet0 ip address 10.1.1.210 255.255.255.0 ip auth-proxy HQ_users
Configure either ACLs or user-agents and then associate to the ip admission rule.
check this link to configure browser based authentication bypass:
Internet Explorer & Google Chrome.
Starting 15.4(3)M image, support for LDAP source interface has been added. Please refer this link for configuration sample and other details.
Enable the ip http secure-server command on ISR-G2. Once the ip http secure-server command is enabled, all transactions between the client and the router/server is encrypted.
While accessing some HTTPS-based websites some clients might encounter SSL errors/Certificate warnings because ISR-G2 uses a test server certificate when ip http secure-server command is enabled. To avoid these SSL errors/Certification warning, replace the certificate on ISR-G2 with a certificate signed by a certificate authority that the clients trust in that domain.
CWS requires around 10KB of memory per session. 9K session is going to require around 90MB.
Virtual-IP & virtual-host are required for Transparent NTLM authentication. By defining a virtual-host, initial web requests are redirected first to the virtual-host, which is part of the trusted domain. Because the box thinks that virtual-host belongs to the same trusted domain, it does not prompt for the user authentication because the same trusted domain (LDAP) is configured on the ISR.
The virtual-IP & virtual-hostname must be unique in a network and the virtual-host must be a DNS-resolvable address. Do not configure the virtual-IP address on any other devices in the network, including the ISR-G2 and loopback interfaces. If the virtual-IP address is configured on any other interface, while trying to "ping" the virtual-ip address and no response is received from ISR-G2. The virtual-IP address is not ICMP ping reachable; so the virtual-IP address will not ping. Because the virtual-IP address resides inside the ISR-G2, when the client browser is redirected to the virtual-IP (or virtual hostname) the client computer will try to make a Layer-4 TCP socket connection to that virtual-IP address and that connection attempt must be routed to the ISR-G2, so that the ISR-G2 can recognize the IP address and complete the three-way TCP socket connection with the client browser. If the client PC has multiple NIC cards, configure a static route for the virtual-IP to go through the ISR-G2.
NOTE: Transparent NTLM authentication works mainly on Windows. Users must be logged into the same domain as that configured on the ISR-G2. Transparent NTLM Authentication may not work for the smart devices such as (Android-based phones, iPhone’s, iPADs, and so on.)
iOS & Safari do support NTLM authentication, but they do not support Transparent NTLM Authentication. However, if a user enters the username & password for the first time in an iPAD, it will cache that user/password information and use that for any subsequent requests. The user is not prompted for the authentication unless the user manually clears the browser cache. After the first authentication, the user experience will be similar to NTLM Transparent authentication. This is tested with Apple – iPAD2 - iOS 5.1.1 using a Safari browser.
Minor changes are required in the ISR-G2 configuration for virtual-host for the authentication to work. Example: If the virtual-host name is isrproxy and the domain name is cisco.com, then the virtual-host needs to be appended with the domain name. [isrproxy.cisco.com]
This configuration change is required because iPAD's are not generally part of the domain and we need to explicitly append the domain name in the virtual-host to resolve the virtual-IP.
No, we support only single domain configuration.
Webauth works with almost all sorts of authentication servers (RADIUS, TACACS+, LDAP, and Local Authentication). Whereas Basic-Auth & NTLM works only with LDAP.
64 bytes (or Characters)
A single user-group can be up to 64 characters and the total user-groups length together should be 1200, after which the remaining part of the user-group length is truncated and sent to the CWS tower for policy applications.
Upstream devices like ISA may reject packets based on a large header size because of the additional x-CWS headers?
No. There are no such limits on ISR.
Use conditional debugging for content-scan. You can define an ACL and associate the content-scan debug command which generate debugs only for the flow that matches the configured ACLs. Use buffered logging instead of logging console or terminal monitor.
No, accounting is supported only by RADIUS & TACACS+. Only Webauth can make use of the accounting feature that will help to monitor the usage of bandwidth for billing purpose.
Root Bind CLI is mandatory for NTLM passive authentication, without this CLI, the feature will not work. For Active NLTM this is not a mandatory requirement.
Ideally test command should be used in conjunction with "no authentication bind-first".
ldap server ldap_server base-dn DC=aaaldap,DC=com no authenticate bind-first
By doing "no authentication bind-first" and clearing ldap server binding by the command below,
clear ldap server ldap_server
we are making sure, that the first ldap request sent to server is not bind (authenticate request) but a search request (look up request). By ensuring search first, the exact location of user from ldap server is fetched as part of attribute distinguished name "dn". Once that is done, actual bind (authenticate) with user-dn location (not base-dn command in the config).
Now, the "test aaa group ldap ldapuser3 password new" command will work without any error 49 (bad authentiation) messages in the ldap debugs.
That said, for NTLM deployments "authentication bind-first" command is necessary. So, once the "test" command is successful, we need to put the "authentication bind-first" command back in the config.
Active authentication on a browser on an AD server fails because the AD server is trying to protect itself from man-in-the-middle attack when a user uses the AD server to generate traffic and authentication request comes right back to the same AD server.
One can refer these links for further details:
Refer to the discussion with Microsoft support at - https://social.msdn.microsoft.com/Forums/en-US/41adba9a-bf45-4cba-a634-5cbc6bd71054/ntlmv1-authentication-fails-over-ldap-saslgssspnego?forum=os_specifications
Check this link for a workaround: http://support.microsoft.com/kb/914060
Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion.
Yes, it is supported but there is no additional configuration required on the ISR-G2; it is based on the client & server configuration. If the client and server is configured to use NTLMv2 message then the authentication will happen in NTLMv2, or else it will be with NTLMv1, which is less secure when compared to NTLMv2. ISR-G2 cannot be forced to do NTLMv2 authentication.
Yes. We do support LDAP server failover. Based on the LDAP server configuration, an LDAP server is chosen for user validation and authorization and if it fails, it will failover to the configured Secondary LDAP server and so on. If only one LDAP server is configured with no backup and the primary LDAP server fails, then none of the users will be authenticated.
Yes. However, there is no CLI available to specify the nested depth level. It will go and check the last node and fetch all the Nested Groups which may result in significant delays and affect the performance. Be cautious while choosing the Nested Groups option.
When user authentication fails, the user becomes part of the default user-group. If watch-list is enabled those users will be displayed under show ip admission watch-list instead of show ip admission cache. The number of failed authentication attempts can be controlled by using the ip admission max-login-attempt command. Configuring the ip admission watch-list expiry timer command can modify the watch-list session expiry timer.
User authentication will fail even if LDAP server is not reachable for whatever reasons.
Smart browsers these days determine authentication is configured on port 80 and will try to reach the web via some other ports and can entirely skip the authentication and redirection, which is very risky. The solution is to restrict the port number which will have access to Internet either using ACL or firewall. This kind of behavior is mainly observed with BYOD devices.(Andriod/iOS/Windows Mobile)
No, we do not support any of the new protocols, which means we can’t deploy any CWS solution.
Yes, it supports SAML Autentication. With this solution ISR-G2 acts just as a redirection device and all the SAML traffic is considered as pass through traffic; there is no specific configuration required on the ISR-G2, all the configs are done on the IDP, CWS Tower and AD. It is recommended not to configure any default user-group under the parameter-map content-scan global or else it will override the user-group learned through SAML authentication.
Domain users (user-group) may not be fetched with the LDAP query.
Need to tweak the primaryGroupID ( 513 ) in order to get the Domain Users as the memberOf Attribute. Generally it is not recommended to do these changes in the live AD by editing the LDAP Attributes using ADSI edit.
Please refer the following links for this limitation.
CWS Tower allowed outgoing ports are:
We do not support FTP on native port 21, but only support FTP over HTTP.
No, presently CWS does not support SNMP. Meaning, we are unable send a syslog message generated by CWS to the SNMP server.
Please refer this link: https://supportforums.cisco.com/document/147696/ios-scansafe-step-step-configuration
Release Notes for 15.5(1): http://www.cisco.com/c/en/us/td/docs/ios/15_5m_and_t/release/notes/15_5m_and_t/155-1TNEWF.pdf
Whitelist download from Tower (ISR): http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_cws/configuration/15-mt/sec-data-cws-15-mt-book/cws-whitelist-towr-telmtry.html
Whitelist download from Tower (CWS tower side guide):
ISR connects to cwsuploads.sco.cisco.com (184.108.40.206) and grabs the latest whitelist. The cert with the serial no and expiry date of expiry date is Nov 18 21:59:46 2033 GMT
is used to validate the CWS tower side certificate.
The certificate listed in the pool, some of which already expired and some expiring in Oct 2015 should not be of any concern. Those do not related to CWS so, the expiry should not have any impact to CWS service.
TAC UI: This is a troubleshooting feature that has been put in place specifically for TAC engineers to identity traffic patters, CPU and memory utilization on the ISR based on date and time. This is accomplished with the telemetry information that the ISR sends (when enabled) to the tower. There are no public documents for this feature.
No. You can only see the whitelist downloaded using a show command. The command is "show cws tower-whitelist". Refer the guide here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_cws/configuration/15-mt/sec-data-cws-15-mt-book/cws-whitelist-towr-telmtry.html
No they don't. You can only see the whitelist downloaded using a show command. The command is "show cws tower-whitelist". Refer the guide here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_cws/configuration/15-mt/sec-data-cws-15-mt-book/cws-whitelist-towr-telmtry.html
No. Since this doesn't get saved into the startup config (cannot be nvgened) upon router reload, the ISR has to establish connectivity with the tower to download it again.