Controlling Skype using App-ID

by vsathiamoo ‎03-28-2017 12:49 AM - edited ‎08-14-2017 02:43 PM (12,529 Views)

What is Skype?

 

Skype is best known as a peer-to-peer IP telephony application developed by Niklas Zennstrm and Janus Friis, also founders of the file sharing application Kazaa and the new peer-to-peer television application Joost.  Skype compliments and competes directly with existing phone services, from traditional POTS to VoIP services. Its major strengths include the ability to provide connectivity through firewalls and NAT (network address translation), support for a large number of active users, and privacy protection via the use of strong encryption. Moreover, it supports integrated instant messaging (IM), chat, file transfer, video conferencing, and a global directory.

 

Skype's underlying technology leverages a distributed peer-to-peer architecture to route multimedia packets among the users as opposed to centralized servers. The peer-to-peer network offers increased connectivity and scalability, and also provides firewall traversal and dynamic routing to evade corporate firewalls.  Despite the fact that it's a closed-source application based on proprietary protocols, The proprietary and evasive behavior of Skype indeed poses a security challenge to enterprise networks, particularly given its ability to transfer files and information without visibility or control.

More about Skype can be found here - https://www.skype.com/en/about/

 

To Allow Skype in your network, the following App-IDs have to be white listed on your Palo Alto Networks firewall:

 

  • office365-consumer-access
  • rtcp
  • rtp
  • skype
  • skype-probe
  • ssl
  • websocket
  • stun
  • web-browsing
  • windows-azure-base
  • apple-push-notifications

 

Create security policies under Policies > Security as illustrated in the screenshot below to allow Skype to function.

 

Screen Shot 2017-03-27 at 10.34.47 AM.png

 

Skype For Business:

 

At a minimum, the following App-ID has to be whitelisted for Skype For Business to function properly. 

 

  • Ms-lync-base (matches the core functionality of the application)
  • ms-lync-online
  • rtcp
  • stun (for media negotiation)
  • rtp (for media streaming)
  • ms-office365-base (core functionality of O365 applications)
  • ssl
  • web-browsing
  • ms-lync-audio/video

 

Some of the standalone clients have pinned certificates. Skype For Business should also be excluded from decryption (you can use SSL decryption exclusion from Device > Certificate Management) and add *.online.lync.com and *.infra.lync.com to exclusion list.

 

Screen Shot 2017-08-14 at 2.43.10 PM.png

 

 

 

Comments
by AlexandrTG
on ‎08-31-2017 03:51 AM

Does any one add URL category ? If we use this rule, then anyone able to surf internet freely. Too broad.

by AndreiSabau
on ‎10-17-2017 04:32 AM

AlexandrTG is right. This allows users to use the "skype" dependencies outside the app-scope. Thus using web-browsing and ssl for regular web browsing, uncorrelated with skype. A workaround is, of course, an URL filtering, but that's a headache as you have to block every url catergory except skype-related ones

by
on ‎10-17-2017 04:42 AM

@AndreiSabau and @AlexandrTG: is web-browsing not used anywhere in your policies?

It is not required to create a standalone policy that summarily allows the dependency applications access out, they can reside in pre-existing policies with appropriate limitations or restrictions.

 

most policies will have web-browsing and ssl allowed for regular browsing, the existence of this common policy is sufficient to satisfy dependencies

by AndreiSabau
on ‎10-17-2017 04:54 AM

@reaper, maybe i have but Skype already has web-browsing and ssl and most of the list above as dependencies. The fact that i have to add them separately means that the client traffic stream correlation fails for this application and it does not match everything this app uses.

by
on ‎10-17-2017 05:15 AM

The mechanisms used by skype to establish a connection currently require these dependencies, because they are so 'plain'. 

 

The way AppID works is by continuously inspecting a session and using it's behavior to identify an application. An accepted tcp session will actually start off as unknown-tcp, then evolve into for example web-browsing when the initial 'get' goes out and then 'windows-azure-base' when the connection apears to go out to azure content delivery network and only after the connection is established and the CDN starts to send skype packets can AppID transform the application to 'skype'. before that point it was a simple outbound browsing session that went to azure.

 

but for each application that gets identified along the way, a security policy needs to exist to actually allow it through, hence the dependencies

 

by Dietrich
3 weeks ago

Can anyone confirm that applying all the Apps above to a security rule allows skype to work correctly?

Ask Questions Get Answers Join the Live Community