Risk
4/3/2012
09:02 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Monitoring, Policies Needed To Catch Rogue IPv6 Traffic

With a growing number of devices supporting the next-generation network protocol, companies need to research and implement IPv6 security

The spotty support of the next-generation Internet routing protocol, IPv6, has left companies with a network security problem that has largely passed unnoticed. While IPv6 is built into many endpoint devices and supported by a majority of networking hardware, enterprise-routing and security features are typically lacking.

The result is that IPv6 traffic is traversing most companies' networks undetected, creating a "shadow network" where traffic flies under the radar of security devices. In most cases, the traffic does not pass beyond the edge of the company network, but experts warn that the lack of awareness by most corporate IT groups could leave networks vulnerable. In March, for example, Insecure.org released the latest version of the popular Nmap network-scanning program demonstrating the ability to peer into a network and through the firewall, just by using IPv6 networking protocols.

"IPv6 tunnels and auto-configuration can introduce serious risks by enabling end-to-end connectivity where the administrators never intended it," says Gordon Lyon, better known as Fyodor, the lead developer of the Nmap program. "Admins may think their IPv4 firewall and IDS (intrusion detection systems) are protecting them, while IPv6 traffic slips in under the radar."

Welcome to the No Man's Land of networking, where the uneven support for IPv6 leaves some hosts trying to communicate in a language that other devices don't even recognize. While IPv6 promises an astronomical increase in address space and some advanced routing functionality, the protocol has faced major adoption hurdles. The exhaustion of the IPv4 address space has convinced service providers and large enterprises to start the painful migration process. Many online firms will permanently stand up their IPv6 services on World IPv6 Launch Day on June 6.

Yet, the argument to implement IPv6 inside a company network is less than compelling.

"Globally, we are going to have to move towards it," says Jeremy Duncan, IPv6 architect for government IT contractor Salient Federal Solutions. "The problem is that there is so much pushback, people just want to bury their heads in the sand."

Look at Google's experience. A few engineers embarked on a IPv6 migration project more than four years ago -- a side project that gained increasingly support. It's been four years, but the engineers are now only halfway through the process, the team reported in a paper at December's USENIX Large Installation and System Administration conference. Problems encountered by the group included a lack of support for IPv6 among providers, immature support among operating systems, and a myriad of application problems.

The security problems posed by IPv6 have their roots in the confusion created by the chaotic implementations. While IPv6 itself poses no inherent security threat, companies' lack of attention to the protocol and the devices in their network that communicate in IPv6 can make it a perfect convert channel. Unless companies are searching for IPv6 packets with monitoring appliances designed to inspect the data, traffic can be easy to miss.

The reasons IPv6 communications can inadvertently be created inside a network are varied. Modern Windows and Mac OS X systems can generate and respond to requests as well as bury IPv6 traffic in IPv4 packets, a process known as tunneling. Employees who want to use peer-to-peer file sharing clients, for example, could use tunneling to get around firewall blocks and rate limiting that could slow down transfer speeds. And, if a company's firewalls and intrusion detection systems do not process IPv6, attackers can use the protocol to map a target network, execute a denial-of-service attack, or exfiltrate data from a network.

"Tunneling through IPv6 is a very advanced tactic that most malware authors have not had to use yet, because there are easier methods at their disposal," says Ben Greenberg, senior security threat researcher at Fidelis Security Systems. "But that hole is still there, and even though it is not being used very much right now, it is still there. When the enterprises patch up the lower hanging fruit, the attackers are going to move to this one."

For companies, the first step to locking down their network is be aware of what devices have the protocol enabled, he says. If the firms are running Windows Vista, Windows 7, Windows Server 2008, Mac OS X and any number of flavors of Linux in a default configuration, the software is likely to be sending IPv6 packets. Awareness is the best defense, says Greenberg.

"So the first question they should ask is, 'Do I need it?' And, if they don't need it, the safest thing to do it to just disable it," he says. "And if they do need it, then it should be controlled. And if they do need it and they control it, they should make sure that their security appliances have the ability to peer into the packets."

Next, companies should tackle policies. Based on the decision to migrate to IPv6 or continue using IPv4, a company's CIO can translate or modify existing policy to take IPv6 traffic into account, says Qing Li, chief scientist at Blue Coat Systems, a network security and optimization firm.

While the technologies are different -- and IPv6 exacerbates some security issues -- the way to solve the problems are similar.

"A lot of the solutions are very generic -- they are, by definition, IT-layer agnostic," says Li. "It doesn't matter whether its IPv4 or IPv6, a lot of the security problems are the same."

Blocking tunneling protocols, inspecting IPv6 packets and making sure that communications comply with any required regulations can all go a long way to securing a company's network and data, he says.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web