What are the security implications of having native IPv6 support on IPv4-only networks? What are the security implications of the automatic enabling of IPv6 transition mechanisms such as tunneling?
In a new Internet-Draft out this week, security researcher Fernando Gont of the UK’s Centre for the Protection of National Infrastructure seeks to explore those very questions:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets
As the abstract says:
This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on “IPv4-only” networks, and describes possible mitigations for the aforementioned issues.
and the introduction states in part:
Most general-purpose operating systems implement and enable by default native IPv6 support and a number of transition-co-existence technologies. In those cases in which such devices are deployed on networks that are assumed to be IPv4-only, the aforementioned technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes.
For example, a Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/co-existence technology is leveraged for that purpose. Additionally, an IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6. Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network. Thus, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure. That is, the aforementioned technologies might inadvertently allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall.
In general, the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled traffic. Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked.
Fernando Gont goes on to discuss the various threats and the ways to mitigate the threats on the edge of the IPv4-only network.
This is only the initial draft of this document and while it certainly may evolve through the IETF process, it is already a good start for IT security staff seeking to understand how to allow IPv6 on internal networks while preserving network security. Some of the advice to IT security teams out there on the Internet is just to “disable IPv6″… but the reality is that with World IPv6 Launch in June and the continuing IPv4 address depletion, turning off IPv6 is no longer a smart answer. Far better to look at documents like this and understand how to secure your infrastructure while enabling IPv6 experimentation and usage.
Kudos to Fernando Gont for putting this document together and we look forward to seeing it develop further. He is seeking comment so if you do have feedback on the document, his contact information is at the end.
This week Digium released three security advisories allowing remote authenticated sessions to either crash an Asterisk server or escalate user privileges. The advisories are:
Which should you use for a distributed version control system (DVCS) – git or mercurial? That was the question taken up recently by two opposing blog posts on Atlassian’s blog:
