In this part of the series (for the other parts see [1], [2], [3], [4], [5]) we’ll discuss approaches to implement security measures suited to protect from IPv6-related threats on the host level.
These can be grouped into the following generic categories each of which will be described in more detail in the following:
- “Minimal machine” approach
- Static configuration of IPv6 parameters
- Tweaking the behavior of IPv6-related mechanisms/protocols
- Local packet filtering
Some of you might recall that we published IPv6 hardening guides for both Linux and Windows a while ago and we’ll reference those exact documents below, by [Hard_Linux] and [Hard_Windows] respectively.
“Minimal machine” Approach
This approach encompasses all activities where a certain (IPv6-) functionality is removed or disabled in order to decrease the threat potential/attack surface related to this functionality.
From our perspective the following measures should be considered for implementation on specific systems:
- Usually on Linux systems MLD can be disabled (or, depending on the default state, just not be enabled) without affecting proper operations which, evidently, in turn prevents all threats in the context of MLD on the affected host(s). For a more thorough discussion of MLD see here or here.
In contrast, on Windows systems disabling MLD (through a specific netsh command) creates a state where Neighbor Discovery does not work correctly anymore, which is the reason why we do not recommend this here. - If systems are provisioned with static IPv6 addresses, DHCPv6 should be disabled as a service (Windows and Linux).
- On systems with static IPv6 addresses, the processing of router advertisements can be disabled as described in [Hard_Linux], Sect. 5.2 or [Hard_Windows], Sect. 5.4. In any case, here the operational feasibility and the resulting overhead must be considered. In some cases, for example after a recompilation of a new kernel or the installation of a new patch, systems might start again to process router advertisements. Also this measure results in a significant “deviation from default” , which means that there is potentially much operational effort required to keep the settings in this well-defined state during the complete life cycle of the systems.
Static Configuration of IPv6 Parameters
Usually many IPv6 properties of hosts are configured through mechanisms involving a high degree of dynamics (such as router advertisements). As a consequence, some of the associated risks may be mitigated by pursuing a strategy of static configuration of parameters. Let us repeat: it should be kept in mind that such an approach can lead to significant increase as for the operational effort.
From our perspective the following measures should be considered for implementation on specific systems:
- Static configuration of IPv6 parameters according to [Hard_Linux], Sect. 4 or [Hard_Windows], Sect. 4.1f. Again, it must be kept in mind here that the mere configuration of static IPv6 parameters does (in contrast to IPv4) not disable the potential concurrent performance of dynamic procedures (such as stateless autoconfiguration/SLAAC). To achieve that objective, all dynamic IPv6 mechanisms have to be disabled as well (see also above).
Tweaking the Behavior of IPv6-related Mechanisms/Protocols
Most operating systems allow for the specific adjustment of the actual behavior of IPv6 core and helper protocols. Some types of adjustments can be explicitly performed to decrease the IPv6-related threat potential/attack surface and increase the security level.
From our perspective the following measures should be considered for implementation on specific systems:
- Use of MLDv2 only according to [Hard_Linux], Sect. 5.4.
- Enabling of a behavior that follows RFC 6980, if that is not default state of an OS (for example, it actually is the default for Linux). RFC 6980 prescribes that IPv6 stacks should drop fragmented neighbor discovery (and router advertisements) packets, which cannot occur in real-life/in production networks and which are hence only generated by attack tools.
Local Packet Filtering
As an ultima ratio approach it can be considered to enable local packet filters to filter IPv6 traffic and address some more security problems.
From the our perspective the following measures should be considered for implementation on specific systems:
- Local packet filtering of IPv6 packets according to the relevant sections of [Hard_Linux], Sect. 6 or [Hard_Windows], Sect. 6.
===
The above was meant to provide an overview of potential approaches to IPv6 security from the perspective of individual systems (as opposed to a network infrastructure perspective). I will discuss this stuff in more detail in my upcoming “Protecting Hosts in IPv6 Networks” talk at the Troopers IPv6 Security Summit.
As always we’re happy to get feedback by any means.
Everybody have a great day,
Enno
These are my next public IPv6 activities:
- I’ll be on the IPv6 Panel at Cisco Live in Berlin.
- Contribution of some talks and stuff to the IPv6 Security Summit (see above).
- “IPv6 in Enterprise Networks” training in April, in Duesseldorf.