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.'"
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.
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.
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.
ttuttle is a rankmaniac
No Problem! They promise to DO NO EVIL!
..Oh, Thats not them?
well, maybe if we asked them nicely?
-
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.
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 using openbsd & squid.
Or do a quick search with google.
s/SSL/HTTPS/;
The gist of this article seems to be that unless you're doing complete content analysis on incoming packets, you aren't going to be able to detect Skype: it uses (on my system at any rate) port 443 (SSL?) and port 80 (HTTP) as its default ports. Any sysadmin that blocks those ports is going to get some very annoyed phone calls from pissed off users.
That skype is being devious and sneaky is not the issue here. I think the real issue here is that sysadmins don't have control over the machines they're supposed to be looking after. There are plenty of ways to make sure that Skype doesn't make it onto the corporate network-- don't give unauthorized users permission to install software, blacklist it on the company approved software image, packet analysis... the list goes on. I figure if the sysadmin is not paranoid enough to do these things to begin with, the use of Skype on his/her network probably isn't a major threat. Or the sysadmin is inept. Your call.
... caused some to ponder whether the ever-more-popular Skype hadn't just turned itself into a huge security risk.
The fact that Skype is designed to be unfirewallable is not a security risk: Any site which wants to block Skype should have a policy prohibiting its use.
The security risk is users who ignore such policies, and system configurations which allow said users to install and use Skype.
Tarsnap: Online backups for the truly paranoid
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.
Skype isn't creating a security hole. Skype is demonstrating that current firewalling practices are inadequate for blocking a determined entity from making an outgoing connection.
Perhaps they ought not to do that; I remember similar concerns about SOAP when it was first being proposed (and no doubt many on here still refuse to use it) and it showed that fewer were willing to blame the inadequacy of the protection than they were the people "bypassing" it. Rather, we should take away the lesson that firewalls in and of themselves are not an absolute solution and instead incorporate other methods and practices in developing secure environments.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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.
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.
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.
Learn to love Alaska
Why not rate-limit outgoing TCP port 443? If Skype needs 100 kbps over a connection to maintain unbroken voice output, limit each connection to 50 kbps. You could also limit it to bursts of traffic - full speed for 0.5 second at a time, then 4.5 seconds at 50 kbps. Real HTTPS (small outgoing requests and large incoming responses) would still be responsive under these conditions.
Hands in my pocket
One important reason that Skype should be sneaky is so people using the software under corrupt/abusive regimes can continue to do so without easy interference on the part of the government. In comparison to your intranet's security, the security of dissidents wins.
This is the natural response to to the unnecessary port-blocking that seems to be used everywhere now. Many places block every port except for the few you need for web surfing, so everything runs on port 80. It's sad because it negates the point of ports in the first place.
In the end, I think sysadmins need to learn that users aren't satisfied with only web surfing.
...is another's ticket to freedom.
If Corporate firewalls can't block Skype, neither can China's.
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.
Let me be the first to state the obvious:
Corporate Security should not rely on well-behaving of fourth-party applications/protocols.
Sure, go ahead and demand that Skype's protocol be crippled to improve visibility, but the fact remains that if a random O.S.S. proggie can accidentally breach your perimeter, then your P.O.S. security will not stand up to a script-kiddie, let alone a corporate spy.
Obama likes poor people so much, he wants to make more of them.
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).
If companies want to keep data safe, they need to worry more about their employees and less about obscure ways that said employees might be able to smuggle data out of the network. In my job I have access to files that should not leave the office. I know this, therefore I do not remove them from the office. However, I still have full access to everything on a specific database. If I really wanted to, just like any other employee, I could find a way to get the records out without using Skype. There are cases of credit company employees stealing personal info, and they did not need Skype to do it!
Information wants a fueled airplane waiting at the hangar and no one gets hurt.
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).