Slashdot Log In
How Skype Punches Holes in Firewalls
Posted by
CmdrTaco
on Fri Dec 15, 2006 02:49 PM
from the i-thought-it-used-a-hammer dept.
from the i-thought-it-used-a-hammer dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Great article (Score:5, Interesting)
Re: (Score:2, Insightful)
There is no such thing as a "UDP connection". UDP is connection-less. TCP uses connections.
Re:Great article (Score:5, Informative)
Parent
TCP over UDP (Score:4, Informative)
You can then route TCP over it (grab packets from
Parent
Re: (Score:3, Funny)
Re:Great article (Score:5, Interesting)
Parent
Re:Great article (Score:5, Interesting)
Parent
Re: (Score:3, Interesting)
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 b
Re:Great article (Score:5, Insightful)
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.
Parent
Re: (Score:3, Informative)
Could you encapsulate a stream that acts like TCP inside of a stream of UDP packets? Sure. But it's not you can switch to a TCP stream as the predecessor post claimed.
Old news and incomplete as well (Score:5, Insightful)
AFAIK Skype uses a fallback system when the technique described doesn't work (where UDP traffic is blocked). In those cases it uses a well connected peer (yes, that could be your Skype client) to relay the voice data to the other party. Your PC becomes a Supernode without your knowledge and consent. Well, not really, coz this is in the Skype EULA:
4.1 Permission to utilise your computer. In order to receive the benefits provided by the Skype Software, you hereby grant permission for the Skype Software to utilise the processor and bandwidth of your computer for the limited purpose of facilitating the communication between Skype Software users.
http://computerworld.co.nz/news.nsf/news/7AB67323
What was it again? All your base belong to us?
X.
Parent
Re: Punching Holes in BT (Score:5, Informative)
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...
Parent
Nothing new here (Score:5, Insightful)
Re:Nothing new here (Score:5, Informative)
Parent
Re: (Score:2)
But, as scary as it sounds... there are Fortune 1000 companies that don't actively control this attack vector.
Re: (Score:2)
Re:Nothing new here (Score:4, Informative)
So it's not new, but it's still pretty clever.
Parent
DS (Score:3, Funny)
Re:DS (Score:5, Funny)
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.
Parent
Re:DS (Score:5, Informative)
See here [kotaku.com]
Parent
Oh come on. (Score:2, Informative)
If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they'r
you have no clue (Score:4, Insightful)
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.
Parent
Re: (Score:3, Informative)
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 (Score:4, Informative)
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?
Parent
UDP *is* Connectionless; Apps might not be (Score:5, Informative)
The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things
Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.
Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)
Parent
Re:you have no clue (Score:5, Informative)
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.
Parent
Re: (Score:2)
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.
Confusing title (Score:5, Insightful)
Re: (Score:3, Interesting)
Re: (Score:2)
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
Why is this so bad? (Score:2)
Slashdot, always bringing you the hottest news (Score:2)
Ever wondered (Score:5, Funny)
Re:Ever wondered (Score:5, Funny)
Parent
Re: (Score:3, Informative)
udp huh? (Score:2)
Re: (Score:2)
punching holes... (Score:2)
I sort of miss the dialpad.com days.
Re: (Score:2, Informative)
A Good Paper (Score:5, Informative)
The answer... (Score:5, Informative)
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... (Score:5, Informative)
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.
Parent
Doh - STUN (Score:2, Insightful)
http://en.wikipedia.org/wiki/STUN [wikipedia.org]
Not exactly new (Score:4, Interesting)
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 (Score:5, Informative)
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.
Parent
You can do this with TCP too... (Score:5, Interesting)
Perl code (Score:3, Interesting)
http://samy.pl/chownat/ [samy.pl]
NAT behavior is not consistent (Score:3, Informative)
News? (Score:4, Informative)
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.
Re:STUN? (Score:4, Informative)
* 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.
Parent