Is it time for IPv6?
IPv6 - Opportunity, Necessity or Threat?
A few years ago, counters presenting the diminishing pool of available IPv4 addresses were very popular on the Internet. The closer to zero the value on the numerator approached, the more it aroused interest in the new version of the protocol - IPv6. Producers of network devices, operating systems and Internet providers quickly intensified their activities aimed at preparing them to work in the new reality. Their homework was to a greater or lesser extent done by them. The IPv4 counters have reached zero and… nothing has changed practically. In both home and business applications, hardly anyone thought about IPv6. While IANA distributed the last available pools of IPv4 addresses to regional registries (RIR), it was not a major problem for end users. The regional registers had some reserves of address space for the following years. With time, however, these also began to melt and reach zero. The situation repeated itself, but this time the role of the buffer with the backup address space was taken over by local registers (LIR), which are mainly large Internet providers. This resulted in a tightening of IPv4 address allocation policies at the level of regional registries. For example, the European RIPE has stopped registering new ASs (Autonomous Systems) for clients applying for PI (provider independet) in version 4 addresses. offer their own addresses from the pool assigned to them as LIRs. This state of affairs has continued since 2012. Although this is really the last stage before the actual exhaustion of IPv4 addresses, few people are interested in the implementation and, above all, the proper protection of the infrastructure working on IPv6.
I am not using IPv6, is it an issue with me?
Practice shows that the mass use of address translation allows even large organizations to maintain their infrastructure with relatively small pools of public IPv4 addresses. Quite a few companies, when applying for addressing, also overestimated their actual demand for public addresses in order to guarantee themselves more inventory and the possibility of flexible infrastructure development. Therefore, the need to implement IPv6 concerns mainly organizations applying for a new, public PI (providers independent) address and wanting to register their own AS (autonomous system) for the purposes of e.g. BGP multi-hosting.
So what about the rest of them who are satisfied with their IPv4 resources? Don't these organizations need to be concerned with IPv6 security? On the contrary. Systems with a new protocol implemented, whether we need it or not, have been present in our networks for a long time. Every system since Windows 7, and even before that in Linux, has the IPv6 stack running by default. Moreover, some characteristic features of this protocol, such as the ability to auto-configure without the presence of a DHCP server, make it possible to successfully operate in our network without any special involvement of administrators, or even without their knowledge.
Is the threat real?
All solutions aimed at ensuring the security of network services are oriented to a specific communication protocol. Firewalls, proxies, email scanning gateways, VPN gateways and all other mechanisms built to secure the IPv4 protocol do not have any use in the case of IPv6, unless the protocol is implemented and properly configured on them. A firewall that blocks inbound traffic for IPv4 will remain neutral to IPv6 traffic unless its rule equivalent is enabled for that protocol. Below is an example of a Linux server port scan where the firewall (iptables) is blocking all incoming traffic:
> nmap 10.10.0.22 Nmap scan report for 10.10.0.22 Host is up (0.00025s latency). All 1000 scanned ports on 10.10.0.22 are filtered Nmap done: 1 IP address (1 host up) scanned in 21.43 seconds
But what happens when the same server is scanned using the IPv6 protocol?
> nmap -6 20a2: 54: 200: 21 :: 2 Nmap scan report for 20a2: 54: 200: 21 :: 2 Host is up (0.00043s latency). Not shown: 991 closed ports PORT STATE SERVICE 21 / tcp open ftp 53 / tcp open domain 80 / tcp open http 110 / tcp open pop3 143 / tcp open imap 443 / tcp open https 993 / tcp open imaps 995 / tcp open pop3s 9876 / tcp open sd Nmap done: 1 IP address (1 host up) scanned in 7.39 seconds
As you can see, blocking all traffic using standard firewall rules does not block access to services at the IPv6 level in any way. In the case of Linux, in order to block this traffic it would be necessary to use the iptables equivalent dedicated to IPv6 traffic, ie ip6tables. An example of a rule that blocks incoming traffic on port 22 (ssh) is shown below:
/ sbin / ip6tables -A INPUT -p tcp -s 0/0 -d 20a2: 54: 200: 21 :: 2 --dport 22 -j REJECT -i eth0
As you can see, apart from the command itself and the IP address format, this rule has the same syntax as the iptables rules for IPv4. Therefore, in order to properly secure the services, no expert knowledge is needed to learn about new tools. However, it is necessary to be aware of the risks. It's a big mistake to assume that we don't need to worry about IPv6 security if we don't use it. As mentioned above, this protocol is already present in our networks and systems, regardless of whether we implemented it consciously or if it was left there as a result of an oversight. It is also a common mistake to assume that in order to protect against threats it is enough to turn off IPv6 on network interfaces. Doing so will limit communication with the outside world, but will not disable protocol support in the kernel. What happens when we ping our host with IPv6 disabled on the interfaces?
> ping6 :: 1 PING :: 1 56 data bytes 64 bytes from :: 1 icmp_seq = 1 ttl = 64 time = 0.017 ms 64 bytes from :: 1 icmp_seq = 2 ttl = 64 time = 0.027 ms 64 bytes from :: 1 icmp_seq = 3 ttl = 64 time = 0.026 ms 64 bytes from :: 1 icmp_seq = 4 ttl = 64 time = 0.025 ms
As you can see, communication via the loopback interface (:: 1 is equivalent to 127.0.0.1) is still possible. Thus, it is also possible to access services locally via IPv6, despite its being disabled on network interfaces.
How are the intruders prepared?
Our lack of awareness and commitment to the process of protecting communications using the IPv6 protocol is just one of the factors that contribute to the threat. Another is the creation and continuous development of tools used for research and possible breaches of security. An example of a suite of such tools is "The Hacker Choice's IPv6 Attack Toolkit" (aka thc-ipv6). After its installation in the system, there is quite a large list of tools, the names of which sound scary:
atk6-address6 atk6-dnsrevenum6 atk6-extract_networks6 atk6-fake_mldrouter6 atk6-flood_mld26 atk6-four2six atk6-kill_router6 atk6-redirsniff6 atk6-trace6 atk6-alive6 atk6-dnssecwalk-atk6-alive6 atk6-dnssecwalk-atk6-alive6 atk6-dnssecwalk-atk6-alive6 atk6-dnssecwalk-fakekld6-atk6-alive6 atk6-dnssecwalk-atk6-alive6-dnssecwalk-atk6-alive6-dnssecwalk rsmurf6 atk6-covert_send6 atk6-dos_mld atk6-fake_dhcps6 atk6-fake_router26 atk6-flood_mldrouter6 atk6-fuzz_dhcps6 atk6-ndpexhaust6 atk6-sendpees6 atk6-covert_send6d atk6-dos-new-ip6 atk6-fake_dns6d atk6-fake_router6 atk6-flood_redir6 atk6-fuzz_ip6 atk6-node_query6 atk6-sendpeesmp6 atk6-denial6 atk6-dump_dhcp6 atk6-fake_dnsupdate6 atk6-fake_solicitate6 atk6-flood_router26 atk6-implementation6 atk6-parasite6 atk6-smurf6 atk6-detect-new-ip6 atvouter6-dk6-detect-new-ip6 atvouter6-dk6-implementation-new-ip6 atvouter6-dk6-implementation -passive_discovery6 atk6-thcping6 atk6-detect_sniffer6 atk6-exploit6 atk6-fake_mld26 atk6-flood_advertise6 atk6-flood_rs6 atk6-inject_alive6 atk6-randicmp6 atk6-thcsyn6 atk6-dnsdict6 extract_hosts6 atk6-fake_mld6 atk6-flood_dhcpc6 atk6-flood_solicitate6 atk6-inverse_lookup6 atk6-redir6 atk6-toobig6
It is worth taking a look at the above tools and their possibilities in order to realize the scale of certain threats and the associated risks.
I hope this article sheds some light on the issues related to IPv6 protection. If the topic turns out to be interesting, perhaps in the following parts we will jointly review the tools from the thc-ipv6 package and show the possibilities of their use in order to increase the security of our own networks and systems.