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."

Nothing new here

[Fenis-Wolf]

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.

Confusing title

[neonux]

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...

you have no clue

[RelliK]

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.

Doh - STUN

[Tetard]

"Nightmare come true". What sensationalism. This is just STUN, which SIP communication devices can also use:

http://en.wikipedia.org/wiki/STUN [wikipedia.org]

Re:Great article

[BarkLouder]

The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established.

There is no such thing as a "UDP connection". UDP is connection-less. TCP uses connections.

Re:you have no clue

[SatanicPuppy]

UDP is not connectionless. It is "stateless" which is not the same thing. Incoming UDP packets still have to open a connection with a NEW packet, so simply dropping all NEW UDP packets will keep you secure from any non-established connection.

The IPTables code would be:

iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT

This still wouldn't protect you from the "attack" described in the article, so to be truly secure, you should only allow outbound UDP on ports of your choosing.

Or you could just remove NAT for UDP:

iptables -A FORWARD -p udp --sport 1:10000 -j DROP

It's annoying, but it's hardly a "nightmare", and there a number of ways to keep your system secure, and to prohibit users from abusing your bandwidth with streaming applications.

Re:Nothing new here

[Anonymous Coward]

Attack vector? If a program on the inside of your network is sending out out connections to other places on the internet at the request of another place that it is already has a connection with, you're 'attack' has already taken place if you didn't want that program running.

This is no more of an attack vector than any other program you allow to run on your internal network that you allow to connect to external sources.

Re:Great article

[_xeno_]

The core BitTorrent protocol uses TCP, so the UDP technique the article describes won't work. (As far as I know, there's no corresponding technique for doing something similar with TCP.)

There's been a bit of work on various UDP protocol replacements for BitTorrent, but nothing that's really gained any cohesion that I'm aware of. So, when it comes to BitTorrent, no, there really isn't much work on making such a technique work.

There might be other P2P platforms that do attempt to do something like the technique described in the article, but the official BitTorrent protocol uses TCP and therefore can't use the technique.

Old news and incomplete as well

[Xenna]

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.

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/7AB67323D 6305E49CC2570A1001698C0 [computerworld.co.nz]

What was it again? All your base belong to us?

X.

Re:you have no clue

[Anonymous Coward]

UDP is not connectionless.

I'm sorry, but I'm just not comfortable with this statement.

When I send a UDP broadcast, do I then have a "connection" with each and every one of the machines that hears my datagram? If so, please tell me how I can enumerate each of these machines that I supposedly have a "connection" with.