Skype Addresses Visibility Concerns

An anonymous reader writes "TechWorld is reporting that VoIP pioneer Skype has finally decided to buckle down from their startup mentality and address some of the concerns about the 'visibility' of Skype by network admins. From the article: 'Problems started around the time that the version 2.0 beta appeared last year, the moment when a handful of software engineers started to assess a troubling issue thrown up by the program's new and evasive design: it was incredibly hard to detect using perimeter security systems. Skype's unofficial explanation for its extreme stealthiness has always been that this was necessary to avoid telcos threatened by its business model from blocking it. While this presents no issues for a home user, using "invisible" software capable of making and receiving voice calls, opening instant messaging sessions and exchanging files on a corporate networks, caused some to ponder whether the ever-more-popular Skype hadn't just turned itself into a huge security risk.'"

Re:ports

[houseofzeus]

Because as a last resort I believe it will use 443, so you would have to block SSL as well. That's why packet inspection is required.

Re:ports

[Oriumpor]

Skype started using the default option "Use port 443 and port 80 for incoming connections" Unless you do layer 7 (basically content based) filtering of those packets you can't see them from regular web traffic.

Re:ports

[ThinkingInBinary]

No. The whole point of the article is that Skype purposefully intends to be invisible and sneaky. The reason is that it makes it easier to run Skype on firewalled and/or NATted networks, either at home or at work. Many home users have convoluted NAT setups, and most don't have the expertise (or reason) to poke holes in the firewall. Skype likes to advertise that it offers Internet phone service that "just works", so they need to make it work on every network. That may mean using random ports, using ports intended for other protocols, tunneling to remote servers or through peers, or other things that can be interpreted as resourceful or sneaky, depending on your point of view.

as a skype user.....

[Roskolnikov]

working in a 'large' corp. network I can say that some skype functionality is blocked, some is not, I can dial out but IM doesn't seem to work;
the behaviour is random but would suggest someone is trying to block it, just not able to do so all the time.

blocking the 'ports' might not be so simple, it can/does use web proxy ports quite well and I can fully see why some would consider it a risk.

its a great product but its allure is certainly that it does work where others are blocked......

just my 10 cents.

blocking skype is easy

[Anonymous Coward]

Skype has done a pretty good job of creating a protocol that works in almost all situations, unlike SIP or many other VOIP technologies. You don't have to worry about NAT full-cone, restricted-cone, port-restricted cone, STUN, or any other crap in a badly designed protocol.

However, if you want to block skype, it is very easy. Have a look at reports [grok.org.uk] using openbsd & squid.

Or do a quick search with google.

Re:ports

[baadger]

s/SSL/HTTPS/;

Eh...

[realmolo]

If you run a corporate network and DO NOT have a firewall that does "full content inspection", then you aren't doing your job very well. Or your boss is cheap AND stupid.

Buy a Fortigate (or Packeteer, or whatever, but Fortigates are good and cheap) and configure the BUILT-IN filter for Skype traffic. Problem solved.

Re:ports

[vbwilliams]

Already been down that road. The only way to defeat it using port 443 as well is to REQUIRE that all SSL'ed traffic pass through a device that can break down the SSL'ed traffic and look at it. You're basically setting up a man-in-the-middle scenario. If that's the case, you have two issues: 1. You need to have a way to decrypt the SSL'ed traffic on the line. That basically requires you to run certificates that YOU control on the proxy host as well as on the end-user's computer. 2. You now have a privacy issue that would become a real pain in the ass at least in the USA in many jurisdictions. Even if you established a policy that allowed let's say going to a banking site to do personal banking during approved hours, you would still have someone legally challenging a company's ability to completely take apart and read someone's supposedly private SSL session. In layman's terms, it means even if I have that padlock in the bottom right-hand corner of my browser, someone upstream who is NOT my bank can see my username and password. This is problematic from a legal standpoint...it has nothing to do with technology.

Blocking is easy, even if not convenient

[AK Marc]

The most effective firewalling technique I've seen was a proxy set up as an internal host, the firewall blocking all traffic other than the firewall or other explicitly approved hosts. Then log all attempts through the firewall and audit those machines. No outbound packets would be send except from approved hosts, everything proxied and logged, all failures and direct connections logged, and nothing allowed in except to the approved hosts. Simple, effective, and pissed off everyone that wanted to run anything they shouldn't.

Re:Traffic shaping

[s_p_oneil]

Skype is very right to want to protect themselves from the telcos, but the IT managers are also very right in wanting to be able to identify and/or block it. It really is a security risk for them. And as I mentioned above (in case you didn't see it), NetSpective WebFilter can identify and/or block it without a proxy. Just plug it in where it can sniff your traffic going to the Internet, set it up to monitor or block, and very much like Skype, it just works. ;-)

Re:ports

[porkUpine]

We can view any SSL traffic leaving or entering our network... been doing it for over a year: http://bluecoat.com/ [bluecoat.com]
We just tell the filter which traffic to allow, and which to prevent (based on our Corporate security policy).