Skype IM Problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Skype IM Problem

L3 Networker

Hi,

I've some problems with skype instant messaging.

Sometimes the messages are not sent.

Checking firewall logs I see when messages are not sent an 'unknown-tcp' connection is denied.

Same destination port (but different ip) were used and recognized before as 'skype' connection

For example

Time            App         From        Src Port   Source
Rule            Action      To          Dst Port   Destination
                Src User    Dst User

===============================================================================

2012/11/06 11:19:26 skype       Zone1      52682 192.168.xxx.xxx
Skype           allow       Zone212350 78.141.179.16
                user1

2012/11/06 11:19:56 unknown-tcp Zone1  49727 192.168.xxx.xxx
blocca_navigazione  deny        Zone2   12350 78.141.179.12
                user1

It seems that PAN-OS was not able to identify correctly the connection.

For security reasons I cannot open 'unknown-tcp' connection.

Any solutions?

Firewall PAN-500

OS: 4.1.7

Application and threat:  336-1565 2012-10-30

Thanks

Regards

40 REPLIES 40

Yes but the signature could for example be something like (just guessing but as an example):

If skype-probe detected using dstip X and dstport Y and unknown-tcp shows up within Z minutes of initial connection towards the same dstip and dstport identify this as skype-message else identify as unknown-tcp.

That would mean you can trick PANOS : want to use forbidden software at work ? run Skype at the same time and it will be classified as armless connections.

Well unless PA broke the private keys of Skype thats the security problem you will face if you choose to allow Skype to traverse through your network and into the Internet.

Simply because Skype uses encryption and various ways to avoid being detected. For example not using a static ssl certificate or such.

Same goes with windowsupdate which is a similar problem. But in this case windowsupdate uses dedicated server certificates which if the ssl doesnt match the client will refuse to download anything from the ssl terminated server.

L3 Networker

Now here is something strange for you all to wrap your head around: I have the very same problem, but in my case, all communication is allowed (there is a any-allow rule). Messages can't be sent, sometimes they have the status "pending" for forever (while the destination actually receives the message), replies don't come back.

and you have ssl decrypt running in ssl-proxy mode and block those ssl sessions which cannot be decrypted for inspection?

yes and no. ssl forward-proxy but no blocking of sessions (the only thing being blocked in the decryption profile are expired certificates).

I am seeing tons of blocked *incoming* skype sessions though (from untrust to trust). my incoming policy is to deny all. but it shouldn't block incoming skype sessions that are "stateful", e.g. result from outgoing sessions. right?

Ok, this is definitely related to ssl-decryption. I tried from clients that are not decrypted by the PA unit and from there it works flawlessly.

Allowing unknown-tcp is same as not having firewall at all.

Actually we don't use ssl-decryption and we have problems with allowing SkyPe.

We must allow SkyPe for some networks and block SkyPe for some networks. This did work fine before, with CheckPoint firewall and IronPort proxy, all was OK. CheckPoint blocked SkyPe totally, and SkyPe worked true proxy, using 443 port.


But this doesn't work with PaloAlto, v5.0.2.

I have checked the logs a lot, and seems that PaloAlto can detect Skype somehow 50/50. I also noticed, that destination IP -s, that PaloAlto detects as Skype, are sending ton's of packets back, but PaloAlto drops them all. This seems to be a bug.

Some users can't connect. Some can. Some can connect, send messages, but can't make calls, messages are delayed etc.

This is HUGE problem for us.

I tried everything with PaloAlto, even allow only 443 port for Skype, still without luck.


We tried upgrade SkyPe to the latest version, this is even worst for some users, seems PaloAlto can't detect SkyPe 6.1 properly.


I asked to open support case also.


What next?

and at the same time allowing skype with proprietary encryption ...? Does not make sense to me .

Hi ,

I tried to reproduce the problem in our LAB with PA-2020 on 5.0.2 and latest updates, no ssl decryption policy, Windows 8 client and Windows XP client. It is working like a charm. This is how the security policy looks like

Skype-Policy.PNG

and this is the traffic log

Skype-Monitor.PNG

Works what? Blocking or allowing?

If you look at the screenshot of the traffic monitor you see that skype is blocked.

Actually after a couple of minutes skype times out

skype.PNG

Ok, blocking is possible. But I have challenge to allow for some and block for some. So far I can block it for all, but I can't allow for some, as it works with random problems, no messages, voice ok, or no voice but messages ok. And I don't wan't to allow unknow-udp or unknow-tcp.

Unfortunately you cannot block/allow skype for part of the users in the same network due to the nature of skype.... catchword Supernode. But there are some restrictions to Supernode , safest way is to disable the function through registry setting.

https://cs.uwaterloo.ca/twiki/view/CF/SkypeConfiguration

  • 13528 Views
  • 40 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!