Slashdot Mirror
How Skype Punches Holes in Firewalls
An anonymous reader writes "Ever wondered, how P2P software like Skype directly exchanges data — despite the fact, that both machines are sitting behind a firewall that only permits outgoing traffic? Read about the hole punching techniques, that make a firewall admin's nightmares come true."
I'm impressed, this is really good stuff. The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established. Is this technique being used or considered by any P2P apps? I've run into the situation several times where I'm firewalled, and the only seeder of a torrent is too.
LOAD "SIG",8,1
There's really nothing new, or special about this technique. Definately nothing to 'keep firewall admins up at night'. Its the same thing that Kazaa did, and Napster as well. Establish connection to a central server, central server informs each client of the others client ip address, each client connects out, NAT router sees outgoing connections to that host, and allows data in. Nothing new, or exciting.
I wish my nintendo DS did this, so I could play metroid at work.
This isn't an exploit. If the admin's didn't want the firewall to forward ESTABLISHED/RESPONSE packets, they can take that capability out...One of the things I've always had issues with, with regards to commercial firewall software (e.g Zone Alarm/Windows Firewall) is that that capability usually ISN'T enabled, so I'm forever getting "APPLICATION IS TRYING TO CONNECT TO THE INTERNET" pop-ups.
If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they're established or UDP or whatever. The article represents this like it's some kind of l33t hacker tool to break down a firewall from the outside, rather than the same problem you'd have if you downloaded a trojan, or some internet-connecting spyware.
Very misleading.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
From my understanding they're not talking about "hole-punching" firewalls but only about plain boring NAT traversal, which is anything but a new topic...
@neonux
Actually, a paraphrase. "Skype interprets firewalls as damage and routes around them."
I don't exactly think this is Skype being tricky, it's just having users establish connections and keeping them open for incoming calls. This is the same way that Instant Messaging services such as AIM work too. If the admins don't want those services enabled, they should inform their users and then block Skype IP ranges.
Crack - Free with every butt and set of boobs
While this is a cool technique, I had heard about NAT2NAT years ago... This is not a new technique, by any means.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Ever wondered, how to use, commas properly?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
didnt know skype was UDP based. Most do wonders to the quality of the network. Esp if there are bugs in the protocol being used. I remember the standard project where you need to implement sliding window and AIMD on UDP to mimic behavior of the dominant TCP variety. I also remember what happened when some kids messed up and started flooding the network with packets.
The war with islam is a war on the beast
The war on terror is a war for peace
This isn't some earth shattering revelation. A good explanation for a layman, but nothing new.
Skype is starting to charge now, so that means everyone will be migrating to the next thing that is free.
I sort of miss the dialpad.com days.
anime+manga together at last.. in real time.
So I guess you can say Skype is the #1 STUNna?
And this is new news how? Nothing to see here folks, move along.
Here is another good discussion (PDF): http://www.rootsecure.net/content/downloads/pdf/sk ype_protocol.pdf.
in tight network conditions (no routes for outside, only application-level proxies have connectivity)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they're established or UDP.
And how are you going to receive replies if you tell it to drop the response packets?
The trick that this article points out is that UDP is connectionless, so even a stateful firewall will not know whether a packet is a valid reply or not. The only way to prevent this is to block UDP entirely.
___
If you think big enough, you'll never have to do it.
NAT2NAT does not "punch" as much as it "snaps" together. But it must be a slow news day and we haven't had a daily regiment of FUD.
Funny, and I'm the one with BAD KARMA.
I'm sorry, I'm not up on UDP, but isn't there a step more than there needs to be? Specifically, if Alice tried to contact Bob -- which she does -- then she would be waiting for a response, and her firewall would therefore be open to his response. But according to their diagram, Bob's response to this will be disgarded by Alice's firewall. Am I confused, or is this just bad diagramming?
...is deep packet inspection. Instead of just letting packets thru based on "I'm just returning so-and-so's request", look to see what their payload contains and what type of stream it is. Yes, encryption can hide the payload. But, you can still prohibit non-SSH/HTTPS/SFTP streams from originating. If it isn't an approved protocol, make it go away.
Want to REALLY torque off the Skype guys? Let it thru, just add random packet delays to each UDP packet that goes out and comes in. A few ms each should do it. Their call quality will go to hell. Things like mail, web surfing, and other non-realtime protocols won't even notice the difference.
Charles
Learning HOW to think is more important than learning WHAT to think.
"Nightmare come true". What sensationalism. This is just STUN, which SIP communication devices can also use:
http://en.wikipedia.org/wiki/STUN
What are the available Skype alternatives and how do they compare to the real Skype itself? Now that they are gonna end the `free ride' to US and Canada destinations, it ripe to begin looking at alternatives.
Is this just the same thing as STUN (Simple Traversal of UDP through NATs)? The technique described in the article sounds simpler than STUN, but similar in concept. (SIP uses STUN, right?)
I've also heard that what Skype does is somehow better than STUN, though it's hard to see how. Can anybody confirm/deny/explain that?
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
Oh man, this shit is a pain in the ass. I had to look into the over the summer. This is the same technique that Apple's iChat uses for audio and video calls. Many many p2p applications use this technique to get through firewalls and NAT routers. The problem is that it doesn't always work when both computers are behind their own NAT router.
Let's say Bob (as in the example in the article) is behind a NAT, his local ip he got from his router via DHCP is 192.168.1.2, and the public IP of his router is 2.2.2.2. He wants to use UDP port 2828 on his computer to transmit his voice data to Alice. So he sends out the first packed to 1.1.1.1:1414, as in the example. Now because of his NAT it looks like the data is coming from 2.2.2.2 and some arbitrary port (the router can't always use the same source port as the NATed computer because some other computer on the local network might already be using that port to connect to the outside world) lets say his router uses 3939.
Now Bobs router says, "Okay, I'll let through any UDP packets sent from 1.1.1.1:1414 to 2.2.2.2:3939 and I'll pass them on to 192.168.1.2:2828". As in the example, Alice's router will just drop this packet because there is no pre-existing connection from Alice's computer using this info. Then when Alice tries to send a packet to 2.2.2.2:2828 Bob's router drops it because his router isn't expecting traffic to this port. His router is expecting packets to go to port 3939. And Bob has no way of telling Alice which port she should actually be sending packets to since he doesn't even know which port his router decided to use on the public side to send out his packets.
You can get around this if only one computer is behind a NAT, or if you open up a persistent connection through your router to your computer. Anyway, I believe UPnP is supposed to help with this somehow, but I got so sick of it that I switched jobs.
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
Today must be a REAL slow news day....
When the only tool you have is a hammer, every problem looks like a nail
Although the author of that article tries to make it seem like this is near unstoppable, there are actually several feasable methods by which this can be stopped. 2 off the top of my head. Install an IPS. An IPS can do a deep inspection of the packet no matter the port and identify/block unwanted traffic. When Skype servers are used as a form of proxy there are several options. A)Have the firewalls block Skype IP addresses. B) Decrease the timeout value for UDP packets on the firewall.
As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article. There is also a simple, cross-platform and open-source library available that implements the server and client side techniques, making it very easy to integrate this technique into other projects. Nonetheless, the article makes for a nice and simple description of the technique.
should be trivial to make netfilter randomize source port for every nated connection.
I always thought of firewalls as being some variation of a rectangle myself, so getting round firewalls would seem to make them easier to circumvent. But if the holes they are punching are round, wouldn't the round firewalls just plug the holes?
UDP is connectionless so you can send a packet and get a valid reply in a microsecond or a year depending purely on how long the app is willing to wait. So how long with the NAT router wait before is prevents a UDP reply packet crossing the barrier back to the sending app?
This is not hole punching, and not a security risk.
It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.
The issue only arises because both parties are firewalled.
The short version: Using a 3rd server that both parties can connect to cleanly, the behavior of UDP is analyzed to see if source ports are static or predictable. If they are, it's trivial to have both hosts send packets to each other causing both firewalls to permit reply traffic, at which point direct communication between hosts over udp is possible.
This is easily overcome by randomizing source UDP ports at the nat layer.
Wouldn't it be great to live in a world where the network admins were here to HELP us instead of fuck with us?
Next asshat who tells me Sarbanes-Oxley forbids (fill in your favorite app) is going to get flogged with a cluebat.
You know it doesn't have to be new to be a security issue, right? There are mitigating controls, but at least 73% of companies don't actively control these protocols.
The problem is not the "firewall." The problem is needing one in the first place. The world will be a much better place when 73% of companies take the mitigating control of dumping Windoze.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
... but its a little more tricky. We figured this out during our senior design project (a video communications system) - all we had to do was have the server start a TCP connection to the client over static source and destination ports, trash the connection before reset/fin packets could be sent and then turn a server on the source port. The NAT we were using would then let an incoming connection come on through to the server. With UDP its a whole lot easier, but it still can be done with TCP as well.
I know you can punch holes for bit torrent, at least if you are using Azureus, as long as you setup your router to port forward/trigger to a particular UDP/TCP port.
Logs into linux box jacked into the core once a day and fires up iptraf...oh look udp traffic from
worstation whatever. Sysadmin totally blocks user at firewall, only way to get internet back is to
call Sysadmin. Sysadmin makes user remove skype from workstation before he reconnects them. Simple
solution to the problem, network is happy again without a crap load of useless traffic blasting
across it.
Samy, the guy involved with the MySpace worm, wrote some Perl to do this a while ago:
http://samy.pl/chownat/
Score:-1, Funny
If you're setting up port forwarding in your router, the application isn't "punching holes" you're just opening up your firewall at the router...
Should take about five lines of code to fix, in any firewall that really want to.
surely the answer is to block the clients from making the initial connection to the skype server? surely someone must have a blocklist available of the skype servers.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
As others point out, the technique has been used for many years.
It's not even a real solution. The article says:
Really, always? Why do you know this? Because you tested it with your one client and the particular version of the one OS you use?
That's the problem with this technique: it might work for some or even most NAT implementations but it cannot always work. Because NAT means that the source address and port of all outgoing packets is re-written. The NAT box is not required to follow any pattern in how it assigns the source port numbers for NAT'ed packets; in fact a good NAT box should not allow the ports it uses to be guessed. Of course the OpenBSD packet filter chooses outbound port numbers in a random (cryptographically strong if you have the appropriate hardware) manner, and this technique will not work if one of the packet filters is OpenBSD. (I don't know much about the other packet filters.)
Sure, for a freebie like Skype, who cares if if the thing only works "most" of the time? But this is not a solution, it's just relying on undocumented behaviour of some NAT implementations.
Unlimited growth == Cancer.
This is really ancient stuff. I worked extensively on NAT traversal in 2000, and even that it wasn't a terribly original notion. The article also glosses over many of the numerous subtle differences between off-the-shelf routers/NAT devices - there are far more accurate and informative articles available.
I was impressed too when I read about it several years ago. Really, this is very old news. The P2P VPN tool Hamachi uses the same system.
D 6305E49CC2570A1001698C0
AFAIK Skype uses a fallback system when the technique described doesn't work (where UDP traffic is blocked). In those cases it uses a well connected peer (yes, that could be your Skype client) to relay the voice data to the other party. Your PC becomes a Supernode without your knowledge and consent. Well, not really, coz this is in the Skype EULA:
4.1 Permission to utilise your computer. In order to receive the benefits provided by the Skype Software, 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.
http://computerworld.co.nz/news.nsf/news/7AB67323
What was it again? All your base belong to us?
X.
http://www.ecip.com/fwdoc.htm
We had it in our one of our livecam video streaming product in 1997
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
The "firewalls" are stupidly allowing packets to come back in from any source.
No, they're letting packets back in from any source to which a packet has been previously sent. One of the first two packets sent by the clients will be dropped, but the others will all go through fine.
Not that this makes it anything other than a stupid way of setting up a firewall if you're trying to regulate what protocols can be used. And if you aren't, what's the big deal?
Once you have a bi-directional UDP packet exchange going, (it's not a connection like TCP) but it is in some sense an unreliable connection.
/dev/tap or /dev/tun) , or use a user space TCP stack connection or use something like my ECIP (http://www.ecip.com/) over it.
You can then route TCP over it (grab packets from
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
The article is not scary but is a good reminder of the different ways a network's security can be circumvented. This HTTP-Tunnel should keep everyone awake at night!
Regards,
a non y mouse
yes, and you can steal the crown jewels, as long as the queen willfully gives them to you!
Who needs to let UDP out anyway? We have DNS server. We have a proxy server. As a matter of fact we let nothing out.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
If a program can do this, can a virus or trojan could do this as well? Now people think: I am behind a firewall, so I am pretty safe, yet this prooves that it is possible.
Isn't Skype a proof of concept?
Don't fight for your country, if your country does not fight for you.
Right, and if an admin gives full-control to the local firewall to the local user then his nightmares should be about his shoddy work, not apps requesting an open port. Something tells me heise security doesnt sell too many impressions or get on the front page of slashdot without all the alarmist language.
The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things
Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.
Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I'm behind a firewall that I don't administer and haven't bothered requesting anything regarding opening ports for voip. My provider is vbuzzer. Their program works in windows without issue, I can make and receive calls. But I use linux, on the linux side, the only one that works is linphone. The others I have tried are kphone, twinkle, ekiga and even asterisk as I liked some features in some of the other clients (but linphone has got much better). Anyway all the others only allow me to make outgoing calls.
I've submitted bug reports to ekiga (nothing done there so far) and tried to get devs interested with asterisk but no go. So what's linphone doing right that every other voip client on linux doing wrong? I'd really like to know to point it out to the other devs.
I assume that more than a few botnets will use this for command channels, if not to deliver payloads. So did the botnets learn this from Skype et al, or did Skype, etc. learn this from botnets?
If the latter, the only useful thing to come from botnets is this slick trick. Of course, as useful as teaching the telemarketers to use wardialers.
-Rick
deleting the extra space after periods so i can stay relevant, yeah.
if you listen to Security Now podcast, this is only true for well behaved firewalls because they re-use the same port after the first transmission to recieve packets where as misbehaving routers dont. Correct me if i'm wrong or a total idiot.
The client at one end is effectively telling it's NAT to expect incoming packets from another host on a certain port, just without an actual connection being made. It's a way for the two hosts (who are already communicating by another method) to bootstrap their way through their respective NATs, without one end having to be permanently configured with a hole.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
This is so 1998 (or was it 1997?)
Anyway, I helped devise a similar system for enterprise use quite some time ago. As long as there's a known third party to introduce the systems, this is quite trivial.
And it's not even the only way this can be done, but "punching holes in firewalls" makes people think they're clever.
See: http://www.ietf.org/internet-drafts/draft-ietf-beh ave-nat-udp-08.txt
for a taxonomy of the ways NATs behave. The method
described in the article won't work for all kinds of NATs.
Is this correct - AFAIK - Skype traffic from an Enterprise goes over https (at least the initial connection) - that, combined with seemingly random IP addresses makes it difficult to block Skype traffic. Am I missing something here?
Teredo uses similiar ( if not the same techniques ) for running IPv6 over IPv4 networks. http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/teredo.mspx
This sentence, which occurs in the last paragraph of TFA, should be further noted. The technique described here has been around for as long as NAT routers have been around (a very long time). Its fairly common knowledge/practice in network security circles. In fact, this was taught in my network security course last year. I think it was on the final as well... except we had to defeat a NAT router using TCP packets which is a slightly more tricky task.
On a tangent:
NAT routers are not really proper firewalls, though they have the side effect of keeping most attackers out. This is beacuse NAT was designed and implemented primarily for allowing multiple computers to utilize a single global address. They technically break the OSI stack by reaching past the link layer... and provide a bit less security than using vanilla iptables without modules. A more interesting exercise would be to describe the steps to defeat a firewall with stateful packet inspection.
There are 10 types of people in the world. Those who understand binary and those who do not.
I don't see any way to download the source code for Wengo.
Heh we did this in 2003 and our VoIP implementation with NAT compatibility outperformed Skype at the time, had much better audio quality. (Old news).
Cost. The more you want to inspect, the more it costs to do. The cost also doesn't necessarily scale well at the high end. In a lower bandwidth system if you are doing all packet inspection in software (meaning you have a general purpose CPU doing everything) you just need to increase CPU power to get the same bandwidth. Ok, fair enough. However at the high end you generally need to start doing things in hardware (meaning specialised ASICs that do most of the work) and that means you need new hardware, if it is even possible to do that in hardware. Especially since you have to consider how you deal with new protocols. Any time a new protocol comes out, you have to update your system or it'll get caught by the default rule. If your system is largely hardware processing, an update isn't so easy.
Not saying it's not valid, just saying that there are reasons why all firewalls don't do deep inspection and it's not laziness.
Also adding a few ms wouldn't matter. You find me a link that doesn't have a few ms of delay. At work I have an extremely high speed network, below 1ms internally and that goes directly to OC-3. However on that first Ethernet to POS conversion there's 3ms added. It goes up form there and it's rarely less than 20ms by the time it gets to the end. That represents pretty much a best case scenario, most people don't have connections that low latency. At home my DSL has about 50ms of latency to the first hop, and is usually about 100ms or so to the destination. In either case, voice chat works fine. Yes there's a little delay, so what? Ventrilo (that's what I use) deals with it. It'll even work with modems.
I thought of several very similar variations of this technique years ago, and I'm sure that lots of other people have considered it as well. In my case, my goal was to effectively unblock all the stuff my company's firewall blocked us from doing (like POP3 mail, FTP sites, not to mention seemingly half of all the world's websites). I came up with numerous ways to get around the company firewall, most of which involved routing things through my home computer (which is also firewalled) with a little help from my personal website, which is hosted by a third party. I'm not patting myself on the back either. This is a fairly obvious idea if you've ever spent more than 5 minutes trying to solve this problem.
On Steve Gibson's and Leo Laporte's Security Now ep. 42, this technique was discussed. If you want to hear more about it, this is a good podcast episode to check out.
Great! Now make Gaim do this so I can send files.
The problem is that most system administrators consider a firewall as a means to limit user freedom. This is a way for users to bypass such restrictions (given a poorly configured firewall). From that point of view this might be bad if it weren't for the fact that they have plenty of tools left to prevent this kind of thing. In a corporate network this should be a non issue.
From a security point of view it is not so bad, however. The approach requires software inside the firewall to initiate a connection. Firewalls can be configured to prevent this if needed but in many cases the firewall is just there to prevent uninvited guests rather than to limit end user freedom (and initiating a request from the inside implies invited guest). The only difference is that now you can initiate connections to a computer that is also firewalled.
Jilles
The amount of half-knowledge is the comments to this entry would be frightening, if the people commenting would be working in that area. Luckily we can safely assume most are just geeks that wondered out out their area of expertise.
> A more interesting exercise would be to describe the steps to defeat a firewall with
> stateful packet inspection.
That's what the procedure does: It tricks the stateful packet inspection (for example the one that netfilter in linux uses), because it fools the router/firewall into thinking that the packets are "response" packets.
Or maybe you meant to say *deep* packet inspection, which does not merely check the connection state, but looks at the (data-)payload to make decision. In that scenario the firewall/router would now what the payloads of certain protocols look like (and what requests and what responss look like), and use a whitelist filter to prevent undesired or unknown stuff from happening.
Found this: Open Wengo Source code
I'm not a sysadmin, but I don't think this is particularly significant.
1. For this type of "incoming" connection to be created, the target machine has to first bounce a packet off its own NAT. So this isn't much different from creating a new outgoing connection since it can't be entirely remote initiated.
2. Since you are already allowing outgoing connections to untrusted hosts you are at already risk, as any connection can be exploited once it is open.
So in the scenario described there wasn't much security in the first place. To consider yourself realsonably firewalled you need to block both incoming and outgoing connections and keep a close eye on any "allowed" services. (ie, use a web proxy)
So according to this article, Skype reverts to port scanning my computer in some cases depending on how my firewall behaves.
At least under some legislations, port scanning alone is enough to be considered an illegal attack on my information systems. Why does this not apply to Skype?
We've known about this bug for years. It's how you fingerprint someone's network. N00bs.
Try www.Raketu.com - communications, information and entertainment all in one small p2p app - and free calling.
In addition skype (possibly not the latest version) can open listening ports on 80 and 443.
I was seriously pissed off when I discovered this, not just because I'd spent an hour or so tracking down why the IIS demo laptop had stopped working (so shoot me for working with windows).
meh