Can Your IPv4 Firewall Be Bypassed by IPv6 Traffic?

Do you have a firewall? Maybe it's not as useful as you think it is. I was surprised to discover that IPv6 was enabled on several hosts with default firewall policies of ACCEPT and no rules. This allowed IPv6 traffic to completely bypass the numerous IPv4 rules!

IPv6 makes me queasy security-wise due to features such as making all IPv6 hosts into routers that obey source routing, as well as the excessively eager and accepting autoconfiguration. More recent doesn't imply more secure, especially if it's unmanaged because you don't realize it's ON. The issue is IPv6 being enabled by default in a fully open mode. Not everyone realizes this is happening, as we're very much still thinking in terms of IPv4. Even auditing tools such as Lynis (for Linux/UNIX systems) don't report this; it only checks if the IPv4 ruleset is empty. There are going to be a lot of security problems because of this. I know it's been so for some time, but awareness lags. I'm not the only one who thinks it's going to be a bumpy ride, as pointed out elsewhere.

You can mitigate this issue in several ways, besides learning how to secure IPv6 (which you'll have to do sometime) and using your plentiful spare time to do so enterprise-wide. Changing all the default IPv6 policies to DROP without adding any ACCEPT rules breaks things. For example, Java applications try IPv6 first by default and take several minutes to finally switch over to IPv4; this can be perceived as broken. If you have Ubuntu on your desktop, you can use ufw, the Uncomplicated FireWall, to configure your firewall with a click of the mouse. When "turned on", it changes the default policy to DROP but also adds rules accepting local traffic on the INPUT and OUTPUT chains (well done and thanks, Canonical and Gufw developers). This allows Java applications to contact local services, for example. You can also disable IPv6 in sysctl.conf (and have Java still work) if you have a recent kernel (e.g., Ubuntu 10):

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

followed by a reboot. You can also do this immediately, which will be good only until you reboot (note: sudo alone doesn't work, you need to do "sudo su -"):

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6

This removes the IPv6 addresses assigned to your network interfaces, and then Java ignores IPv6. If you have an "old" kernel (e.g., the most recent Debian) and need to support Java applications, the above kernel configurations are not available at this time. However, there are other ways to disable IPv6 for Debian, well documented elsewhere. You can also manually add firewall rules like those done by ufw, as described above.


Posted by Minime
on Tuesday, September 21, 2010 at 02:56 AM

Yeah. Why fix it, when you can disable it… great tip </sarcasm>

Posted by Pascal Meunier
on Tuesday, September 21, 2010 at 07:12 AM

Minime, the first step for hardening systems is to disable what you don’t need.  In general, there are more problems than there is time.

Posted by Jeremy
on Wednesday, September 22, 2010 at 03:43 PM

Why don’t you just create firewall rules for IPv6.  Like using ip6tables.  Recreate the same v4 iptables rules for ip6tables.  Then make sure net.ip6.forwarding is off.

Posted by Pascal Meunier
on Wednesday, September 22, 2010 at 04:16 PM

Jeremy, that’s first because we have dynamically managed, complex rules that use forwarding to and from openvz containers.  Having duplicate sets adds complexity and requires verifying that they match. 

Also, even though iptables and ip6tables have the same syntax, the differences in IPv4 and IPv6 can require a careful review.  The translation isn’t trivial except for uncomplicated or not very restrictive firewalls.  For example, ICMP can be almost entirely blocked in IPv4 with few negative consequences, but in IPv6, ICMP can’t be blocked so aggressively.

Leave a comment

Commenting is not available in this section entry.