How-To: Implementing a Baseline for IPv6 Controls
March 11, 2014
Many organizations have IPv6 in their line of sight but are not ready to implement. Because the IPv6 protocol stack is enabled as a default on most systems, environments may be inadvertently running an ad-hoc IPv6 instance on their networks. This could mean IPv6 is already prevalent in a given environment.
Unaware of this IPv6 prevalence, administrators may not have the controls in place to enforce policy on this unwanted traffic. Protocol/services used to tunnel IPv6 and the IPv4 addresses reserved as “IPv6 relays” are available and waiting to facilitate traffic. This availability creates an opportunity for an adversary - or even a savvy non-malicious employee - to bypass security controls in a given environment.
Instituting a baseline of controls can help mitigate inadvertent IPv6 traffic from traversing a network - or at least minimize noise on a network - so security devices use fewer resources when identifying valid security events.
Organizations often leave IPv6 default settings enabled thinking that it’s not doing anything or that it will be one less step when they begin the IPv6 implementation process. This approach creates more “noise” on the network and provides unforeseen opportunities for adversaries to deny access or even breach and control given aspects of the network.
In addition to default, IPv6-enabled, Commercial Off-the-Shelf (COTS) software, “home-grown” software and applications can inadvertently create opportunities for IPv6 utilization. In cases where home-grown applications are running on vendor solutions or on proprietary systems - such as industrial microcontrollers that require the IP Protocol stack - odds are both IPv4 and IPv6 protocol would be compiled into the system and enabled - IPv4 for current use and IPv6 for future use.
What follows are the underlying mechanics and some of the technical means used to affect an environment. We won’t go into any in-depth examples. This is more of a conversation on how leaving IPv6 unchecked can create opportunities for a breach. These opportunities arise when certain means are introduced into an environment to tunnel IPv6 traffic via IPv4 and bypass security controls along the way. Identifying these opportunities allows administrators to implement mitigating controls or at least monitor for potential issues and loss of intellectual property.
In its basic form, IPv6 in a business production environment will use three protocols as a core for communications.
- ICMPv6 is utilized for Neighbor Discovery (RFC4861), which replaces ARP in IPv4.
- DHCPv6 (RFC3315) uses an IPv6 multicast address on UDP port 546 for clients and UDP port 547 for Server/Relay agents. As stated before most operating systems have the IPv6 protocol stack enabled so DHCPv6 will periodically send multicast requests in an effort to obtain an IPv6 address and valid IPv6 default router.
- DNSv6 (RFC3596) uses Quad-A (AAAA) records to facilitate DNS services as opposed to A-records in DNS (v4).
All environments differ, so there is no single best practice or recommendation that could be used for every organization. You may take the Defense in Depth model approach, utilizing COTS software with vendor solutions. Or, you may institute an Information Assurance phase into your systems analysis and design lifecycles to natively add security at the genesis level of application design. Either way, there will be a jigsaw puzzle of IPv6 services running on the network.
There are a couple ways to facilitate IPv6 communication. Some are easy to identify and some not so easy to identify. Some are older technologies and some relatively newer. Once an instance is internally based, IPv6 Local-Link addresses can provide a means for malware among other things to propagate through a network before it is picked up by security devices. This depends on the logical location of security devices within the environment.
As for Internet-directed opportunities, there are few mechanisms that can be used to obtain connectivity over IPv4.
- One method is simple GRE (RFC7059-3.4) tunneling which uses Protocol 47 but requires configuration on both ends of an agreed tunnel and is very visible leaving an environment.
- Connection of IPv6 Domains via IPv4 Clouds (RFC7059-3.5) uses a concatenated IPv4 address to facilitate a segment of IPv6 addresses and provides a tunnel interface that communicates via Protocol 41 encapsulated packets to traverse the IPv4 environment destined to an Internet IPv6 Relay.
- Another method is to implement an ISATAP “router” (MS-TechNet) available in Windows 2003 to current. It is mainly a Windows box that can be easily setup to communicate via IPv4 to an IPv6 relay via Protocol 41.
Worth mentioning - but outside the scope of this conversation - is malware based on the encapsulation of IPv6 in IPv4 packets that are destined to the Internet and attempt to bypass security controls not configured to identify this type of traffic.
These underlying means have a pattern of tunneling via a specified protocol whether it is Protocol 47 or Protocol 41, and these tunnels need to terminate somewhere. There is an identified IANA IPv4 IP address range 126.96.36.199/24 (RFC3068-2.3) reserved for 6to4 Relay Anycast (IPv6 Relay) terminations as well as IPv6 brokers that can provide IPv6 ranges and the tunnel configuration file required to link to them. All you need is a device that can support this functionality. A home router would meet this requirement. ICMP does need to respond to the tunnel broker, but in most environments ICMP reply is serviceable.
Establishing Baseline Controls
Aside from obtaining enhanced security services, there are certain steps you can take to reach a baseline of IPv6 controls. Controls can be instituted at the various layers of the OSI model. Standard protection should always include a foundation of antivirus, software patching, OS updates, OS firewalls, firewall appliances with up-to-date access control lists reviewed on an annual basis and network resource monitoring tools. However, these controls may not have IPv6 awareness.
First and foremost, senior management buy-in is a must for successfully implementing IPv6 controls.
The following bulleted list simply itemizes potential controls for a given environment:
- Deny traffic to the IPv6 relay address space 188.8.131.52/24.
- Review IPv4 DHCP configurations for registered devices/unauthorized devices.
- Identify IPv6 Brokers and understand what services they provide and how they provide them.
- Utilize Microsoft Group Policy to control IPv6 services at the server/desktop level.
- Utilized OS firewalls (Windows FW, IP Tables, etc.) to deny IPv6 interactions with clients.
- Monitor network for IPv6 addresses communication.
- Monitor network for multicast services for IPv6 DHCP regex ff02::1:2.
- Scan devices for open/listening ports for UDP 546 and UDP 547.
- Monitor network for IPv6 UDP 546 and UDP 547 traffic.
In addition to these controls for COTS solutions, developing homegrown applications should be addressed separately when it comes to IPv6 integration. Having an Information Assurance phase during design and development would ensure that information security approaches are integrated into the design throughout the development lifecycle. Using application sandboxes can provide the means to further see how homegrown applications process IPv6 packets as well as see what services and protocols are being used.
Whether the plan is to clear noise from the network so security devices are not processing benign traffic or whether it is to eliminate opportunities for security events to happen, the ultimate goal is the protection and optimization of a given business environment. If IPv6 is not ready for implementation, then steps should be taken to ensure controls and monitoring are in place to address any unforeseen and unwanted opportunities in an environment.