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

Great article

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.

Re:Great article

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.

TCP over UDP

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.

You can then route TCP over it (grab packets from /dev/tap or /dev/tun) , or use a user space TCP stack connection or use something like my ECIP (http://www.ecip.com/ [ecip.com]) over it.

Re:Great article

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

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

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

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: Punching Holes in BT

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

Nothing new here

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

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

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.

DS

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

Re:DS

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

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

Oh come on.

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

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

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?

UDP *is* Connectionless; Apps might not be

UDP is a Layer 4 protocol for transmitting packets between (Layer 5,6,or 7) applications - it doesn't have any concept of connection, state, or acknowledgements, either in the packet headers or in the protocol for what to do with those packets. By contrast, TCP creates a connection between the two endpoints, using the 3-way-handshake mechanism, window size management, acknowledgements, retransmit mechanisms, etc., and the connection has state (SYN sent, SYN-ACK received, N bytes still waiting to go into a window, FIN received, etc.)

The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things

• Do a simple one-packet response to a one-packet query - DNS usually works this way, and all the protocols like Echo and Daytime that got turned off due to packet-amplification attacks like smurfing work that way. The application doesn't maintain any state - it just answers your question and waits for the next one.
• Send a stream of packets, unacknowledged, which you hope will mostly be delivered. Voice and videoconferencing applications work that way - it's better to have an occasional static or screen glitch than to slow the whole thing down waiting a few hundred milliseconds for lost packets to retransmit, watching everybody's mouth move out of sync like a bad Godzilla movie.
• Provide a full-scale connection, emulating TCP badly at Layer 7. Applications that do this are usually designed for LANs, where they usually work, and they can get higher throughput with less CPU demand on the computer because the connections usually work and are have much lower latency and loss and higher bandwidth than the environments TCP was designed for.

  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.

• Genuine one-shot unacked messages - telemetry apps are often like this, and sometimes logging apps are as well. If you lose the message "It's 43.123 degrees at 12:24:14", there'll be another one soon saying "It's 43.122 degrees at 12:24:15" that's probably just as useful as doing an ack and retransmit.

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

Re:you have no clue

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.

Confusing title

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

Why is this so bad?

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.

Slashdot, always bringing you the hottest news

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

Ever wondered

Ever wondered, how to use, commas properly?

Re:Ever wondered

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

udp huh?

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.

Punching holes?

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

punching holes...

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.

Skype is a Big Tymer

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

A Good Paper

Here is another good discussion (PDF): http://www.rootsecure.net/content/downloads/pdf/sk ype_protocol.pdf [rootsecure.net].

Steps, too many.

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?

The answer...

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

Re:The answer...

A few ms each should do it.

I'm pretty sure a few ms would be absorbed by the jitter buffer. Heck, 20ms jitter is often a normal occurance on long-distance WAN links.

Doh - STUN

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

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.

STUN?

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?

Re:STUN?

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

Not exactly new

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

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?

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

Easy to defend against on an Enterprise network

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

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.

How Skype & Co. get round firewalls

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?

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.

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.

You can do this with TCP too...

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

Perl code

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

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?

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

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.

Not at all new

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 already published this technique in 6/3/2002

http://www.ecip.com/fwdoc.htm [ecip.com]

We had it in our one of our livecam video streaming product in 1997

Why let UDP out anyway?

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.

Is there a risk?

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?

How come so few sip/voip apps get this right?

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.

Chicken or Egg?

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

This only applies to well behaved firewalls

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.

Seems perfectly reasonable

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.

NAT behavior is not consistent

See: http://www.ietf.org/internet-drafts/draft-ietf-beh ave-nat-udp-08.txt [ietf.org] 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?

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?

Microsoft's Teredo.

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 [microsoft.com]

News?

Use of the procedure described above is not limited to Skype and is known as "UDP hole punching".

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.

Similar technologies

Heh we did this in 2003 [nathack.net] and our VoIP implementation with NAT compatibility [sysdesign.ca] outperformed Skype at the time, had much better audio quality. (Old news).

Security Now

On Steve Gibson's and Leo Laporte's Security Now [grc.com] ep. 42, this technique was discussed. If you want to hear more about it, this is a good podcast episode to check out.

Wonderful

Great! Now make Gaim do this so I can send files.

security or straight jacket?

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.

what security?

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)

Port Scanning

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?

Woop Dee Dee

We've known about this bug for years. It's how you fingerprint someone's network. N00bs.

ports 80 & 443

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