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
Ever wondered, how to use, commas properly?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Here is another good discussion (PDF): http://www.rootsecure.net/content/downloads/pdf/sk ype_protocol.pdf.
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.
They're not 'starting to charge', their free period is ending at the end of the year just like they said when they started it.
...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
We can only send packets as fast as they come out of the codec. After you've just transmitted a packet, there's maybe a 100mS wait until the next packet even exists. As long as Skype (or any VOIP stack) is working properly, the senders do all the 'flow control' necessary, simply by having a constant, regular stream to transmit. You don't want TCP flow control at all, you've either got enough bandwidth or you haven't.
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
both alice and bob are doing the same thing: sending a UDP packet to the other. for both, once they send out a UDP packet, that allows a UDP packet from the other side to come in.
so whoever sends the first packet wont make it to the other side, but the other side's packet will make it across, because both holes would then be open.
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?
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.
... 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.
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...
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.
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
* It's the same as STUN, the article even mentions STUN at the end.
* STUN also supports "symetric" firewalls/NATs, I think that's not mentioned in the article. But no one uses them at home anyway, and I doubt that they are widespread elsewhere.
* SIP can use STUN (it's not required, but pretty common now).
* What the article does not mention: Skype can also mis-use HTTP proxys with HTTPS support to get through the firewall. That's the configuration that most companies have, and I hoped to get a bit more information about that in the article. But basically it will work similar to the common HTTPS tunnels (google for them if you don't know them), just Skype-specific instead of allowing arbitrary TCP connections.
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
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.
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.