Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Skype Punches Holes in Firewalls

CmdrTaco posted more than 7 years ago | from the i-thought-it-used-a-hammer dept.

Security 215

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

cancel ×

215 comments

Sorry! There are no comments related to the filter you selected.

Rugged, easy-to-clean plastic laminates (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17260026)

each one is able to support more than 14 tons
and you can really see how big it is
and together they stretch for almost 1/4 mile
2.5 times the height of mount everest (the highest point on earth)
this super-imposed outline will give you an idea of its size
it's 370 miles wide at the base
and over 100 feet in length
but that's 40 miles from the opposite rim
and over 75,000 feet at the top
and that figure increases every year
Rugged, easy-to-clean plastic laminates are used on all the walls and surfaces
and that figure increases every year
the floors on which you are walking
the floors the floors on which you are walking
the floors the floors the floors on which you are walking
the floors the floors the floors the floors on which you are walking
children under 7 must be accompanied by an adult

Great article (5, Interesting)

Nasarius (593729) | more than 7 years ago | (#17260108)

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.

Yeah, but the technique does not work .... (1)

hummassa (157160) | more than 7 years ago | (#17260298)

in tight network conditions (no routes for outside, only application-level proxies have connectivity)

Re:Great article (2, Insightful)

BarkLouder (916884) | more than 7 years ago | (#17260540)

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:Great article (5, Informative)

autocracy (192714) | more than 7 years ago | (#17260632)

It is true that UDP is connectionless, but stateful firewalls do track UDP conversations as "connections." This is why, for example, DNS requests going out can be answered without unrequested inbound UDP traffic sent anywhere.

Re:Great article (4, Interesting)

pilot1 (610480) | more than 7 years ago | (#17260598)

Back when eDonkey was still fairly popular, I remember the lMule devs (GNU/Linux port of eMule) were aware of this technique and planned on incorporating it in lMule. BitTorrent became popular, lMule forked many times, and we never got around to it. I'm not aware of any current P2P apps that do it. The problem is that the technique, as they describe it, requires a central trusted server that both sides can connect to. With Skype that's fine, but it's a problem when you're dealing with something that's supposed to be entirely P2P. I don't remember this limitation, so either I have a bad memory or there's some way around it.

Re:Great article (4, Interesting)

d3ac0n (715594) | more than 7 years ago | (#17261404)

I would imagine that using the tracker server for this purpose would work. Obviously for "trackerless" torrents it would break again, but for standard tracker torrents it would probably work quite well. Couple it with torrent encryption and you have a very nice way to get around your college/work firewall.

Re:Great article (1)

izomiac (815208) | more than 7 years ago | (#17260864)

BitComet (a Bittorrent client) uses "UDP NAT Bypassing" which I assume is this technique. Unfortunately, this feature has been broken/disabled for the last few versions though.

Re:Great article (0)

Anonymous Coward | more than 7 years ago | (#17260958)

Hamachi does this to establish VPN "connections".

Re: Punching Holes in BT (0)

thex-defect (1040474) | more than 7 years ago | (#17261058)

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.

Re: Punching Holes in BT (5, Informative)

Crazy Man on Fire (153457) | more than 7 years ago | (#17261192)

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.


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

Re:Great article (3, Interesting)

w128jad (643759) | more than 7 years ago | (#17261078)

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.


I was impressed with this technique too. Perhaps the third party for a protocol such at bittorrent could use the seeders as UDP port mediators. It would be pretty easy to determine if the traditional listening port range was being filtered, and then the other seeding peers could do the UDP port exchanges for peers behind NAT firewalls. I don't think having a centralized trust is an issue here, because the whole concept relies on checksums anyway.

Of course I don't intimately understand how the protocol works in terms of discovery of other peers, so I could be talking out of my ass. Feel free to ridicule me if any of you know different.

The only place I could see this falling apart is the added overhead of establishing the scheme for *every* peer that wants to connect to your machine. The handshake to get each other's UDP ports would have to take place on some seeder *each* time a new peer came online, and each new host would somehow need to know which seeder was going to help exchange UDP ports. You would need an election, kind of like the master computer browser election on a NetBIOS PTP network. Perhaps you could handle this in tiers, allowing each "master browser" to handle a certain number of host UDP port exchanges.

Just think if this worked though. It would mean no more leechers!

Re:Great article (4, Insightful)

_xeno_ (155264) | more than 7 years ago | (#17261138)

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.

Re:Great article (1)

Amouth (879122) | more than 7 years ago | (#17261346)

once you have established a UDP connection (i know it is connection list but both of them talking) between the them you can fake your own TCP connection or switch it to one. once you know the forwarding port your good to go..

Re:Great article (1)

w128jad (643759) | more than 7 years ago | (#17261380)


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.


I don't think that would necessarily be a problem. You could leave the current protocol as it stands and "bolt-on" the UDP scheme. I don't know anything about the particulars of the protocol, but I would think you could add a preference to a bittorrent client to allow it to both participate in traditional bittorrent exchanges with normal seeders, as well as attempt UDP port exchanges by using the TCP connections with existing seeders.

You could have the client "test the waters" so to speak with a seeder, to see if it has the bolt-on code to help exchange UDP ports with other NAT-bound leechers. If the code responds, then you start establishing UDP connections through port exchanges with that seeder, else you just treat it like a traditional torrent seeder. That way, in the interum, you aren't breaking the current torrent protocol, but could actually get an added bonus of other "virtual-seeders" on UDP.

I am surprised to hear that torrent is TCP based in the first place. It seems like needless overhead, when the checksumming ensured data reliability anyway. But short of a complete reimplementation of torrent with UDP (with community support), I would think it would make more sense to extend the current protocol (not in the microsoft way :)

Just some thoughts.

Nothing new here (5, Insightful)

Fenis-Wolf (239374) | more than 7 years ago | (#17260116)

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.

Re:Nothing new here (4, Informative)

Rycross (836649) | more than 7 years ago | (#17260392)

The OpenTNL library (a game networking library pulled from the Torque engine) does this too. I remember thinking it was pretty clever at the time.

Re:Nothing new here (1)

throx (42621) | more than 7 years ago | (#17261008)

Most (if not all) game engines do it, and have been doing it since the late '90s. If I recall correctly, the first I saw it was the original Battle.Net code but that doesn't mean B.Net didn't get it from someone before that.

Re:Nothing new here (1)

Rycross (836649) | more than 7 years ago | (#17261264)

Thats interesting, but not surprising. I'm guessing that, like the OP said, the technique is very old and used pretty much everywhere UDP is.

Where did you see the Battle.Net code? Did you work for Blizzard or are you talking about bnetd?

Re:Nothing new here (1)

Tenareth (17013) | more than 7 years ago | (#17260408)

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. (Granted, when you talk "companies" that includes small businesses, so the % may seem high to you)

But, as scary as it sounds... there are Fortune 1000 companies that don't actively control this attack vector.

Re:Nothing new here (1)

rbarreira (836272) | more than 7 years ago | (#17260652)

What attack vector? The point of the story is, if you let the network make UDP connections, the network can make UDP connections to anyone. So what?

Re:Nothing new here (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17260808)

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:Nothing new here (1)

mindstrm (20013) | more than 7 years ago | (#17260876)

How is it a security issue?

If my users are allowed to make outgoing UDP connections (which was my choice) then why do I care if they are making that connection to another firewalled person somewhere lese in the world -vs- a computer out in the open?

the security issue. (1)

Erris (531066) | more than 7 years ago | (#17260886)

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.

Re:Nothing new here (1)

Chris Pimlott (16212) | more than 7 years ago | (#17260580)

This is similar to the way FXP worked to let you transfer files directly between two FTP servers. You set passive mode and tell A to expect a file, and it says "okay, send it to a.a.a.a:aaa", then you turn around to server B and say "send me a file, I'm waiting at a.a.a.a:aaa".

Re:Nothing new here (0)

Anonymous Coward | more than 7 years ago | (#17260636)

Exactly. That's exactly how my VoIP provider works thru my NAT/firewall (w/o opening a port), or VPNs like Hamachi work, and countless others. Nothing new here. Might be an interesting read for those who didn't know, but hardly newsworthy.

Re:Nothing new here (3, Informative)

jfengel (409917) | more than 7 years ago | (#17260744)

You're right that it's not new, but you're missing a crucial step. They need to exchange port numbers, not just IP addresses, via the central server (or at least one port number). Then they need to prime the firewall to pass connections through to that port by sending out a packet to the peer from that port, even though the final destination of that packet will be filtered out.

So it's not new, but it's still pretty clever.

Re:Nothing new here (1)

Amouth (879122) | more than 7 years ago | (#17261442)

i was jsut thinking about it... and if they set the first out going packet's ttl to 1 or 2 they could make it even more effective aginst active fire walls as the udp packet would die before it makde it the other person so that they nat box wouldn't see an incoming attempt before a request from it's clients..

that and they would save 1 packet of info per call on the net.. think abouthow much bandwidth that is :)

DS (3, Funny)

an7ron (846004) | more than 7 years ago | (#17260120)

I wish my nintendo DS did this, so I could play metroid at work.

Re:DS (5, Funny)

MyLongNickName (822545) | more than 7 years ago | (#17260218)

I wish my nintendo DS did this, so I could play metroid at work.

And if you could disguise it to look like a cash register, your customers would have no idea you weren't ringing up their Happy Meal.

Re:DS (5, Informative)

GweeDo (127172) | more than 7 years ago | (#17260440)

Um, if they worked at McDonalds they would already have free WiFi for DS gameplay.
See here [kotaku.com]

Re:DS (1)

Meeuw (552270) | more than 7 years ago | (#17260770)

Actually, the Nintendo DS *does* this trick! As far as I sniffed Tetris DS and Mario Kart DS the connections are punched through the firewall. I've tried to firewall my wireless network so any DS could connect and play at nintendowifi but the connections are made peer-to-peer at random source and destination ports. I've started to work on a netfilter queue to do some smart firewalling (to allow holepunching through nintendowifi) but I haven't finished this yet :-(.

Oh come on. (2, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17260122)

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.

you have no clue (3, Insightful)

RelliK (4466) | more than 7 years ago | (#17260300)

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.

Re:you have no clue (2, Informative)

grasshoppa (657393) | more than 7 years ago | (#17260534)

Generally, it's wise not to open your mouth unless you know what you are talking about;

The kernel firewall knows how to MASQ udp packets; There's a timeout associated with them. So if you get a random UDP packet that it doesn't have a matching connection for, it'll drop it.

The real problem is being an administrator for a network which doesn't block outgoing traffic.

Re:you have no clue (1)

whoever57 (658626) | more than 7 years ago | (#17261406)

The kernel firewall knows how to MASQ udp packets; There's a timeout associated with them. So if you get a random UDP packet that it doesn't have a matching connection for, it'll drop it.
Which brings up an interesting question: the article talks about destination port numbers, but does not discuss source port numbers.

Surely, iptables/netfilter also requires source ports to match? This is important, since the MASQ/NAT firewall can rewrite source port numbers, and hence the central server cannot reliably pass this information to the clients (since neither the clients nor the central server can reliably know the source port of the UDP packets after they are re-written by the NAT/MASQ firewall).

Re:you have no clue (2, Insightful)

SatanicPuppy (611928) | more than 7 years ago | (#17260616)

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:you have no clue (2, Informative)

mindstrm (20013) | more than 7 years ago | (#17260930)

Now we're into semantics... stateless and connectionless are the same thing.

The nat or filter tables use the concept of a connection to allow/deny udp packets, but that is only a convention; UDP in and of itself is completely connectionless and stateless. There is absolutley nothing saying that 2 packets with the same source & destination ports are part of the same conversation at all.

It's not even an attack anyway... if you allow outgoing connections, why do you care if the person is connecting to someone else in the world who is firewalled -vs- someone who is out in the open, or whether htey are using UDP or TCP? (let's leave network performance & abusive UDP out of it...)

Re:you have no clue (3, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17261150)

Well, no, I suppose if you sent every packet from a UDP session to a different port, there would be no way of telling that they're all part of the same session, because you're right, UDP doesn't contain any tracking info.

The state table entry for a UDP packet, however, contains the source IP:port and the destination IP:port, and uses that information to "track" the exchange. So unless you just allow all UDP through the firewall, the state table keeps track of how often the destination ip responds, and if it doesn't respond within the timeout set in ip_conntrack_proto_udp.c at compile time, the system will terminate that connection, and require a "new" connection to be set up between those addresses. It also won't allow the destination port to be changed without a second "NEW" packet originating from the new destination port.

I agree it's not an "attack" as such. My original point was that it wasn't an exploit at all, in the sense that you are not able to break any existing rule using this method. If you allow UDP out, and UDP:Established in, then how can you complain that you end up accepting a bunch of UDP packets?

Re:you have no clue (0)

Anonymous Coward | more than 7 years ago | (#17261142)

Umm... Where are those things in the UDP header [faqs.org] ?

A connection doesn't get opened with UDP by sending a new packet, both ends must negotiate that they will listen on that UDP port.

For instance, syslogd listens on a UDP port. When a client wishes to send data to the server, it just sends it. If the server's not listening, so what!

The only reason those states can exist is because an intermediate network device is trying to reconstruct what the endpoints are doing and thus must track "connections".

So in the syslog example, the server sends nothing back. It's a one way protocol and your "connection" tracker is going to watch all these UDP "connections" for no reason.

Re:you have no clue (1)

SatanicPuppy (611928) | more than 7 years ago | (#17261292)

The system maintains a "State Table" which stores information about all incoming/outgoing connections. For TCP it stores stuff out of the packet headers, including sequence, and state, and all that other junk, but it also stores origin and destination, to help spot packet spoofing.

For UDP the state table depends entirely on the origin port/address and the destination port/address. When the connection is made out, this is recorded in the table, and when the packets start coming back in, this is compared with the original entry.

If it matches, they are accepted, if it doesn't they aren't. Additionally there is a timeout, which, in the case of linux is actually hardcoded into the kernel in /usr/src/linux/net/ipv4/netfilter/ip_conntrack_pro to_udp.c...It defaults to 30 seconds, which means, if the local IP doesn't send a response every 30 seconds, the connection will time out.

All these people maintaining that UDP is a "connectionless" protocol are baffling to me...How do you think NAT works? Do you think that it just forwards UDP packets everywhere, hoping that someone wants them? All connection information has to be maintained with NAT, or there is no point.

Re:you have no clue (5, Informative)

E++99 (880734) | more than 7 years ago | (#17261418)

All these people maintaining that UDP is a "connectionless" protocol are baffling to me...How do you think NAT works? Do you think that it just forwards UDP packets everywhere, hoping that someone wants them? All connection information has to be maintained with NAT, or there is no point.

UDP is connectionless. NAT routers invent imaginary connections based upon the outgoing packets they see, and then close the imaginary connections after inactivity. It's not part of the protocol. It's a model that the router uses to block all packets except the ones that were presumably requested.

Re:Oh come on. (1)

jimicus (737525) | more than 7 years ago | (#17260360)

Of course it's not. But a lot of it depends on how you run your firewall.

If it's "every packet trying to cross the firewall in either direction is blocked unless it comes from the web proxy or the mail server" then Skype will also be blocked anyhow.

If it's "any packet trying to come in is blocked, but if the connection was originally set up from inside the network, anything goes" (which seems to be the most common configuration), then Skype will work quite happily.

Re:Oh come on. (1)

SatanicPuppy (611928) | more than 7 years ago | (#17260700)

Absolutely. It be fair, it's easiest to set up a firewall that blocks all incoming non-ESTABLISHED traffic, and allows all outbound traffic. That's two lines of code.

Every other port or packet type you have a special case for is two more lines, so you see your work doubling in front of you with every little bit of added complexity.

Still, if you do it right, stuff like this won't sneak up on you.

Re:Oh come on. (1)

jimicus (737525) | more than 7 years ago | (#17261246)

There is also the small issue of spyware and the like, and whether or not it should be blocked in that fashion. Though if you believe nobody has thought of tunnelling spyware traffic over HTTP you're fantastically naive - I've not actually looked into it, but I'd be astonished if they haven't, and if you don't have a half-decent AV solution which also looks out for spyware, you deserve all you get.

Re:Oh come on. (1)

SatanicPuppy (611928) | more than 7 years ago | (#17261364)

It depends. At work, I deny everything, and then open specific ports for specific traffic from specific subnets, and then every address gets monitored for usage. Catches most things, and in a work environment, blocking 99% of all ports is acceptable.

At home, I allow all outgoing, and a tiny amount of incoming. I monitor usage with snort, to check for spyware traffic. I've been doing it for 5 or 6 years and I've never had any problems. Probably helps that I don't do any web surfing/email from Windows machines, so if something did go across port 80 from one of them, it'd stick out.

Confusing title (5, Insightful)

neonux (1000992) | more than 7 years ago | (#17260142)

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

Re:Confusing title (2, Interesting)

Aadain2001 (684036) | more than 7 years ago | (#17260200)

No, it is "punching" a hole in the firewall. While NAT transversal is similar to this technique, is works even if you are not using NAT (say, at an office). While it's nothing "ground braking" or really that new, it is (at least to me) interesting and probably is to anyone who isn't a network guru.

Re:Confusing title (1)

SatanicPuppy (611928) | more than 7 years ago | (#17260396)

It's not even "punching a hole", so don't think about it that way.

Many firewalls are set up to trust the computers on the inside, so if they make a connection out, the firewall allows that connection to persist by allowing packets that are a part of the internally originating conversation to come back through.

So basically, far from having "a hole punched through your firewall", you've basically invited an untrustworthy element through your security, and it's opening a window so it can pass information back out to it's friends.

This is a very old, classic problem with firewalls, because you want the firewall to be as inobtrusive as possible, while still offering good protection. I don't, for example, block my windows PC from sending out on any port through the firewall, because I mainly use it to play games and I never know what ports it'll need to use. However, I do monitor it's internet usage using Snort, to keep an eye out for spyware and zombie processes. If I cared, I could lock it down to web-only with trivial changes in the firewall.

Re:Confusing title (1)

Aadain2001 (684036) | more than 7 years ago | (#17261168)

So basically, far from having "a hole punched through your firewall", you've basically invited an untrustworthy element through your security, and it's opening a window so it can pass information back out to it's friends.

Window... hole... basically a port is opened (from the inside) that allows data to into the 'secured' side of the network. You may not like the term 'hole', which conjures images of hackers and exploits, but you are, in effect, opening a 'hole' in your firewall that someone on the outside can now sent data through to your computer. That's a hole. It's also a window. It's also a door, a porthole, and channel, a port, etc.

Implementing John Gilmore (0)

Anonymous Coward | more than 7 years ago | (#17260148)

Actually, a paraphrase. "Skype interprets firewalls as damage and routes around them."

Why is this so bad? (1)

Salvance (1014001) | more than 7 years ago | (#17260184)

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.

Re:Why is this so bad? (1)

hey! (33014) | more than 7 years ago | (#17260892)

Well, it's not being tricky so much as efficient in the case of Skype. What's interesting is the technique being used.

What the technique here describes is method of creating a two way connection between any two points A and B, provided that point B has a connection to point C, and that A and B can send UDP requests and receive responses. It so happens that A in Skype has a connection to C, but that's not stricly necessary.

Now there's nothing evil about Skype doing this. They're avoiding unnecessary traffic to their network while not adding any additional traffic the users' network. But it doesn't take a genius to think of uses for the technique that are evil.

The thing to remember here is that the administrators of A and B's firewalls do not want anybody making incoming connections to machines on their network for any purpose; otherwise they wouldn't have a firewall. Most are surely aware of Skype and by not blocking Skype's IP they are perhaps implicitly consenting to this. But what about some random web site?

Re:Why is this so bad? (0)

Anonymous Coward | more than 7 years ago | (#17261300)

I think you're missing the point a bit. With a basic IM application, the client always remains connected to the server with a TCP connection that the client establishes when it first starts up. When a conversation is to be established, the server tells both clients to connect to a server (again via TCP) and the messages are relayed by the server. Never are the two clients directly connected to each other (For basic IM functionality).

Skype doesn't want to relay the audio so they want both clients to connect directly to each other - that's the difference. Skype causes one client to send an outbound UDP message that it knows will never arrive at the destination client...simply to prepare the NAT router to allow the remote clients UDP messages back in and route them to the appropriate internal IP address.

Slashdot, always bringing you the hottest news (1)

rbarreira (836272) | more than 7 years ago | (#17260192)

While this is a cool technique, I had heard about NAT2NAT years ago... This is not a new technique, by any means.

Ever wondered (5, Funny)

spun (1352) | more than 7 years ago | (#17260204)

Ever wondered, how to use, commas properly?

Re:Ever wondered (1, Funny)

Anonymous Coward | more than 7 years ago | (#17260326)

No [cpan.org] , not [crasseux.com] really [wikipedia.org] .

Re:Ever wondered (5, Funny)

CODiNE (27417) | more than 7 years ago | (#17260590)

Don't tease, those, who have graduated, from the Shatner, School of Grammar.

Re:Ever wondered (2, Informative)

Peyna (14792) | more than 7 years ago | (#17260670)

Not to mention how to properly use an em dash.

Re:Ever wondered (1)

crosseyedatnite (19044) | more than 7 years ago | (#17261002)

If, I, put, commas, after, every, word, then, the, ones, that, should, be, there, are, there, and, the, ones, that, should, not, should, be, blocked, by, the, punctuation, firewall,.

udp huh? (1)

minus_273 (174041) | more than 7 years ago | (#17260206)

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.

Re:udp huh? (1)

dotgain (630123) | more than 7 years ago | (#17260358)

You generally use UDP for voice because if a packet gets delayed or lost, there's no point in retransmitting it. In fact, retransmission would cause delays, whereas a missing packet is usually handled quite well by whatever endpoints are in use (i.e. they just repeat the audio in the last packet received, and hope the user doesn't notice).

Re:udp huh? (1)

minus_273 (174041) | more than 7 years ago | (#17260466)

I know why you wouldnt really need reliable transport on voice data due to the hard real time constraints. Im more concerned with the flow control. UDP has nothing it is just data blasted on the network. a buggy protocol on top of UDP and enough people using it will bring us back to the internet crash of the late 80s. Seems like not every one remember the internet becoming unusable. There is a reason why TCP was revised to behave the way it does today. The older TCP didnt really scale up well.

Re:udp huh? (2, Informative)

dotgain (630123) | more than 7 years ago | (#17260644)

It's voice, not file transfer.

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.

Punching holes? (1)

zcubed (916242) | more than 7 years ago | (#17260210)

This isn't some earth shattering revelation. A good explanation for a layman, but nothing new.

punching holes... (1)

joeldg (518249) | more than 7 years ago | (#17260234)

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.

Re:punching holes... (2, Informative)

AndrewNeo (979708) | more than 7 years ago | (#17260308)

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.

Re:punching holes... (1)

Sciros (986030) | more than 7 years ago | (#17260422)

It's not going to be charging Skype-to-Skype, which is what this article is talking about as far as I can tell. It will be charging $30/year for Skype-to-phone... which is what it was doing from the get-go unless you're talking about its special promotion to release that functionality for free for a time. And actually to begin with it was charging 30 euros, not $30 (closer to $40 at the time). I for one doubt too many folks will go to "the next thing that is free." Me, I've been paying for Skype-to-phone and phone-to-Skype (SkypeOut and SkypeIn, respectively) since they were available because I spent most of last year out of the country, and been quite satisfied.

Skype is a Big Tymer (1)

Larsiny (753559) | more than 7 years ago | (#17260272)

So I guess you can say Skype is the #1 [azlyrics.com] STUNna [faqs.org] ?

Yawn... (1)

Jinjuku (762364) | more than 7 years ago | (#17260280)

And this is new news how? Nothing to see here folks, move along.

Punch holes? (1)

monkeyboythom (796957) | more than 7 years ago | (#17260350)

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.

mod 04 (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17260362)

of BSD/OS. ^A Hapless *BSD I've never seen

Steps, too many. (1)

mmeloche (1018710) | more than 7 years ago | (#17260372)

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?

Re:Steps, too many. (2, Informative)

brunascle (994197) | more than 7 years ago | (#17260686)

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.

Re:Steps, too many. (1)

mindstrm (20013) | more than 7 years ago | (#17260724)

bob won't get alices request, because his firewall won't allow the incoming packet.

Re:Steps, too many. (1)

David Gould (4938) | more than 7 years ago | (#17261240)

No, that's exactly it: as I read it, Bob's first attempt to connect to Alice is discarded by Alice's firewall, but it was never intended to be received; its only purpose was to put Bob's firewall into the "waiting for response" state, so that when Alice subsequently attempts to connect to Bob, Bob's firewall interprets the incoming data as the response that Bob was waiting for. And that's exactly what it is, in the sense that Alice and Bob are both intentionally following the Skype protocol; it's just not technically a "response" to Bob's actual packet.

That's why my take is that this isn't really a "security issue" so much as an "acceptable-use policy" issue: it only works because Alice and Bob are both intentionally running the Skype software and signed into the Skype server. Bob obviously doesn't consider an incoming call from Alice to be an "attack", because if he didn't want to receive calls, he wouldn't be running that software. Bob's local BOFH may consider it an "attack" in the sense that one of his lusers is using his network in a way that he didn't approve and is unable to control, but that's a different sort of problem.

What's the purpose of a firewall? To protect the network from hack attacks? Or to enable BOFHs to enforce their AUPs and control how their own lusers use the network? It's really both, I guess, but at least it's only the latter that is thwarted by this method.

The answer... (5, Informative)

chill (34294) | more than 7 years ago | (#17260444)

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

Doh - STUN (2, Insightful)

Tetard (202140) | more than 7 years ago | (#17260518)

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

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

Alternatives Anyone? (1)

bogaboga (793279) | more than 7 years ago | (#17260630)

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.

Re:Alternatives Anyone? (1)

WetCat (558132) | more than 7 years ago | (#17260986)

www.wengophone.com
Moreover, it's open source.

STUN? (1, Interesting)

Darkforge (28199) | more than 7 years ago | (#17260672)

Is this just the same thing as STUN [wikipedia.org] (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?

Not exactly new (3, Interesting)

Wannabe Code Monkey (638617) | more than 7 years ago | (#17260678)

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.

Re:Not exactly new (1)

larien (5608) | more than 7 years ago | (#17261358)

Read page 2 of the article - it explains how Skype can bypass this, at least in some cases.

Re:Not exactly new (4, Informative)

dgatwood (11270) | more than 7 years ago | (#17261464)

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.

Alice's computer should not be sending to 2828. It should be sending to the source port seen in the packets sent to the centralized server used for the rendezvous operation. Bob doesn't tell Alice anything. Bob sends a message to the central computer, which in turn, tells Alice something. The central computer DOES know what port Bob's router used because it can look at the source port on the UDP packet.

When a breakdown occurs (rare, but possible), it is not because of the difference between 2828 and 3939. It occurs because the router picked a -different- source port to use when sending packets to Alice than it did when sending packets to the central server. If the router does not consistently map port 2828 to 3939, but instead adds a secondary mapping from 2828 to 5050 when communicating with Alice's machine, the connection may fail. However, in order for a complete failure to occur (as opposed to simply requiring two or more packets to be sent and a little extra negotiation), one of the following must be true:

A. Both routers must be broken in this way. If this is the case, neither side can get a packet through to the other side.
B. One router must be broken in this way and the other router must alter the source port (reverse port masquerading) of inbound traffic.

If neither of these is true and Alice's machine is the one with the broken router, her router will use a different source port when communicating with Bob's machine that corresponds with the different destination port to which Bob's response must be sent. As long as Bob's router does not munge this, Bob's computer now knows how to send a message back to Alice, and a bidirectional communications channel should exist at that point.

I'm not saying that any of these services/protocols handle that extra bit of negotiation, of course, just that the problem isn't unsolvable unless both routers have a critical defect in their behavior.

Slow news day? (1)

t00le (136364) | more than 7 years ago | (#17260720)

Today must be a REAL slow news day....

Easy to defend against on an Enterprise network (1)

Smukatele (743439) | more than 7 years ago | (#17260740)

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.

Otherwise known as STUN (1, Informative)

chhamilton (264664) | more than 7 years ago | (#17260742)

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 [ietf.org] 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 [wikipedia.org] . There is also a simple, cross-platform and open-source library [sourceforge.net] 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.

At least netfilter can be fixed (0)

Anonymous Coward | more than 7 years ago | (#17260746)

should be trivial to make netfilter randomize source port for every nated connection.

Re:At least netfilter can be fixed (0)

Anonymous Coward | more than 7 years ago | (#17261178)

So what problem are you solving? Congratulations, you've just made it impossible for your computer to connect to another computer that has a firewall. Your computer can still connect to non-firewall'ed computers on the internet (And it wouldn't even have to bother with UDP tricks, TCP would work fine...), so you're solving the wrong problem.

How Skype & Co. get round firewalls (2, Funny)

jctull (704600) | more than 7 years ago | (#17260760)

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?

How long does NAt allow a reply to UDP packet? (1)

Viol8 (599362) | more than 7 years ago | (#17260832)

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?

Not hole punching. (2, Informative)

mindstrm (20013) | more than 7 years ago | (#17260836)

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.

Hurray for Skype, boo for asshat network nazis (0)

Anonymous Coward | more than 7 years ago | (#17260884)

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 can do this with TCP too... (5, Interesting)

sparr0w (902739) | more than 7 years ago | (#17260910)

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

The better fix that we use at work (0)

Anonymous Coward | more than 7 years ago | (#17261110)

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.

Perl code (2, Interesting)

sheriff_p (138609) | more than 7 years ago | (#17261124)

Samy, the guy involved with the MySpace worm, wrote some Perl to do this a while ago:

http://samy.pl/chownat/ [samy.pl]

Misleading explanation of a easily solved non-prob (1)

Ancient_Hacker (751168) | more than 7 years ago | (#17261202)

Hmmm.
  • This isnt "hole punching".
  • Whatever that is.
  • Each client is initiating a connection to a broker.
  • The broker tells anybody that wants to know where Bob is.
  • The "firewalls" are stupidly allowing packets to come back in from any source.

Should take about five lines of code to fix, in any firewall that really want to.

am I missing something here? (1)

advocate_one (662832) | more than 7 years ago | (#17261308)

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.

NAT Traversal, not firewalls (1)

phliar (87116) | more than 7 years ago | (#17261400)

As others point out, the technique has been used for many years.

It's not even a real solution. The article says:

From the incoming query it sees that Alice is currently registered at the IP address 1.1.1.1 and a quick test reveals that her audio data *always comes from* UDP port 1414 [emphasis mine].

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>