Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Skype Punches Holes in Firewalls

Posted by CmdrTaco on 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."

10 of 215 comments (clear)

  1. Nothing new here by Fenis-Wolf · · Score: 5, Insightful

    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.

    --

    1. Re:Nothing new here by Anonymous Coward · · Score: 2, Insightful

      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.

  2. Confusing title by neonux · · Score: 5, Insightful

    From my understanding they're not talking about "hole-punching" firewalls but only about plain boring NAT traversal, which is anything but a new topic...

    --
    @neonux
  3. you have no clue by RelliK · · Score: 3, Insightful

    If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they're established or UDP.

    And how are you going to receive replies if you tell it to drop the response packets?

    The trick that this article points out is that UDP is connectionless, so even a stateful firewall will not know whether a packet is a valid reply or not. The only way to prevent this is to block UDP entirely.

    --
    ___
    If you think big enough, you'll never have to do it.
    1. Re:you have no clue by SatanicPuppy · · Score: 2, Insightful

      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.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
    2. Re:you have no clue by Anonymous Coward · · Score: 1, Insightful

      UDP is not connectionless.

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

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

  4. Doh - STUN by Tetard · · Score: 2, Insightful

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

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

  5. Re:Great article by BarkLouder · · Score: 2, Insightful
    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.

  6. Re:Great article by _xeno_ · · Score: 4, 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.

    --
    You are in a maze of twisty little relative jumps, all alike.
  7. Old news and incomplete as well by Xenna · · Score: 4, Insightful

    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

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

    X.