Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    July 2014
    S M T W T F S
    « Jun    
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • About Us

    Have you ever noticed how security often takes a backseat when trying something new? When I am trying out a protocol out for the first time, I barely skim the Security Considerations section of the RFC. Just the same, as more of us start experimenting with IPv6, the use of tunneling protocols is likely to rise. That is good for IPv6 adoption but not so hot for security.

    I certainly don’t want to discourage anyone from trying IPv6. In fact, I would rather see folks testing the waters now, trying it out and getting comfortable with it, than thrashing and flailing when ICANN announces the exhaustion of IPv4 pools. I do want to make sure everyone is aware of the risks involved so they can take appropriate precautions.

    This article will only cover 6to4 (Wikipedia/RFC 3056) not to be confused with 6in4 and Teredo (Wikipedia/RFC 4380) tunneling protocols. A direct tunnel to your providers’ IPv6 systems does not present the same problems and risks as these public protocols do.

    Both protocols focus on easing the transition to IPv6 and neither one claims to offer any significant security protection. In fact, the Teredo RFC goes so far as to call itself the IPv6 Provider of Last Resort. This label comes primarily from the crazy stunts required to successfully traverse multiple NAT gateways. However, it is worth considering some other factors as well. 6to4 comes with an entire RFC devoted to security considerations (http://tools.ietf.org/html/rfc3964). Remember, IPv4 firewall rules don’t do anything to IPv6 traffic.

    6to4 tunneling requires that the user endpoint exist in publicly routable IP space and be directly reachable by any 6to4 serving device. One advantage of this exposure is that you can make use of more than just one 6to4 gateway, the obvious disadvantage being that you have to trust traffic coming from any address claiming to support the protocol for full functionality.

    6to4 can also support routes to networks behind the endpoint. Endpoints are assigned an IPv6 address from the 2002::/16 prefix. The 4 bytes immediately following 2002: are the IPv4 address of the endpoint converted to hex. Thus, 192.168.25.200 would map to 2002:c0a8:19c8::/48 (RFC 1918 IP used for example only, it would be invalid in actual operation). It is reasonable to say that if one was going to create a server and publish it to the IPv6 Internet, it should also be fortified against both IPv4 and IPv6 threats. The take-away here is if you publish a 2002::/16 IPv6 address, we also know the IPv4 address of your endpoint.

    Teredo is designed to work just fine with the remote endpoint behind one or more NAT gateways. Unlike 6to4, however, only one host can exist behind the endpoint. Right from the start, we need to worry about tunneling from the public Internet to a host inside a NATed environment. If the host is not well-protected, we could stop right there. We also have endpoint address leakage to contend with. Teredo goes even further than 6to4 by encoding the IPv4 exit point of the NAT gateway, the UDP port used by the external NAT session, and the IPv4 address of the tunnel endpoint used by the client. Some obfuscation is used, XORing UDP port and NAT IP with all 1s. However, this fact is well-known and will only protect you from people afraid of Wikipedia.

    The base prefix for a Teredo IP address is 2001:0000::/32. Teredo client addresses are assembled as follows:

    1. 2001:0000::/32 — base prefix
    2. 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
    3. 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0×00)
    4. 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0×7777 ^ 0xFFFF = 0×8888)
    5. 2001:0000:c0a8:19c8:0000:8888:F537:76C8/128 — add external IP of NAT gateway XORd with 0xFFFFFFFF (10.200.137.55 -> 0x0AC88937 ^ 0xFFFFFFFF = 0xF53776C8)

    Again, I don’t want to scare anyone off. Just know the risks and take appropriate precautions.

    Happy IPv6ing!





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    • Pingback: IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security – Security Threat Research News

    • Pingback: Phocean.net » IPv6 tunneling and security

    • Pingback: IPv6 Tunneling-Protokolle – Anwender sollten die Risiken kennen » markus-arlt.de

    • Sabahattin Gucukoglu

      I'm not all scared. My server's public IPv4 address is already known; there is no egress on most ISPs; people can already do horrible things to me and my server. That is no different with assigned teredo and/or 6to4. But, yeah, 6in4 is the more "Secure" alternative since you can have trust rules leading from your end to the gateway's end work fine (no unsolicited traffic).

      Remember, part of what makes Teredo and/or 6to4 so damn useful is that we can do direct host-to-host communication with routable blocks of IPv6. So we get IPv4's routing advantages without the 'orrible NAT/ALG/crap (minus a bit of efficiency for smaller payload sizes). I agree it's something to think about, but not too hard. Remember when we had ::/96 for compatible IPv4 addresses? Now that *would* have been anarchy (and there are still vestiges of that left in the various hideous translation proposals being pushed by all and sundry).

      Cheers,
      Sabahattin

    • http://sites.google.com/site/ipv6security/ Joe Klein

      Ben, IPv6 is a great protocol with many security features, not just IPSec, but until we have built end-to-end native IPv6 connections and rid ourselves of IPv4, the transition techniques you describe above will be a ongoing threat to the network integrity of all organizations. But your blog entry only touched on a very small surface of the threat.

      In my speech at DOJOSec (http://blog.saecur.com/2009/07/saecur-dojosec-june-2009-joe-klein.html), I describe more tunnels and problems that need to be addresses today, prior to implementing IPv6. I also have a site which contains the last 5 years of my IPv6 security presentations ( http://sites.google.com/site/ipv6security/Joe Klein)

      Lastly, DOJOCon (www.dojocon.org), a Security conference to benefit Hackers For Charity (http://www.hackersforcharity.org/), is scheduled to stream my presentation sometime after 3:50pm EST, Friday November 6th, 2009. Check out the website to learn more about the conference. And don’t forget to donate to “Hackers for Charity”!

      And Ben, keep up the great work on the blog! It’s worth the read.

      Joe Klein, CISSP…
      North American IPv6 Task Force, Security SME

    • Pingback: UnderForge of Lack » Blog Archive » 2009.10.27 火曜日 (たぶん)縮刷版



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice