Controlling Skype using App-ID

by vsathiamoo ‎03-28-2017 12:49 AM - edited ‎08-14-2017 02:43 PM (38,006 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
on ‎10-26-2017 07:39 AM

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

by mitacs
on ‎02-20-2018 11:35 AM

According to latest Microsoft Skype for Business requiremets (https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Simplified-port-requirements-for-Skyp...), there are UDP ports 3479, 3480 and 3481 that AppID does not correctly identify in the instructions posted above. Port  3479 occasionally gets RTCP AppID in SFBO rule, but mostly STUN from our different rule. We drop UDP ports 3480 and 3481 in one network and allow in another, and so far we have not had any complains from the users in the network where we drop these packets. AppID does not detect these 3480 and 3481 ports as part of SFBO rule at all.

It seems like there is some work left to do on PaloAlto's part.

by
on ‎02-21-2018 04:26 AM

hi @mitacs

 

can you confirm what the sessions on these ports are identified as?

If the ports succesfully identify as RTCP, they should be allowed as this is in the policy instructed above (the RTCP app allows for dynamic ports)

If anything other than 3478 is identified as stun, would you mind collecting some packetcaptures and opening a support case to have this investigated: quite possibly the app-ID needs to be updated to accomodate this behavior

by mitacs
on ‎02-21-2018 05:42 PM

Port 3481 identified as STUN

port 3480 half and half mix of STUN and "not-applicable"

port 3479 mostly STUN from different from SFBO rule and RTCP captured by SFBO rule

port 3478 95% of STUN and 5% of MS-Lync-Audio both correctly captured by SFBO rule

 

What would the best syntax of packetcapture filter be?

by
on ‎02-22-2018 03:43 AM

hi @mitacs

that depends, is this between 2 or more IPs, is source or destination always the same, ...

 

please reach out to support to expedite this

by chyates
on ‎03-23-2018 04:27 PM

and if you're like me, you had a rule allowing STUN that broke this week when it started being classified as Lync.

by
on ‎03-26-2018 05:44 AM

hi @chyates

Sorry to hear you had this issue

There is, however, a way to prevent this from happening:

In PAN-OS 7.1 we introduced a way to disable applications when they are 'newly' added to the application repository through an update, so you have time to review and enable when ready

in PAN-OS 8.1 we added another new feature that allows for a threshold time to be set, so rather than enable/disable, a new app is only activated after X time so you have time to review:

new appID.png

 

PAN-OS 8.1 App-ID new features guide

by RobinClayton
yesterday

We generaly block all "Web Browsing" for all users except via an internal proxy server.

 

Our skype rule with "Web Browsing" breaks this and users can browse any site..

 

If we remove "Web Browsing" from the skype rule will it break Skype?

Ignite 2019
Ask Questions Get Answers Join the Live Community