IPv6 Security in Layer-2 Firewalls
You can configure many firewalls to act as a router (layer-3 firewall) or as a switch bridge (layer-2 firewall). The oft-ignored detail: how does a layer-2 firewall handle ARP (or any layer-2 protocol)?
Unless you want to use static ARP tables it’s pretty obvious that a layer-2 firewall MUST propagate ARP. It would be ideal if the firewall would also enforce layer-2 security (ARP/DHCP inspection and IPv6 RA guard), but it looks like at least PAN-OS version 11.0 disagrees with that sentiment.
Straight from Layer 2 and Layer 3 Packets over a Virtual Wire:
In order for bridge protocol data units (BPDUs) and other Layer 2 control packets (which are typically untagged) to pass through a virtual wire, the interfaces must be attached to a virtual wire object that allows untagged traffic, and that is the default. If the virtual wire object Tag Allowed field is empty, the virtual wire allows untagged traffic. (Security policy rules don’t apply to Layer 2 packets.)
I read this as “please feel free to do ARP hijacking on a supposedly protected subnet.” I hope I’m wrong and would appreciate a pointer to a document explaining how PAN-OS enforces source address validation.
But wait, it gets worse. From the same web page:
If you want to be able to apply security policy rules to a zone for IPv6 traffic arriving at a virtual wire interface on the firewall, enable IPv6 firewalling. Otherwise, IPv6 traffic is forwarded transparently across the wire.
Let me reiterate that (and I checked the configuration instructions to be on the safe side): by default, Palo Alto firewalls pass IPv6 traffic between Virtual Wire (layer-2) interfaces.
You can probably guess how the rest of this blog post will look like (hint). Anyway, here we go:
- Nobody wants to configure IPv6.
- Windows and major Linux distributions have IPv6 enabled by default.
- Because nobody cares about IPv6, it’s sometimes left enabled.
- Likewise, there’s a non-zero chance that whoever configured the layer-2 firewall decided IPv6 didn’t matter.
- Unless you’re using more modern components like nftables1 (or eBPF 😉), Linux servers filter IPv4 traffic with iptables and IPv6 traffic with ip6tables. If your server administrators don’t care about IPv6 they probably haven’t configured ip6tables with a DENY ALL rule.
What could possibly go wrong? How about:
- Someone gets root access to the least-protected server on the subnet.
- They start IPv6 RA daemon and all other nodes (including servers across the layer-2 firewall) get IPv6 addresses.
- Unless someone configured IPv6 firewalls/ACLs on the other servers, they’re now wide open to the intruder.
But wait, it gets better:
- Include DNS option in IPv6 RA
- That will make other servers use the compromised server as their DNS server.
- The fake DNS server can return AAAA records for every query, forcing all other servers to establish new sessions over IPv6 and thus send the traffic to the first-hop IPv6 router (the compromised server).
- A Palo Alto layer-2 firewall (unless explicitly configured for IPv6 firewalling) would happily propagate that traffic.
As always, it must be the DNS’ fault 😜, and the optimum solution must be to use /etc/hosts files 🤣.
Want even more details? You’ll find them in the IPv6 Security webinar and in the Network Security Fallacies part of How Networks Really Work.
Revision History
- 2023-05-01
- Added nftables as a replacement for iptables/ip6tables.
-
Mentioned by Alexey Popov in a comment. I’m way too rusty when it comes to Linux. Also: one has to love many ways of getting the same job done ;) ↩︎
It's not only a firewall problem. Ignoring or not having IPv6 security in e.g. wireless equipment can also be a lot of fun (or not, depending on which side you are on). If you don't care about IPv6 you'll probably don't care about any of the IPv6 security features.
Imagine a guest network in a hotel and some modern entertainment systems in the rooms. Guest should be able to stream music from their phone to the audio system and videos to the TV in their rooms. Client isolation on the wireless probably won't work because of this.
Now comes the attacker (which might be a bored guest) and announces an IPv6 prefix + DNS via RA ....
PS: I always wanted to implement this feature on something like an ESP8266 and hide that in an USB outlet. ;-)
For using Palo Alto networks firewalls in a daily basis, they do not enable ipv6 firewalling by default. This is a device wide settings, which means that it does not only impact virtual wires. Once the checkbox is enabled, however, they do ipv6 firewalling, even if I never had the chance to try and evaluate their efficiency on the matter...
For the L2 security part, I must only agree. It sad they don't incorporate a minimal amount of L2 security in a virtual wire setting...
Hope this helps the debate!
Hey Ivan et al.
I just did a factory reset on a PA-220 (PAN-OS 10.2.3) and the "IPv6 Firewalling" checkmark was enabled by default. Good news. ;)
However, I still don't know how this option is set on other firewall models or PAN-OS versions. I remember that this "IPv6 Firewalling" was not enabled by default on older PAN-OS versions. Neither do I know how it is set on PAN-OS 11.
Cheers, Johannes
> Linux servers filter IPv4 traffic with iptables and IPv6 traffic with ip6tables. What about nftables, which does have a common inet table, and which has been part of linux kernel for a decade or so, and which is a default backed of lets say firewalld on RHEL?
Thanks for the pointer (and I learned something new ;). Added.