23 March 2012

Firewalling IPv6

Basic firewalling of IPv6 isn't a whole lot different to how we managed firewalls for IPv4.
Almost everything is the same, save for:
  • The Source and Destination Addresses have a different format (obviously).
  • Prefix lengths extend from /32 in IPv4 to /128 in IPv6.
  • We can no longer blatantly block ICMP traffic. You shouldn't do this in IPv4 either, but blocking ICMPv6 will stop IPv6 working altogether.
This is a short explanation of 2 significant changes network administrators will face going in to IPv6. If you want me to clarify somethings, or you can clarify something for me, please leave a comment.

NAT and Default Block
Mindsets are going to have to change. For the last nearly 20 years since the mid 1990's, network administrators have relied on the Network Address Translation (NAT) to provide a certain level of default security, and provide it easily to their "internal" network.

As a recap, NAT allows private (RFC1918) addresses that are by design not routed on the public internet to "hide" behind a public IP Address. This allows potentially tens of thousands of devices with private addresses to access the public internet and is the reason the internet has been able to survive this long without moving to IPv6.

This provides a level of security in that the "private" devices can access the internet, but the internet can not access these devices. To make a device accessible from behind a NAT, you have to explicitly make an effort to punch a hole in the NAT with a Port Forward to forward the traffic to the private device.

So, if the public internet can't access your devices, how can they attack them? This has been "good enough" security for a lot of networks, especially home networks and small businesses.

This all changes under IPv6; suddenly every single device with an IPv6 address is routable from every single other device in the world. A networked lightswitch in India can send a packet to a heart rate monitor in New York. A network connected fish tank in the UK can send a packet to a printer in New Zealand. The wireless weather station on the roof of my house can talk directly to a network switch deep "inside" IBM's corporate network.

While this opens up some exciting opportunities for a truly connected planet (universe?), it opens up some scary security issues that need to be considered.

A lot of devices have a deserved reputation of security issues; network attached printers for example. These issues are generally not too serious in an IPv4 world since most of the affected devices are privately addressed on an internal network, "protected" by a NAT gateway.

To mitigate the problems, we need to replicate the security NAT provides in an IPv4 world, using IPv6 technologies. So, looking functionally at what NAT does for security, it is nothing more than a Default Block. In other words, any traffic coming inbound is stopped at the border. In our IPv4 world, we have thought of our internal network as being private. This assumption is no longer valid once you've moved to IPv6. Your internal network is now entirely and small part of the internet.

So, step number one is to stop the world talking to your internal network. Setup the devices on your network perimeter to explicitly reject any incoming connections (don't forget to allow return traffic for connections that were initiated outbound). There are exceptions to this such as ICMPv6 (below), but you don't want the world to be able to talk to a rouge web or ftp service on your internal network.

While you're at it, defense in depth and check all your host firewalls too. Even Windows Firewall has become capable since Windows 7 and 2008. Remove those "Accept All" rules and invest the time to make sure you have a valid rule-set implemented.

This is important, and another required mindset change for many network administrators. You can not blatantly block ICMPv6 when you are running an IPv6 network. Let me repeat that:


ICMPv6 is used for various critical purposes for daily operation of IPv6. The venerable 'arp' protocol is replaced with ICMPv6 Neighbor Discovery; so one of the first things to break if you block ICMPv6 will be your ability to talk to other hosts on your network segment. Including your router.

I won't go in to great detail here; RFC 4890 has an excellent overview of the situation that you should read, understand and follow.

I explicitly use a wrapper/helper application called husk to manage both the IPv4 and IPv6 firewalls on my Linux hosts. Disclaimer: I am the author of husk!

Husk has IPv6 support which makes it easy to manage firewalls for both IPv4 and IPv6 at once. As mentioned at the start of this article, not much has changed so being able to manage both IP versions in the same tool is great. Management is simplified to the point that when I use hostnames of dual-stack hosts in my husk rules, at compile time the hostname is resolved to the correct address by iptables and ip6tables respectively. One rule for both IP versions keeps it simple and manageable.

No comments:

Post a Comment