Skip to main content

Skype, is it right for you? Let's take a look.

Recently, I have heard ALOT about Skype, the ability to detect it, and the ability to stop it. Let me just say, I use Skype. I like it, I’ve done alot of communication over it with both domestic and foreign people. I’ve done podcasts on it, etc.. so it’s a great part of the network here. However, this post will attempt to look at the pros and cons of the software and why business should or should not allow it. The decision is up to the reader, I will not make it for you.

What is Skype?
Skype, if you don’t know, is a P2P based VOIP, IM, and file transfer program. It allows:
-Voice Calling to another Skype user
-Voice Conference Calling (up to 10 connections)
-Voice calling to traditional phone lines (this is called “SkypeOut”)
-Voice calling from traditional phone lines (people can call you, this is called “SkypeIn”)
-Chat with groups possible up to 48 people.
-Cross-platform file transfer
-Directory and presence management.

There are some great research papers out there about how to detect Skype, the theory (I say theory because it’s all analysis, Skype AFAIK has never told anyone) of how it works, and such.

The biggest question is, does it pose a threat to my network?  Let's take a look at Skype. 

1.  Skype's code makes heavy use of anti-debugging techniques.  So what?  Skype doesn't want you to look at their code.  Fine.  But why?  I'm not really one for conspiracy theories, but let's come back to this one later.
2.  Skype makes significant use of Obfuscated code.  Again, why.  We'll come back to this as well.
3.  Keeps chatting on the network, even when idle, and even when not a supernode.  Well, this makes sense. Skype has to know who is logged onto Skype to properly display your buddy list.  The client has to advertise it's presence.   All IM clients do this.  Or are the authors of the presentation thinking something else...  The only big point in this is the ability to transverse NAT.  Either during a call or not during a call, this is a hole.  Skype uses keep-alives and what not to keep the hole to your machine through the NAT device you have.  (Take a look at the second paper linked above.
4.  Lack of privacy.  I've argued this point a couple times, and some people don't really care.  Skype uses AES-256 encryption to encrypt all their traffic.  Phone calls, IM's, presence awareness, and even file transfers.  Skype holds the keys.  Big deal right?  Well if you are working for a company that needs to monitor your in and out calls, file transfers, and/or IM's plus even having the right to do so doesn't allow your company to listen.  Skype is there.  You can't do a darn thing about it (or can you?)
5.  Supernodes use alot of bandwidth (question mark)  I say "Question Mark" because it's debatable.  Let's discuss this. First off, a Supernode is a regular client on the Skype network that has a few things going for it. a) it has more than 256kb/s “up” stream bandwidth and b) is not behind a NAT or firewall. A supernode participates in the greater Skype network in the sky by sharing the “contact list” and helping out with the routing of calls. It should be noted here, that I have never found a piece of reliable research that says that “Supernodes carry calls.” In fact, Skype’s own forums say that Supernodes do not carry calls. However, this is one distinction to be made, Supernodes are different from relay nodes. Supernodes carry the global index (the list of people logged into Skype and where they are at). Relay nodes are...

Relay nodes -- Skype, because it has no central “server” to establish calls, relies on the Global Index carried by the supernodes and the ability for one host to directly contact the other. When one Skype user calls another Skype user, the easiest way for this to take place is to directly establish a communication from host to host, from caller to answerer. In the event this cannot take place, the Global Index tells the “answerer”, “hey, try to initiate contact in the reverse direction” from answerer to caller. If that STILL doesn’t work, then the Global Index has a small number of nodes called “Relay nodes”. Relay nodes actually DO route calls between two parties. The Caller and the Answerer both contact the “Relay” node and the Relay node handles the call between the two parties. The important thing for you to remember is that the call, the IM’s, the file transfers, etc are encrypted between the two parties.

In order for Skype to work on your network you need to allow the following things:
1)  Outgoing TCP connections on ephemeral ports. (1024 and higher)
2)  Outgoing UDP packets should be allowed to ephemeral ports. If you are behind a NAT, the NAT device needs to hold your UDP state table for at least 30 seconds.
3)  Outgoing TCP packets should be allowed to 80 and 443. But here is the kicker, they are allowed to go through proxies.
4)  Finally the NAT translation should provide consistent translation.

Now, how many networks out there deny these things?  How about, almost none.

Why does Skype need UDP? Well, if you are reading my blog, your probably know a thing or two about networking, and I should not have to explain that UDP is connectionless. (faster.) You wouldn’t want your voice conversation to be delayed would you?
“Wait” you say. “By running Skype, I allow myself to become a Supernode or a Relay node?” Yes you do. Excerpt from the EULA: “"You hereby grant permission for the Skype Software to utilise the processor and bandwidth of your computer for the limited purpose of facilitating the communication between Skype Software users"” Of course, if you are behind a NAT, firewall, or proxy, the chances of you becoming a Supernode or a Relay node are impossible. Even if you aren’t, Skype has a bunch of both, and they probably don’t need you.
Plus there is explicit ability to shut “supernode” functionality off in the registry (on Windows obviously).
6)  Does Skype have backdoors?  **CONSPIRACY THEORY**  Refer to #1 and #2 above.  Does it have backdoors?  Will we know?  Who knows?

File Transfers -- This is usually the biggest objection to IM, any type of IM. “The ability to transfer files from the network, either to each other, or off network”. Even though this is stupid, and files can be transferred a zillion ways (SSH, FTP, etc.), organizations think that everyone transfers all the “sekret” files using IM, so therefore ban. Whatever. Skype, AOLIM, Yahoo, MSN, ICQ, etc.. all allow you to transfer files, the key with Skype is, it’s encrypted.
So what?
Antivirus scans the file after Skype receives it, so what’s the big deal? I’m not saying it’s good or bad, as I said in the beginning, that’s an exercise for the reader, so I’ll leave it up to you.

So how can we detect it? Well, in true “me” fashion, I am going to use Snort as the example. Snort is made by Sourcefire, the company I work for. We make another product called “RNA” (Real-Time Network Awareness), that detects the Skype application as well (and a bunch of other applications on clients).  But let me stick with Snort.

In Snort we basically have two ways of detecting Skype. The first, and present way is via the rule language. As I said before, Skype is encrypted. So it’s tricky to be able to find these clients. However there are some strings in the initial logon of Skype that we are able to detect.
Because the rules fall under the VRT license, I will not repost them here, but I will talk about them a bit.

The first rule, (5998) is from HOME_NET to EXTERNAL_NET, so we are detecting the outbound initial logon connection, and we tie a flowbit to this initial logon. The second rule, (5999) is from EXTERNAL_NET to HOME_NET and tracks the successful logon of the Skype client, all the while calling the flowbit from the first rule. So, if both rules fire, we have a successful logon.  Can we use Snort inline and "drop" this traffic?   If we block the initial logon of Skype, Skype can't be used.  

Now, both of those rules are TCP. So what about UDP? Can we detect Skype via UDP? The answer is yes, but it's in beta code, we have a Skype preprocessor. This is a public beta, written by Jason Brvenik and we would love some feedback on it. If you’d like to have it, look here. Couple caveats about it, it works on, and has not been tested with the newest Skype clients.

So, the final questions, is Skype Spyware?
In my opinion No.  It does not contain spyware and never has.
Is Skype useful?
In my opinion Yes.
Is Skype beneficial to my environment?
Is it? That’s a determination that only you can make. Do your clients sit behind NAT, Firewalls, and/or proxies? Then they won’t be supernodes or Relay nodes. They are just clients.
Do you have a requirement to monitor all IM, file transfers, and/or voice calls?
If so, Skype is hard. It’s encrypted.

Anything I missed or would like me to research/explain?

Subscribe in a reader

Snort, RNA, Real-Time Network Awareness, and Sourcefire are registered trademarks of Sourcefire, Inc.
Skype is a registered trademark of Ebay.


Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:

Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button