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:
- Set up a separate proxy port on MWG for this purpose
- Use authentication on that port
- Use Stop Ruleset, not Stop Cycle to create the bypass/tunnel
- Only bypass port 443 traffic
- Only bypass if URL.HostIsIP is true OR URL.HostBelongsToDomain(Skype domains) is true
- Only bypass if URL.Reputation equals Minimal Risk, or Unverified
- Block (or at least continue to scan) all categorized sites other than those that are tunneled or allowed specifically for Skype.
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:
- Internet Services
- Web Phone
- Residential IPs
- Uncategorized sites
- Content Server
- Web Meetings
- Instant Messaging
- Web Mail
Optionally you may want your URL filtering to also allow:
- Web Ads
- Media Downloads
- Social Networking
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
This document was generated from the following discussion: How Do I Selectively Control Skype with McAfee Web Protection?