Q&A: Things to consider when it comes to IPv6 and securityby Steve Ragan - May 20 2011, 12:00
The Tech Herald recently spoke to Asaf Greiner, the VP of products at Commtouch, for a quick overview of the basic security challenges that IT administrators will face when it comes to IPv6 adoption.
Commtouch, plainly stated, is a vendor’s vendor. Their technology and R&D can be found embedded in products from a large base of businesses, including 1&1, Check Point, F-Secure, Google (Postini), GFI, McAfee, Panda, WatchGuard, Webroot, and others.
You might know their name because they were the first to market with reputation-based protection for Spam filtering, and their ability to identify new Malware attacks within minutes.
Last month, as an example of detection, Commtouch was the only security company to detect ZeroDay attacks on Flash Player vulnerabilities via files embedded within email attachments. [Adobe Advisory] [Original Virus Total Report]
An overview of their products can be seen here. Just remember, you may already be using their technology. It depends on the security products you have in-house.
The Tech Herald (TTH): What are the top five security problems that IPv6 has the potential to create?
Asaf Greiner (AG): Since this is new (and complex) technology, there are bound to be incorrect configurations of network devices and endpoints that will open vulnerabilities.
- Current security solutions will not protect some IPv6 vectors and organizations will be exposed to IPv6 threats even before they start “officially” using them, since their network devices might already support IPv6 but without the correct configurations for protection.
- Tunneling of IPv6 will result in some of the communications being hidden from traditional protection systems.
The introduction of almost unlimited numbers of IP addresses will create several security problems. In an IPv4 environment a rogue computer can almost certainly be associated with a single IP address due to the limited number of addresses available. The same rogue computer operating in an IPv6 Internet though, may have access to a wide range of IP addresses.
An attack could be launched from many of these addresses making it difficult for security solutions to “pin down” the source of the attack. Security solutions that rely on the blocking of rogue commuters based on IP address will face the biggest challenges leading to security problems in the following areas:
- IP reputation-based spam blocking
- Email header-based spam blocking using IP address
- URL filtering based on domain IP address
- Denial of service prevention based on attacker IP address
TTH: What can administrators do to address these problems?
AG: We believe administrators should open up their IPv6 networks gradually.
The first stage would involve blocking the network from all IPv6 traffic going in or out. Then, gradually opening those parts of the network that the organization needs – all the while making sure that there is a clear understanding of those specific parts that are opened.
This is a good opportunity to “get it right” from the start. Administrators will also need to consider the threats outlined above and put systems in place (or upgrade current systems) that properly address these issues.
Administrators can also do their part in making the IPv6 world safer by considering carefully the range of addresses that they make available to end users. Too large a range will likely be unnecessary for most users and will make abuse easier.
TTH: What should administrators consider when deploying IPv6? What are some of the best practices you recommend?
AG: Administrators should take the time to develop in-depth understanding about IPv6 prior to implementing. There are many subtle differences between IPv4 and the two next steps (I) dual stack (II) IPv6 only. These need to be mastered to the same level that IPv4 was.
TTH: How will reputation-based defenses be hurt by the flood of available space on IPv6?
AG: As described above, the wide range of available addresses will make it difficult to assign a reputation to any one IP address.
A knock-on effect here will be the database size required to store lists of low-reputation addresses. Ideally IP reputation systems need to be able to store address ranges (as opposed to long lists of individual addressees) and also need to be able to intelligently assess how wide a range to block. Too wide a range will result in the blocking of “innocent” addresses.
To further save on storage space, IP reputation systems need to dynamically customize themselves to store locally relevant addresses only i.e.: only addresses that actually reach the protected network. Continually downloading and managing a complete IPv6 list is not going to be possible for a network protection endpoint.
Cloud-based solutions become more important since they can centrally store the complete huge list while making manageable portions available for protection endpoints.
TTH: What are your predictions for dual stack networks, and how do you think criminals will leverage this to target organizations and users?
AG: Dual-stack networks are likely to be used for a long time. We expect that major threats might initially emerge in situations where the organization/user isn’t aware that there is a functional dual stack (such as in Windows) resulting in abuse that simply bypasses existing security configurations.
TTH: What are some of the things Commtouch is doing to strengthen defenses as IPv6 is deployed?
AG: Commtouch is in the process of releasing new versions of all software clients to enable support of IPv6 protection.
In addition we are working to ensure that our cloud-based GlobalView Network infrastructure is IPv6 capable. This includes the obvious network and routing issues as well as ensuring that our spam, URL, and IP tracking databases can all store addresses and address ranges in IPv6 formats.
On an application level we are working to ensure that we can intelligently predict and block ranges of IPv6 addresses that are abused. IPv6 assignment strategies are still in early stages and far from being formalized. No real standard exists and the recent RFC 6177 actually moved away from previously defined recommendations.
To address this evolving situation we have designed both our client and backend cloud to be able to efficiently represent any network prefix (e.g. /56; /128). We are performing ongoing IPv6 traffic tracking and analysis, in order to observe and analyze the adopted IPv6 usage patterns and allocation schemes.