Why should your internal hosts have publicly routable IP addresses, courtesy of IPv6? I blame the pesky academics...
We got a bit of a surprise a couple of weeks back. For the very first time when testing an internal network, we were granted an IPv6 address over DHCP. It was a new network for a local authority and it had taken the opportunity to implement IPv6. My first thought was, ‘why?', as it had less than 500 servers and workstations in total. Maybe for a bit of future-proofing? Was it a risky strategy, though? Did they know what they were playing with?
Less than five per cent of the IPv4 address space is unallocated, hence there's a bit of concern about room for growth, as the number of internet users increases. We have noticed a number of public IPv6 address-range allocations, often for academic institutions, but sometimes in the commercial world too.
A v6 allocation would seem to solve these problems – for example, an organisation would usually be allocated a /48 subnet, which contains as many potential IP addresses as the entire v4 address space.
Native support for IPv6, enabled by default in Windows 7 (and Vista), makes the task of implementing it a whole lot easier, but also creates interesting opportunities for mischief.
First, do you even know if you have any IPv6 traffic on your network? It is to be hoped you are not granting v6 addresses from your DHCP server unintentionally, but it wouldn't take much to set up a rogue DHCP server offering v6 addresses to your clients.
How many of your internal hosts have publicly routable IP addresses? It may be more than you think, as coverage recently of the Teredo service shows. This is meant to give you the ability to access the v6 address space without having to make significant changes to your border routers.
It is essentially a 6-to-4 tunnel, operating locally on the client, encapsulating v6 traffic in IPv4 UDP packets. There is a significant problem, as it can easily lead to one of your clients – server or workstation – having a publicly routable IPv6 address.
When the Teredo service is started on the local machine (be it by a user or through malware), it automatically tries to discover an outbound route to the Teredo server, removing the need for any significant user technical expertise.
If a UDP connection can be obtained to Teredo, a two-way tunnel is created. The internal host gets a publicly available IPv6 address in the range the provider allocates for Teredo service. It is an ideal place for a hacker to hide a back door connection to internal hosts on your network.
There are several routes to mitigate the problem.
- Disable the IPv6 adapters on your standard workstation and server builds if you don't explicitly need them. Malware could re-enable these, but it is a great start. You don't offer unnecessary services from your clients, so why offer unneeded network interfaces?
- Check your outbound IPv4 firewall rulesets to ensure that the UDP communication on high ports required by Teredo is not possible. Pay particular attention to UDP port 3544, the default for the service. Bear in mind that UDP traffic is commonly permitted outbound for services such as DNS and often allowed inbound for services such as streaming media.
- If you run IDS or IPS, ensure they can monitor IPv6 comms, as this could so easily be used as a covert channel. Consider running Wireshark, even if you do have monitoring in place; look for ICMP, link-local multicast name resolution messages and other IPv6 traffic.
- Similarly, if you intentionally offer IPv6 services and have a public v6 address space allocation,
the size of the subnet makes
it very hard to discover unintended public hosts or services in your address space.It's like finding a needle in a haystack!
In summary, don't do IPv6 unless you understand the risks. And if you aren't doing v6, then disable the relevant client network adapters and monitor v6 traffic on your network.
In the meantime, maybe ARIN and the other registries can convince certain academics to give back their unnecessary IPv4 class A allocations, so we don't need to bother implementing IPv6 at all…