I recently was asked quite a few questions about network security, and the conversation started steering towards IPv6, and how the new protocol changes the security game in many ways. The person I was talking to was a very competent network engineer, but like so many these days, woefully misinformed about IPv6. He was was under the assumption that EVERYTHING was different, and that moving to IPv6 was too daunting a task to worry about right now.
I have my own opinions on IPv6 deployment, and who should be doing it, but I thought it was a good idea to point out exactly what doesn’t change when moving to IPv6. By that, I mean that many cornerstones of network security are IP version-agnostic, and should be followed in any environment. Rather than tell him that he absolutely must convert to IPv6, I pointed out that there are a few key points that can be followed whether or not IPv6 is being implemented in an environment. If you build your security policies around these ideas, they can be implemented in much the same way when you finally do start forwarding v6 packets.
If You’re Not Using It, Turn It Off
This goes without saying – in fact it’s a key step in hardening network hosts and devices. You should never leave a service running if you don’t have a plan for it.
Starting with Vista (Windows), OSX 10.2 (Apple), and most modern Linux distributions (kernel 2.6.x and above), IPv6 is supported, and in most cases, turned on by default. If you’re not actively deploying IPv6, it should not be enabled. Countless mechanisms exist for mass-disabling IPv6 in your environment, such as through Group Policy. It’s really simple – if you’re not using it, turn it off.
However, if you are implementing IPv6 on your network, it doesn’t mean that all features of IPv6 need to be turned on. IPv6 is a big beast and there a lot of new technologies involved. You should go through and figure out which features you want to use and how, and turn the others off. For instance – you should be aware of is the fact that ISATAP and Teredo tunneling mechanisms are enabled by default in Vista/7. Don’t know/don’t care? This paper by Symantec goes into detail concerning the problem Teredo brings to the table from a security perspective. Teredo can be used to get otherwise blocked traffic through your firewall and create big security problems.
You can disable Teredo and ISATAP via Windows command prompt:
12 netsh interface teredo set state disablenetsh interface isatap set state disable
Teredo also runs on UDP port 3544. Block it. Teredo is terrible.
Control Your Access Layer
There appears to be an increase in overall IPv6 knowledge even within organizations that have typically lagged behind. Malicious users are also become more IPv6-savvy. There has been an increase in viruses and worms using IPv6 to propagate – as the creators know that network administrators are doing little to nothing to secure IPv6 traffic.
I’ve written several posts on my blog about IPv6 security and some of the technical details behind Router Advertisement exploits, such as a devastating DoS attack (one of many types possible with Router Advertisements) and a Man In The Middle attack, all made possible with very easy-to-use scripts. The authors of these scripts have made it very easy to circumvent common defenses such as RAGuard, which would otherwise stop many of these attacks. However, SEND (Secure Neighbor Discovery) also exists to help secure your access layer from would-be attackers by requiring an RSA signature option and proof of authorization for messages like Router Advertisements. The most important step is to disable IPv6 wherever possible if you’re not implementing it, but in addition to that, it’s important to realize the risk at the access layer, and be comfortable with it, or try to mitigate it with mechanisms like SEND.
Turning off IPv6 on your network devices and even disabling it on a Group Policy basis doesn’t prevent all users from running it. Keep in mind that with the advent of “Bring Your Own Device”, or environments where employees bring their own devices to work regardless of policy (i.e. ALL environments), the way you control end-user experience is changing. Your Active Directory team begins to sweat as they slowly discover that they are not omnipotent, as they were led to believe. There are a few things you can do to ensure that only legitimate devices or users can connect to your network, such Microsoft’s NAP, or 802.1x authentication. These are all IP version-agnostic technologies. Realistically, none of these mechanisms will completely prevent IPv6 from running – you’ll undoubtedly see some link-local traffic from time to time.
Have an IPv6-Aware Internet Edge (No Matter What)
It’s crucial to find out if or how you are allowing IPv6 packets to leave your network. Even if you’re not forwarding IPv6 on your routers, tunneling is still a real threat. Consider the use of an HTTP/HTTPS proxy for internet access by users – this can allow you to require authentication to even access the internet, and can be a great security measure to help prevent the use of technologies like Teredo without your consent.
If your current internet-facing edge firewall is not in some way IPv6 capable, throw it out. If it cannot inspect tunneled traffic, throw it out. You cannot have a good IPv6 security posture without a firewall that’s capable of filtering out the traffic, no matter what form it comes in. This applies even to those not implementing IPv6 – you may think that the time isn’t good for your organization to move to IPv6, and you may be right. However, IPv6 will find a way to run on your network in some fashion, and you need to be ready to kill it as it attempts to leave your network, if that is your desire. Cisco has a great article about configuring IPv6 traffic filters and firewalls – I highly recommend reading that if you have Cisco gear on your network.
Know IPv6 syntax for common firewall and access control implementations. Not having a firm grasp on IPv6 network security can be a big hurdle to migration. Take the time and learn IPv6 access lists in Cisco IOS, or how to set up ip6tables in Linux to filter based on v6 rules. If you have any experience with any of these in IPv4, you’ll quickly notice that the implementation isn’t that much different. For instance, here’s a sample Cisco IOS access list to allow certain IPv6 traffic:
1234 Router#conf tRouter(config)#ipv6 access-list ip6_aclRouter(config-ipv6-acl)#permit 2001:db2:1::/64 anyRouter(config-ipv6-acl)#permit 2001:db2:2::/64 any
Looks pretty familiar, right? No big deal. My recommendation is to start looking into the IPv6 counterparts to the firewall syntaxes you’re used to working with – you might be surprised with how similar it is, and once you get used to typing colons, the rest is pretty easy.