Posted on by Vulnerability Analysisin
Hello, its Ryan. We've noticed a misconception about IPv6 that is popular on the internet: that IPv6 addresses are hard to ping sweep because there are so many possible addresses. Ping sweeping can lead to port scanning, so this misconception is viewed as a security feature. In this post, I'll prove that, while it won't work across the internet, ping sweeping on the local network is easier in IPv6 than in IPv4.
Before we go further, if you don't know what IPv6 is, read this Wikipedia entry. Essentially, IPv6 is a new protocol that is a lot like the currently deployed IPv4, but it has many more addresses (about 2^128 total). It is so much like IPv4 that a lot of network gear supports IPv6 without any modifications. Most newer operating systems have native IPv6 support, and many prefer IPv6 connections over IPv4 ones.
On our IPv6 test network, we are running a few Linux machines and an OS X laptop. On one of the Linux machines, we run the following command:
ping6 -I eth0 ff02::1
And, on this machine, the neighbor cache fills up with all the link local addresses of the other computers connected to the node. Linux systems with iproute2 can use command
to show the neighor cache. Folks on Windows Vista and Server 2008 can use the netsh command
netsh interface ipv6 show neighbors
What just happened?
Well, we sent an ICMPv6 echo request (type 128) message to the all-nodes multicast address. All the nodes that were listening sent back the ICMPv6 echo reply (type 129) message. When we received these messages, their link-local (and MAC) addresses were added to our neighbor cache. eth0 is the interface connected to the network (the -I flag is needed when pinging the multicast address).
Ok, so that was fun--we just created a list of all the link layer addresses on our Ethernet segment. The next exercise is even more fun. Run this command:
ping6 -B -I eth0 -I [global IPv6 address attached to eth0] ff02::1
Now check the neighbor cache. It will show the global IPv6 (the equivalent of a public IPv4) address. We just discovered the global IPv6 addresses of the hosts on our network.
These commands won't work across the internet because, in general, multicast isn't supported across the web. They also won't work with hosts that filter ICMPv6 types 128 and 129 (which is not compliant with RFC 4980 section 4.4.1). However, it is not possible to block all ICMPv6 types, and an analysis of restrictive host-based firewalls will likely show that some multicast ICMPv6 traffic is allowed.
So what can you do about this problem? Not that much, and the truth is, it isn't really a problem. Things are working exactly as they should, and security effort is usually better spent making sure hosts are secure, not obscure.
Many network managers think their networks don't support IPv6 because it hasn't been officially deployed. Most networking gear we tested that works at layer 2 seems to pass IPv6 packets with no problem. Flat networks will probably support IPv6 just fine. Almost all popular operating systems support and prefer IPv6.
So, what's to prevent an attacker from starting a stateless auto-config server (a way to send router advertisements), passing out IPv6 addresses, and possibly conducting ping sweeps on your network? Probably nothing. If you purchased network security equipment that protects you from IPv4-based attacks, this doesn't need mean that it's broken. IPv6 is a new protocol, and you'll probably need to deploy new equipment, upgrade old equipment, and/or notify users of the risks of running IPv6 on your network. An applicable analogy is that its like purchasing a Blu-Ray disc for a movie that you already own on DVD.
If you'd like more information about how this works, email us at firstname.lastname@example.org with INFO#498112 in the subject line. We have some other blog posts about IPv6 coming soon, and we'd like to know answers to these questions: