When it comes to enterprise environments, Teredo scares the heck out of me -- just because of what it does. For those who aren't familiar with the technology, Teredo, championed by Microsoft, uses UDP datagrams to tunnel IPv6 traffic over IPv4 ports, as defined in RFC 4380.

Teredo allows internal networks to transition to IPv6, interconnecting them through their NAT devices and across the IPv4 Internet. Sounds innocent enough, right? Well, there are some significant security concerns for enterprises here.

Before Teredo, many organizations experimented with network-to-network IPv6 connectivity across the Internet, and they did so using IPv6-to-IPv4 gateways. Here's the traditional scenario:

Let's say two organizations deploy IPv6 on their intranets. Of course, the IPv6-enabled machines on one network can communicate with other IPv6 systems on that same intranet. In a pre-Teredo world, though, communication across the big, bad IPv4 Internet required each organization to deploy an IPv6-to-IPv4 gateway, which would convert the protocols. On one intranet, a machine would compose IPv6 packets destined for another intranet's system. The network gateway would tunnel the IPv6 packets inside of IPv4 packets, shooting them across the Internet. Once received by the other network, these packets would then be de-encapsulated by another gateway, this one extracting the IPv6 from the IPv4 and sending it to its IPv6-enabled destination.

On an end-host system, Teredo does the encapsulation without requiring an IPv4-to-IPv6 network gateway. IPv6 packets are put into a UDP packet, which is sent to the destination system via IPv4. Teredo is designed to work across NATs, so long as UDP packets over IPv4 can be sent between the two systems needing to communicate via IPv6.

What does this mean to an enterprise? Without Teredo, network administrators had to install and configure IPv6-to-IPv4 gateways, presumably hardening them against attack. But now, all of that tunneling functionality is pushed to the end system, which makes it much harder to secure the network. Any of your internal network's Teredo-enabled systems that can receive UDP packets can then act as an endpoint for IPv6 tunnels. Any applications that are bound to a machine's IPv6 addresses are then exposed.

On the inside of your network, a Teredo system can even act like a VPN endpoint for IPv6, allowing an attacker to send arbitrary IPv6 packets to a target machine and possibly get routed through that box to other places on your internal network. Symantec security researcher James Hoagland describes these attacks and more quite thoroughly in a recent paper.

Teredo wouldn't be such a concern if it were turned off by default. Yet Windows Vista ships with both IPv6 and Teredo automatically enabled. That's really a bummer, in my opinion. Windows Server 2008 supports IPv6, but it has Teredo shut off.

To defend yourself against Teredo-based tunneling and any associated attacks, first block arbitrary UDP packets at the network firewall, especially inbound and outbound traffic at UDP 3544, the default port for Teredo. Note that only the Teredo service listens on this port. Clients use an arbitrary high-numbered UDP port to send traffic to that destination, so you really want to block all traffic going to or from UDP 3544, closing off Teredo clients and servers that use it. Of course, various hacks can allow the traffic to be carried across other UDP ports as well.

Next, make sure personal firewalls on Windows boxes support IPv6 filtering and that it is enabled. The built-in Windows personal firewall offers such support, but many other products do not yet. Finally, it's possible to turn off Teredo at an end system by either running the 'netsh' command with the appropriate options, or setting a given value in the Windows Registry. Both methods are described in an article by Microsoft. I urge you to shut off Teredo if you aren't using it.