In the previous installment of our series of IPv6 security posts, we covered some of the ways addressing has changed in IPv6 compared to IPv4. In this post, we’ll talk about some of the things to consider when securing IPv6 compared to IPv4. Before digging into this topic, however, it is important to remember that while IPv6 may have different security concerns than IPv4, it is not necessarily any more secure than IPv4. Furthermore, the post will focus on those aspects that are different or unique to IPv6, since many of the common best practices for IPv4 networks also apply to IPv6 networks.
A few years back I set up IPv6 connectivity on my home network for the first time. I had a rush of exhilaration when the first ping and traceroute commands completed successfully. Suddenly, I was free of Network Address Translation and bypassing my firewall, connecting directly to any IPv6 device on the Internet. But then it slowly dawned on me that those people same people could also directly connect to my device! In a panic, I wondered if my SMB shares were visible to the world, or if criminals could relentlessly probe my open ports for zero-day vulnerabilities. How could I even check if I had any open ports? My fear got the best of me and I disabled IPv6.
I contacted my friend Dan and posed my dilemma to him. How could I tell if my ports were locked down on a machine which ran IPv6? A number of sites provided port scanners for IPv4, but nobody had a general purpose scanner for IPv6. Hurricane Electric provided one, but only for devices that were on their network. Dan hacked up a primitive IPv6 open port testing site, which uses NMAP to scan an IPv6 visitor for typically vulnerable ports before issuing a simple report. I was pleased to discover that my computer did not answer on any of those commonly attacked ports.
In this process, I discovered that many modern operating systems with IPv6 enabled also come with a set of reasonable host firewall defaults which do not expose listening ports as much as I had expected based on my experience with IPv4. Many hosts with IPv6 enabled by default also come with some very sensible settings to prevent network-launched crimes of opportunity from malicious users.
IPv6 also provides a natural defense against classic portscanning attacks, where an attacker probes for commonly vulnerable ports of every IP address on a subnet. For densely packed IPv4 service provider networks with one IP address assigned per typical user, a few thousand probes across a known DSL or cable subnet can yield a rich collection of potential targets. Since the address space of IPv6 is so much larger and sparsely populated than IPv4, blind portscanning of subnets becomes impractical since a typical IPv6 subnet contains quintillions of addresses hosting a relatively small number of end devices.
Despite the sensible security posture of IPv6, a network based firewall provides additional protections by thwarting attacks at the network perimeter, analyzing connection context and allowing greater control of policy and analytics. An IPv6 Quick Start Guide for the Cisco ASA can be found in the World IPv6 Day – IPv6 Transition community at the Cisco Support Forums. Please visit this forum and ask questions. Overcome your fear of running IPv6 and start reaping the benefits of running IPv6 on your own network in time for World IPv6 Day.
From my home network, I can successfully ping or traceroute to some IPv6 hosts, but I cannot subsequently open a web page or use other applications with it. How can this be? Maximum Transmission Unit (MTU) gotchas…
There is a subtle difference between IPv4 and IPv6 fragmentation strategies. IPv4 routers fragment traffic in the network when needed and then the receiving host reassembles those fragments. This generally works well, but there are a number of potential issues. Because of these issues, the IETF developed means for higher layer protocols such as TCP to determine the smallest MTU on a path and send appropriately sized datagrams in order to avoid fragmentation. The IPv6 designers presumed the presence of this Path MTU Discovery so that in IPv6, fragmentation no longer happens in the network but only at the hosts -- and then only in special cases in that absolutely require it.
In the previous installment of our series of IPv6 posts, we covered some of the ways ICMP has changed in IPv6 compared to IPv4. In this post, we’ll talk about how addressing has changed in IPv6 compared to IPv4.
While IPv4 addresses are 32 bits log, the IPv6 address space has been extended to 128 bits, which will make it virtually impossible to remember the numeric representation of the address for a given host. This will definitely lead to more reliance on DNS. It will be difficult to operate even very simple test networks without relying on DNS to resolve host names to IPv6 addresses. Because of this, more attacks will be targeted against your DNS servers. Making sure your DNS configuration and servers are secure will be very more important in IPv6. DNS will also be targeted by attackers to attempt to locate systems on the network by trying to resolve “common host names,” since scanning a remote IPv6 network is essentially impossible due to the size of the IPv6 address space.
Most people already have IPv6 capability whether they know it or not. All Microsoft operating systems such as Windows Vista and all MacOS releases since 10.2 have IPv6 installed enabled by default. Mobile devices running Android 2.1, Apple iOS 4.0, and Symbian 7.0 are configured likewise as is nearly every *nix variant you can name. Even the venerable and ubiquitous Windows XP has a latent IPv6 stack which can be activated with a single command.
Typically, IPv6 enabled systems will prefer IPv6 connections over IPv4, so a misconfigured or malfunctioning IPv6 network will cause connectivity problems. Many popular troubleshooting regimens simply prescribe disabling IPv6 as the “solution,” which really does nothing more than to hide the underlying problem with the IPv6 network. When you have a network problem that is “solved” by disabling IPv6, you have masked the symptom of a bigger problem that warrants further investigation.