Slashdot Mirror
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.'"
You can check for the SSL negotiation messages. So if you have a stateful firewall, its not a problem.
:)
Unless Skype does a basic SSL negotiation too
You could proxy all SSL through a controlled host, and keep regular SSL blocked to maintain some modicum of control over the users SSL use. Otherwise, barring unsavory techniques it's not really supposed to be possible.
I have a very simple policy; if a user wants something on a machine that is outside the core software I support, they have to get my permission.
This policy lasted all of 5 minutes during a meeting with the Senior Leadership Team, who completely ignored what I said and told me, in no uncertain terms, that Skype was going on their laptops.
Personally, whilst I understand that Skype want to be sneaky by design, I'm worried about allowing software on to the network that I can't monitor and disable at will. And as the discussion here has already mentioned, disabling 80 really is not an option.
As the admin of a small ISP's Linux routers I'd welcome very much the ability to classify Skype traffic. We do aggressive traffic shaping to let VoIP and games work nicely when the links are saturated with other traffic (mostly P2P garbage). The current l7-filter protocol definition doesn't work for skypeout traffic and it's not very pretty in general. When Skype decides to offer a conntrack helper or at least l7-filter definitions for their convoluted encrypted protocols I might consider suggesting it to our clients. At the moment we advise them to use other VoIP solutions.
I may have a personal gripe here, but the network admin at my university has a thing for any program except web browsers. Huge tracts of ports are simply blocked off because people set their IRC programs to use those ports. All the popular ports of the Bittorrent programs, every obscure port that some worm uses (he even blocked 443, SSL when he heard a worm used it, but mass complaining removed the block).
It is good that skype uses common ports that can't be blocked without huge reprocussions or fancy expensive packet inspectors. There are bastards out there who would be happy if all their users only used cloned-on-reboot machines with only a web browser. The internet is more than a big blue E (or a big red O)
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
your going to have to go a lot lower than that to kill skype, standard PSTN voice channels use 64kbps GSM uses 14.4kbps and i bet some modern codecs can go even lower. It may still be feasible though.
it would also hurt file uploads and downloads over https (e.g. https based webmail apps) of course you may view that as a good thing and could possiblly avoid it by only limiting connections that had both sigificant upload and download (but then your increasing the complexity again).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I have a post below that references a PDF from Black Hat Europe 2006 called "Silver Needle in the Skype". The authors hacked Skype (the PDF explains how they did it) and exploited a buffer overrun to make it execute their own code. They gave a demonstration where they had a Python script craft a packet that caused a Skype client to launch the MS calculator. Obviously this was a trivial exercise, but it was done to prove a point.
By crafting some simple UDP packets, they were also able to get Skype clients to do a number of unsavory things, such as scout for information from behind a firewall (i.e. IP and port scans on the Skype client's internal network). However, there is more to it than that. Skype can also relay TCP connections to help a client that is blocked get connected to the Skype network. But the relayed TCP connection isn't restricted to carrying Skype traffic, and this makes that feature very dangerous. Imagine what a hacker could do if he could scan your internal network and open any TCP connection he wanted to from inside your firewall. And the only trail you'd have to trace the attack back to its source is virtually undetectable, obfuscated, and encrypted. It should even be pretty easy for the hacker to bounce his connection through several Skype clients in several different countries before it hits the target, making it virtually impossible for anyone to trace it back to the true source (although Skype did such a good job hiding that it's not even really necessary).
to allow your peer to peer software to be blocked.
Really, I don't understand why more companies offering peer to peer software haven't made their traffic use common ports and do NAT piercing. I'm sure this will be a trend in the future.
The fact is that the current model of blocking all traffic until it is commonly used enough that it has to be let through causes some serious problems for uses and businesses marketing networked software. If administers must allow ranges of ports before software can be used, then it makes it difficult to bring software to market. Users are often prevented from using new software that administrators are unaware of.
Additionally, although blocking all incoming ports has obvious security benefits, blocking all outgoing ports except well known ports is pretty iffy. It's not like there aren't plenty of security vulnerabilities in client applications running on port 80... There's nothing about forcing users to keep all their traffic on port 80 that stops them from using an outdated version of internet explorer. Obviously if you think can force someone to use a recent version of some browser or another and no other, you are locking down their boxes entirely and blocking off peer to peer traffic etc, is a non issue.
Making it easy to rate limit certain kinds of traffic is an obvious reason for having traffic on seperate ports, but frankly I see no real benefit on rate limiting specific kinds of traffic over simply rate each ip address on the network.
Some network admins seem to think they can derive what software is critical for someone to use a priori. It may be the case that on some networks http is the only critical software used, but it is my impression that admins seem to assume that this is every network, when the reality is that most schools, workplaces, and public facilities have users who will need to access something like CVS, ftp, skype, aim on the spur of the moment, and their network will utterly fail them because their admins either didn't anticipate the need, or decided that it wasn't a "legitimate" use of the network (as if they could tell ahead of the time what purpose some protocol was going to be used for).