Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may refer to this post or to this talk from the Troopers NGI event).
Some of this has already been discussed in RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls but that document is from 2007 and things may have changed in the interim.
Let’s start with a quick look at the traffic which might be of interest. We will take a server perspective here, read: which types of IPv6 traffic might have to be accepted by a host/NIC firewall in order to support proper operations? I will discuss the following, with a focus on the implications of filtering them locally:
- IPv6 Extension Headers
- ICMPv6 Types 1–4
- Router Advertisements
- Neighbor Solicitations & Advertisements
- ICMPv6 Redirects
We assume a white-list based filtering approach (“allow known-good stuff and deny the rest“) and will give a respective recommendation for each of those types of traffic.
To be discussed first as they might show up very early in a filter list (supposing that one is processed sequentially). In the following (and similar to the remarks in the “Why IPv6 Security Is So Hard – Structural Deficits of IPv6 & Their Implications” talk) the term “IPv6 extension headers” denotes the “standard” ones as of RFC 2460 except for AH & ESP, which then leaves: HBH, Routing Header, Fragment Hdr, DestOptions.
There’s two main reasons to include them in our discussion and, in one way or another, in the filter list. It’s well known that EHs can be abused for nefarious things on the local link. Presumably router advertisements will be allowed later on (see below), and RFC 6980 might only provide limited protection against RA Guard evasion attacks (as laid out here and here) so having an additional layer of security (against extension headers) is probably a good idea. Furthermore some security products/components might expose a different default stance as for filtering EHs (e.g. Check Point firewalls filter most of them by default; also see Antonios Atlasis‘ research on several firewall products some years ago) so if you want to deploy a consistent policy you either have to find out the exact behavior of the filtering component in place or apply a well-defined ruleset yourself.
Last but not least one may keep in mind that packets with EHs but otherwise permitted upper layer protocols might not be blocked by a final “default deny“ rule.
In case inter-subnet multicast is needed, allowing HBH is probably helpful.
You may also want to generally allow fragmented IPv6 packets and hence the fragment header, but on the other hand this would include allowing fragmented ND/RA packets which bears quite some risks (see the above sources on RA Guard evasion).
Overall this gives the following recommendation:
- Allow AH & ESP in case IPsec is needed towards the host.
- Allow HBH in case MLD is needed (see also below).
- Allow fragment header in case you consider it possible that legitimate fragmented packets come in (thinking of DNS[Sec] you may read this first). If you do so, reflect on explicitly denying fragmented RA/ND traffic but this might not be supported configuration-wise and it might be debatable from a rule-set complexity/operational effort perspective.
- Explicitly deny other EHs, namely routing header (type 43) and Destination Options (type 60).
ICMPv6 Types 1–4
All of these are diagnostic/error messages and hence considered vital for the proper functioning of network communications (in particular type 2 [PTB]). We hence recommend to allow (“don’t touch“) them. Besides Black Nurse (which mainly affected network devices/firewalls – has anybody ever tested against host operating systems? We’re not aware of any testing against host OSs… does any of our readers know any stuff?) there’s not many (publicly known) security issues with/of these packets.
Except for very specific circumstances (tenant isolation in cloud environments comes to mind) you’ll want to allow inbound Ping (Echo Request – ICMPv6 type 128) to a system. For the record: I’m a networking guy, with an operations background, and subsequently have always been in the “the operational benefits of Ping are far greater than the real [usually even: perceived] negative security impact“ camp.
From an overall architecture perspective RAs are/can be considered the most important IPv6 packets at all (I mean, they kind-of bring life to IPv6 stacks, which is why I occasionally compare sending an RA to a system with “kissing the sleeping beauty” ;-). We would hence expect to allow them (and in the past mailing lists used to be full of messages of people who broke their network connectivity by erroneously filtering them) but strictly speaking you might not need them in one specific scenario (the “fully static configuration” approach from the server configuration post). Even in such a setup/setting we recommend to be very careful to filter RAs, given their role in the big IPv6 picture.
Recommendation: allow. In “fully static configuration“ scenario one might deny/block them, but should do so only after diligent testing.
Neighbor Solicitations & Advertisements
In most cases blocking NS/NA packets (on an Ethernet link at least) will break something. As a consequence you should simply accept/allow them. In case you’re concerned about NDP spoofing attacks a local packet filter would be the wrong control anyway (NDP inspection on switch ports comes to mind but has its own set of limitations, not to be discussed in the present post).
Since many years there have been security discussions around ICMP(v6) redirect messages (ICMPv6 type 137). Strictly speaking those are packets with a fully valid purpose and maybe even needed in some cases. On the other hand they can easily be abused for malicious purposes (traffic redirection) which is why it’s probably a good idea to block them (from an operational impact vs. associated security risk ratio perspective).
Recommendation: no action needed in a white-list rule set. If really really needed, allow them (ICMPv6 type 137).
As long as no inter-subnet multicast communication is actually needed/in place you probably won’t need MLD. This can be expected for the vast majority of networks where the type of filtering we discuss here is applied at all. You can subsequently block MLD (as opposed to entirely disabling it which on Windows breaks ND, but not on Linux; see also this post. Windows is not covered there, we can still confirm through lab testing.)
Recommendation: no action needed in a white-list rule set. If really needed, allow ICMPv6 types 130–132 and maybe 143 (depending on MLD versions in use).
In case DHCPv6 is involved in parameter provisioning to the systems in question (for learning the DNS resolver[s] or when using the “DHCPv6 with reservations” configuration approach described here) you’ll need (to allow) it. In all other scenarios it won’t be needed.
RFC 3315 states: “Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.“
This means that, from a host/server perspective, inbound UDP 546 is needed (probably the client port of server-side packets is not always deterministic => do not include a source port in the rule). You may also keep in mind that disabling a local DHCPv6 client might yield unintended results on Windows systems, depending on the method chosen for the task (see also this post) so blocking those packets might be the best way of getting rid of DHCPv6 interactions.
Recommendation: no action needed in a white-list rule set. Explicitly allow inbound UDP 546 once a system needs to receive DHCPv6 messages.
As always we’re happy to receive feedback from you guys.
Everybody have a great day