Here we are, all the way up to Myth #4! That makes this the 4th installment of our 10 part series on the top IPv6 Security Myths.
This myth is one of my favorite myth’s to bust when speaking with folks around the world. The reason for that is how many otherwise well-informed and highly experienced engineers, and others, hold this myth as truth.
It’s understandable, really. In IPv4 the largest subnet you’re likely to encounter on any given LAN is a /24, which allows for up to 256 host addresses. Scanning 256 addresses for responsive devices and open ports is downright trivial – and most subnets are even smaller than that! In the brave new world of IPv6, the standard minimum subnet size for any LAN is a /64. An IPv6 /64 allows for up to 18,446,744,073,709,551,616 (about 18.4 Quintillion) host addresses. To frame this a bit better, my friend and colleague Jan Zorz, is fond of asking: “How many hosts can you fit in one /64?” The answer, of course, is “all of them.” Now you can see where the myth comes from: Using traditional techniques, it is impossible to scan that many addresses in a single human lifetime. If you could scan one million addresses every second, it would take about 584,555 years to scan just one /64!
Myth: IPv6 Networks are too Big to Scan
Reality: Many Addressing Techniques Reduce the Search Space
Fortunately for attackers, IPv6 nodes tend to clump up in certain IPv6 address ranges. In other words, scanning IPv6 networks is not impossible because there are shortcuts available that allow attackers to find devices without scanning all the addresses. Let’s take a look at some of these, and how you can help prevent making it so easy for the bad guys.
There are generally three ways to configure the IPv6 address for a given node/interface (SLAAC, DHCP, manual) and all of them are wrong. OK, not quite, but they can all be done wrong, in ways that will expose your network to address and port scanning attacks.
SLAAC (StateLess Address AutoConfiguration)
Traditionally SLAAC uses modified EUI-64 format interface identifiers, which basically takes the interface’s MAC address and stuffs the hexadecimal word “0xfffe” in between the OUI (Organizationally Unique Identifier) and the second half of the MAC address, plus setting the “Universal” bit to 1. For example, the MAC address 00.00.5E.00.53.01 would become the IID (Interface Identifier) 0200:5EFF:FE00:5301.
The main problem here is twofold. One, every SLAAC address created in this way includes 0xfffe as bytes 4 and 5 of the IID, signaling the address type and simultaneously reducing the search space (the number of numbers to scan). Two, OUIs are well known and so attackers can further reduce the search space by focusing on existing OUIs, OUIs for specific device types, etc.
Making matters worse, virtual machines and groups of devices bought all together may have sequential (or other distinguishably patterned) MAC address numbering. This can further reduce the search space or even, in some cases, mean that finding one responsive address could lead easily to finding the others (by searching sequentially up and down from the “hit”).
The best solution to this challenge is to use “Semantically Opaque Interface Identifiers” as described in RFC 7217. Luckily, work is underway to make that the default method for generating the IPv6 addresses assigned by SLAAC. Until then, think carefully about the risks of embedding hardware addresses in your IIDs before deploying SLAAC, and perhaps look for implementations that already use the RFC 7212 scheme.
DHCPv6 (Dynamic Host Configuration Protocol version 6)
Many network administrators looking for greater accountability and control over their dynamically configured network turn, quite rightly, to DHCPv6. This can be problematic from an address scanning point of view because many DHCPv6 servers assign addresses to clients sequentially (e.g. ::100, ::101, etc.). As you can probably guess, this significantly reduces the search space. All an attacker has to do is scan the lowest IIDs of any network to find all of your network’s nodes.
You can mitigate this risk by starting your addressing pools with a numerically high address (i.e. not ::10) and, even more importantly, by randomizing the sequence and sparseness of assigned addresses. As stated in RFC 5157:
Further, it is desirable that allocated addresses are not sequential and do not have any predictable pattern to them. Unpredictable sparseness in the allocated addresses is a desirable property.
Manually configured addresses
Manually configured interface addresses are often plagued by the same problems that DHCPv6 assigned addresses are but worse. Namely low numerical value and sequential numbering. Hoe many times have you configured a point to point link that ended in ::1 and ::2 (or 0 and 1, etc.)? Probably more than once.
Low-byte sequential addresses aren’t the only risk here though. Many of us have found clever ways to use the new hexadecimal address space. Unfortunately, many of these can actually make it easier for attackers to scan our networks. Embedding the IPv4 address, the TCP/UDP port number, or human readable words (e.g. ::dead:beef) into the IID all make those addresses easer to find.
Additional Threats
Regardless of your chosen address configuration method, there are some additional risks to keep in mind when considering the validity of this myth.
With any address scanning technique or methodology, the attacker must know which network to scan, right? Part of this is unavoidable, you have to announce your IPv6 address space out via BGP, put a listing in WHOIS, etc. But you can make it harder (or easier) for attackers to find individual /64s within your aggregate IPv6 space. Just like with individual interface identifiers, it’s likely a bad idea to build obvious patterns into your subnet identifiers. Some examples are numbering sequentially or embedding addresses/VLANs/IPv4 subnets/etc. Just like with IIDs, I have to recommend against using these visible patterns in your network addresses.
Many tunneling techniques such as 6to4, ISATAP, and Teredo use well-known addresses or algorithms for addressing that make devices using these technologies potential targets for network scanning. Worse is that some of these transition/co-existence mechanisms are active by default on some devices. Keep an eye out!
There are also ways around network scanning all together in some cases. Watch out for application-layer protocols leaking out IPv6 addresses (e.g. email). Remember that if one local node is compromised, neighbor discovery, link-local multicast addresses, and node information queries can all make short work of discovering and documenting the entire local network, and beyond.
Finally, don’t forget that anything published in the DNS (including reverse mappings) is potentially open to public probing!
I highly recommend that folks interested in this topic take a look at draft-ietf-opsec-ipv6-host-scanning, which treats this subject in much more detail. As always, there are also many additional IPv6 resources including some security specific resources available from Deploy360.
This post also appears on the Deploy360 blog.
