IPv6 insecurities on “IPv4-only” networks

When people hear about IPv6-specific security issues, they frequently tend to rate this as an argument in favour of delaying or avoiding IPv6 deployment on their enterprise or campus network. Even without IPv6 being consciously deployed, however, some of the IPv6-related security issues were already introduced to most networks many years ago. The reason for this is simple: IPv6 is implemented in all common operating systems and enabled by default. We introduced hosts with these operating systems on our networks several years ago – be they clients on the office network or servers in a data centre or DMZ.

Since most, if not all, of today’s company networks are IPv6-enabled to a certain degree, they are attackable over IPv6. To make things worse, in contrast to IPv4, IPv6 brings along different kinds of autoconfiguration functionality, which can be misused. Network operators and security people who have neither basic IPv6 experience nor measures in place to detect IPv6-related attacks run a risk, and this risk is permanently increasing as the bad guys have already started to use IPv6. Bad guys are usually early adopters.

Let us look at some possible scenarios:

1. Rogue IPv6 router attracts traffic

In this scenario, the attacker has access to a local network segment. He is either an insider or has otherwise gained physical access to the network. Maybe he managed to compromise and take over one system on the network segment. He can now send periodic IPv6 Router Advertisements (ICMPv6 Type 134 messages) to the local network. All nodes on the network that have IPv6 Stateless Address Autoconfiguration (SLAAC) enabled – which is the default – will consequently configure global routable IPv6 addresses and a default IPv6 route to the attacker’s node. As a result, all former IPv4-only nodes on the network are now dual-stack nodes and have native IPv6 connectivity, with the attacker serving as the next hop.

2. Attacker bypasses IP based access control

Here the attacker wants to access a resource (in this case a database server) protected by IP-based access control (IPv4 ACLs). He again sends Router Advertisements in order to configure IPv6 addresses on the desired machine. He might then be able to access the system via IPv6 because this “second door” is not protected by ACLs. This example applies to all devices protected by IP-based ACLs with only weak alternative access protection or none at all “because nobody can access it anyway”.

3. Client bypasses firewall with IPv6 tunnel

In the third scenario, we have a user on the local network whose network knowledge is up to date. He wants to access a resource that is blocked according to the local firewall policy. Since this resource is available over IPv6 as well, he tells his web browser to use IPv6. The client node does not have native IPv6 connectivity, so it tries one of its IPv6 tunnel mechanisms that are enabled and can configure automatically. Given that the local firewall does not filter IPv6 traffic that has been tunnelled over IPv4 to an exterior tunnel gateway, this user can access the otherwise blocked resource.

Food for thought

These are just three examples that show how IPv6 can affect your network security, even though you have never consciously deployed IPv6. There are a number of others. The following questions may help you to assess whether your network security is at risk:

• Do you see IPv6 traffic on your network? (Monitoring)
• Are you sure your firewalls filter (tunnelled) IPv6 traffic?
• Do you have enough knowledge about IPv6 and its specific attacks to detect them?
• Do you rely on IP-based ACLs – which are ineffective for IPv6?

If you did not answer “yes” to the first three questions and “no” to the last one, then it seems you have a new item to add to your “to do” list.