Selectively Allowing Skype Without Totally Neutering SSL Scanning
I’ve done some limited testing with Skype for a customer that wants to control Skype usage. Allow for some users, block for others. This is tricky, but it can be done with MWG alone, and the addition of McAfee Client Proxy (MCP) provides as good a solution as is currently possible. Note: there is no way to allow Skype either selectively, or as a whole, without opening significant security holes in your web protection. The problems are that Skype port hops, is resilient in that will try any means it can find to get out, does not always conform to HTTP and HTTPS protocols, and uses peer to peer connections. In a purely transparent proxy environment, it likely will not be able to authenticate itself.
If you want to block Skype completely, don’t allow clients direct out through the firewall and enable SSL scanning on MWG (at least for Internet Services Category). You can also block Skype in SaaS by enabling SSL scanning for at least Internet Services, although most admins would likely only want to block it when users are on the corporate network.
Regardless of proxy mode, MWG will break Skype if SSL scanning is enabled, so you need to tunnel (bypass scanning) for uncategorized sites and other sites that Skype uses. Tunneling HTTPS requests can be done by category using rules that bypass the SSL Scanner ruleset. Make sure you include reputation, category, authentication, protocol, and URL.HostIsIP as part of your bypass criteria, to minimize the impact of neutering SSL Scanning. Authentication criteria can be applied assuming the request has been authenticated before it hits the SSL scanning ruleset.
With just MWG in play, to allow but control Skype, you really should use explicit proxy if you want to restrict access via authentication. This requires reconfiguring the Skype client (usually by end user) to use the proxy and to authenticate. If the explicit proxy approach is taken, it is recommended that you:
Note that Skype can use a different proxy port than what the user uses for general web surfing. You could even have the proxy drop everything on that port other than HTTPS traffic. The intent is to have this port be used for only Skype traffic directed to MWG by explicit proxy settings in the Skype app. You don’t want users to be able to use this proxy port and its permissive HTTPS rules to bypass your standard filtering for their regular browsers. User-Agent based blocking could also be implemented to further control use of this port.
Things get a little better when using MCP and control doesn’t require the end user to muck with their Skype settings, since MCP transparently intercepts the Skype traffic, directs it to the cloud or MWG, and supplies the authentication information.
With MCP you can bypass by process (skype.exe) and then open your firewall to allow port 443 direct. This method is not recommended, because allowing any client to go direct out on 443 opens a huge security hole, unless you can restrict the firewall rule to only allow client IPs that have MCP installed.
Alternatively with MCP, you can keep MCP enabled for Skype and use MWG (and SaaS) tunnel rules that limit access based on MCP authentication and port (on MWG). With Hybrid III (as of this writing in controlled release , allows synch of most MWG rules to cloud)these rules should be available for use in the cloud (except the proxy.Port property). Until then, there is a different set of rules that are required to allow Skype in the cloud when SSL scanning is enabled.
For MWG, at a minimum, tunnel (use Stop Ruleset, not Stop Cycle) Uncategorized Sites (can be done by matching categories to an empty list) and Web Phone, Internet Services, and Residential IP Addresses. Content Server should also be added if you want the Skype Home Page to work properly. Other bypasses can be done in the URL category filter to prevent blocking of other content (this content is not required for operation though). Note that tunneling eliminates the possibility of scanning any content, so users that are allowed to use Skype will also be allowed unfiltered HTTPS access to any site that matches the tunneled categories, including uncategorized sites. Furthermore, files and URLs transferred via Skype will not be scanned or filtered by MWG or SaaS.
For complete operation, I recommend allowing the following categories to bypass SSL scanner:
Optionally you may want your URL filtering to also allow:
Allowing these categories in the URL filter is not nearly as dangerous as tunneling because you can still run anti-malware on the return content and often many of these categories are allowed anyway, certainly for users allowed to use Skype.
For SaaS (without Hybid III) my settings for the applied policy enable Theat Protection and block Medium Risk and High Risk reputations and turn on anti-malware. SSL is enabled but not for the SSL scanner bypass categories listed above. My Category filtering allows the SSL scanner to bypass categories, as well as the optional categories listed above. Skype functions work when using this policy and Skype Home works.
My MWG policy is a bit more complex, but basically does the same with a little more restriction. MCP Authentication should already be above SSL scanner. If you are using explicit proxy instead of MCP, put your authentication rules before SSL scanner. The Skype Bypass Rule is the key to making Skype work with SSL scanner enabled.
[Ruleset for SSL scanning.]
If SaaS and Hybrid III (controlled release) are not involved, I recommend adding a proxy port restriction as well.
The other key is additional allows by category for sites that Skype uses while conforming to the HTTP/HTTPS protocol and still enabling filtering for those sites. These are required if you use the Stop Ruleset for SSL Scanning bypass, as recommended.
Stop Rule Set
URLs which categories are contained in this list are allowed
Allow Skype URL Bypass Categories and Skype Tunnel Categories for Skype Authorized Users and Skype Authorized User Groups
Stop Rule Set
Block Everything Else for Skype Authorized Users and Skype Authorized User Groups
Skype Host domains need to be added to allow Skype Home to work in explicit proxy configuration. They are not needed for MCP-sourced traffic.
I haven’t tested extensively, and Skype could change how it operates, but it appears that MCP opens up some additional options for customers wishing to control or limit Skype usage without completely blocking it or asking users to change their configurations, or just opening up a huge security hole in your firewall.
Feedback welcome, these rules could probably be refined further, but are certainly much better from a security standpoint than just turning off SSL Scanning entirely, for everyone, or just limiting SSL bypass by category and/or URL.HostIsIP property is true.
My testing was done with MCP 1.2, MWG 7.4.2, Skype 184.108.40.206
As always, posts to this forum by McAfee employees do not imply that the solutions are approved, endorsed, or supported by McAfee.
Above provides the rules necessary to modify your existing rulesets. Here are rulesets from the 220.127.116.11 ruleset library modified as per above. No guarantees of accuracy or correctness but should help get you started. Suggestions, and edits welcome.
I suggest to restrict the ports in network protection then you will see that the port restriction will force the traffic of Skype passing through SSL scanner so it will blocked because of anomaly use of traffic.
I did it in my lab and it is worked.
Correct restricting ports and enforcing SSL scanning will BLOCK Skype as stated in the beginning of the article. Network protection rules only apply if you are deployed in a transparent bridge or transparent router mode. The point of this whole article is for selectively allowing Skype. Skype is easily blocked, with proper network configuration regardless of deployment mode (see paragraph 2).
Excellent info. I already read it and I chose that part which I did in my lab in reply. BTW thanks for this useful Document and also Rules.
I'm a little worried about
I tried to capture some skype connections and I never find a Domainrequest? Did I miss somehing?
As far as a I know, skype in a explicit proxy environement tries to connect to a dedicated microsoft skype server. It tries several IP until a connection is established.
Why don't you restrict the bypass to ips out of a list with well known skype servers?
Otherwise any SSL IP Only Request will bypass the normale rules....
As far as I can see the only connection which must be not intercepted is the one to the server.
This connection is open (more or less like a tunnel) as long as skype is open.
All other requests might be ignored.
Tell me if i'm wrong. I tried this on our test proxy and it works for us without any restrictions.