With Maite Cadenas Sanchez
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about the Cisco Cloud Web Security on ASA with Cisco expert Maite Cadenas.
Cisco Cloud Web Security, formerly called Scansafe, provides exceptional threat protection and control for organizations of all sizes, delivered through the cloud. ASA is one of the transparent connectors you can have with Cisco Cloud Web Security.
Maite Cadenas is a service delivery manager (SDM) for the Cisco Cloud Web Security solution for the EMEAR region. Her work involves helping customers to implement the CWS solution in their environment, making sure that they have the support needed during the implementation and as a first technical point of contact. Prior this role, she was part of the Brussels Security Team in the TAC Center that helps customers troubleshoot Cisco security technologies. She holds a master's degree in telecommunication engineering and a bachelor's degree in networking technologies from Universitat Enginyeria i Arquitechtura la Salle. She also holds CCIE certification in security (#26075) as well as ITILv3 Foundations.
Remember to use the rating system to let Maite know if you have received an adequate response.
Maite might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation in Security community, sub-community, Firewalling discussion forum shortly after the event. This event lasts through January 31, 2014. Visit this forum often to view responses to your questions and the questions of other community members.
First of all thanks for taking the time to answer all of our questions
Now here are the questions I have at the moment.
I can see there are 2 different types of key:
Company Authentication Key and the Group Authentication Key.
Are both required? Or can I just simply use the Group one or Company one?
I can see they both do the same (Enable the Cloud Web Security Feature) but the Group one actually identifies all traffic from the ASA to be sent to the ScanSafe tower.
2)How does the firewall determine which SSL packets not to redirect to the ScanSafe cloud?
I mean How does the firewall inspect the HTTPS traffic in order to determine whether the traffic should be redirected or not as I have not seen in the past the ASA workings as an HTTPS Proxy.
Thank you for your questions.
1) Regarding your question about the keys, indeed there are 2 types of keys, but you only need to use one, which will be the license that is requested when configuring scansafe feature (CWS) on your ASA.
server primary ip [PRIMARY PROXY IP] port 8080
server backup ip [SECONDARY PROXY IP] port 8080
license [AUTH KEY]
You can make the choice which one to use:
- Company key: You can only create one per portal
-Group Key: You can create as much as custom groups. This offers more granularity.
You can read more information about the advantages of each one in the following link:
2) Regarding which https traffic to redirect, it does it based on the policy map configured for it.
In the following "ASA. Scansafe step by step configuration guide", you can see on step 2 that you define an ACL to match all https. If you would like to match it for specific networks only you can make the ACL more specific.
Also, it exist the possibility to whitelist some traffic. You can find more information how to do it in the following video:
Hope that helps.
First thanks for the answer
Regarding the SSL one.
Yeah I know it's via the MPF setup but that was not my question:
I mean is all of the SSL traffic being redirected or can I say only SSL traffic to facebook for example?
If the facebook option (example) is used how does the firewall determine that facebook is inside the SSL payload as ofcourse goes encrypted.
ASA is only redirecting the https by adding the scansafe (CWS) header in front of the https traffic, by looking the L3 and L4 (in this case https) information that is matching the traffic specified by the ACL on the MPF.
ASA is not inspecting inside the SSL traffic since, as you said, of course goes encrypted. The https inspection is done in the cloud. And you need to make sure that you have perform all the steps to enable https inspection on your CWS portal.
The most common scenarios I've seen is to send all the traffic with destination to port https (and just limiting the source network on the MPF ACL) and then of course adding some whitelisting.
Here you can see an example of whitelisting based on source and destination networks.
Have in mind that, regarding whitelisting with https traffic, ASA (firewall) won’t be able to decrypt HTTPS traffic, and whitelist can only be done via IP Address/Subnet.
Let me know if that answers your question.
I need some help please. My question is if I have an issue with CWS, how do I know if the issue is the ASA or in the cloud? Look forward to hearing back from you soon.
Thanks for your question.
Indeed, it is important to be able to narrow down were is the issue. Specially if you need assistance and open a TAC ticket to get quicker to the right team (ASA team or CWS team) to troubleshoot the issue.
In the following link there is a good troubleshooting guide and you can find a section "
Distinguishing Between ASA and CWS Proxy Problems": Basically the idea is to bypass the CWS on ASA and define CWS as explicit proxy on the browser of the user.
- If after specifying the the explicit proxy on the browser CWS works, and before you were having an issue, then the issue is pointing to the ASA.
Also some other tips to have in mind:
NOTE: CWS (Scansafe) towers do not reply to ping (ICMP), therefore that wouldn't be a valid test and you need to test the connectivity. A valid test would be to test the TCP connection on port 8080 to the proxy tower. For example:
- When testing explicity connector: telnet
- When testing from ASA: ASA#ping tcp
Also, in case you need to open a TAC ticket, it will be useful to provide already the following outputs:
1) Show tech
2) show scansafe tower
3) ASA# ping tcp
4) show service-policy inspect scansafe
5) show scansafe statistics
6) Any logs you have collected at the moment of the issue.
From testing PC:
Screenshot of the errors you are getting
Hope that helps
Good to see you are talking about this; I'm wondering how and what I need to open the ScanSafe account in order to configure the policies. I have found the info to configure the ASA, and to configure and modify the content filtering policies once in the portal; but I do not find any info on how to get the username and pass necessary to login into the portal.
To have access to the CWS portal, you need to order CWS licenses or you can also request a 45-days evaluation.
To know the details about how to request it, please kindly check in with your local Cisco Security/Content Sales, and they will be able to assist you further with that.
If currently you don't have a direct contact, please, check the following link, section "Let Us Help"
Hope that helps,
I've recently implemented Cloud Web Security on a 5505 for a client, and the HTTP filtering appears to be working fine. However - when I enable the HTTPS redirect to CWS in on the ASA in the service policy rules section - users attempting to visit HTTPS sites that are being blocked (based on category such as "Adult" in the CWS portal) are simply receiving a generic "unable to load webpage" type message instead of the message from CWS stating they are being filtered like they do for HTTP pages?
Do I need to enable HTTPS inspection and push a certificate to each end-user device for for this to function correctly? I was under the impression that HTTPS inspection was not necessary to simply block/allow sites based on their URL and was only necessary if one wished to block content IN those sites, if that makes sense?
Still learning about this product - appreciate any assistance/insight! Thank you.
Thanks for posting this question.
In short, yes, to get full extent of HTTPS block page, HTTPS Inspection needs to be enabled, and certificate needs to be pushed down to all user’s certificate store.
Below is an explanation:
- User experience when HTTPS inspection is enabled
If HTTPS inspection is enabled, the browser will establish the HTTPS connection with the CWS service using the details provided by the auto generated SSL certificate. Once the HTTPS session is established the website request can be blocked and the user block page successfully displayed within the HTTPS session.
- User experience when HTTPS inspection is disabled
When a user attempts to access an HTTPS website, which is a blocked, the browser will display an error message and not the block page. The browser displays the error message because the HTTPS connection was terminated before it could be fully established. This is not a fault with Cisco Cloud Web Security. It is expected behaviour for any web security solution that blocks an HTTPS request without having an HTTPS inspection capability enabled.
The error is displayed because the HTTPS session was terminated before it was established. The session was terminated to prevent encrypted content from the website being allowed through to the browser as specified by the web policy. The browser ignores any content returned outside the HTTPS session and this is the reason the block page cannot be displayed.
In contrast, when HTTPS inspection is enabled the block page can be displayed because (a) it allows the HTTPS session to be established and therefore doesn’t cause the browser to display an error (b) because the session has been established the block page can be returned to the browser within the encrypted HTTPS session and isn’t ignored, it is trusted and displayed.
Note: legacy browsers may exhibit a different behaviour from that outlined above. In some cases these less secure browsers may allow the block page to be displayed.
Hope that helps.
Thanks for answering my question. Another quick question for you. Is CWS supported in multi context? Really appreciate your help.
Thanks for your interest on this topic.
Yes, CWS (Scansafe) is supported in ASA single and multiple context as well.
One thing to have in mind is that when configuring it in multiple context mode the CWS server configuration part is done only in the system context mode and the MPF config is allowed only in the user contexts.
You can read more details about it in the following link and also see the configuration examples.
Hope that helps