today I’m going to suspend the “Developing an Enterprise IPv6 Security Strategy” series for a moment and discuss some other aspects of IPv6 deployment.
We’ve been involved in a number of IPv6 projects in large organizations in the past few years and in many of those there was a planning phase in which several documents were created (often these include a road map, an address concept/plan and a security concept).
Point is: at some point it’s getting real ;-), read: IPv6 is actually enabled on some systems. Pretty much all enterprise customers we know start(ed) their IPv6 deployment “at the perimeter”, enabling IPv6 (usually in dual-stack mode) on some systems/services facing the Internet and/or external parties.
Unfortunately there’s a number of (seemingly small) things that can go wrong in this phase and “little errors” made today are probably meant to stay for a long time (in German we have the nice phrase “Nichts ist so dauerhaft wie ein Provisorium”, and I’m sure people with an IT operations background will understand this even without a translator…).
In this post I will hence lay out some things to consider when you enable IPv6 on perimeter elements for the first time.
In the previous parts of this series (part 1, part 2, part 3, part 4) we covered several aspects of IPv6 security, mainly on the infrastructure level. In today’s post I will follow up by briefly discussing so-called First Hop Security features.
IPv6 First Hop Security (“IPv6 FHS”) is a collection of features (initially implemented, and named, by Cisco but available on other platforms too) that can be found on many access layer switches to prevent different attacks in IPv6 networks. The availability of those features is sometimes divided into three phases and started in 2010 with the release of IOS images containing mainly RA Guard (see below) and port-based IPv6 ACLs. Phase two was released in early 2012 and contained some more features (namely from the “IPv6 Snooping” framework) whereas phase three was released at the end of 2012 and contained some more advanced features (e.g. IPv6 Source Guard). Nowadays usually “phase one” features are supported on many platforms, at least on physical ones (support on virtual switches is still somewhat lacking).
There’s an excellent Cisco FHS Wiki maintained by Andrew Yourtchenko, Scott Hogg wrote a good overview, as did Ivan Pepelnjak, and this is a nice presentation on some elements by Jim Small from 2013. Still, from our perspective the main question is: which of those features should be deployed in production networks/can be observed in real-life enterprise networks. Actually it’s only two:
Rafael Schaefer: Advanced IPv6 Attacks Using Chiron. Hands-On Workshop
Outline: During the IPv6 Security Summit at Troopers 14, Chiron, an all-in-one IPv6 penetration testing framework was released publicly for first time. Since then, the advanced features of Chiron were used to discover some 0-day evasion techniques against high-end commercial and open-source Intrusion Detection / Prevention Systems. Moreover, for Troopers 15 it was enhanced with new features, like advanced MLD support and a fake DHCPv6 server, which can be combined with its other features, like the use of arbitrary Extension Headers and fragmentation to leverage really advanced attacks.
In this workshop, after a quick refreshing to the basic capabilities of Chiron, we will focus on the advanced IPv6 functionalities that the framework offers. We will not only show how to reproduce the latest published IPv6 attacks, but moreover, how you can create your own arbitrary IPv6 attacking scenarios for your own security assessments or penetration testing purposes. A lab will be set up in order not only to reproduce the presented techniques, but to also try your skills and – why not – to discover your own 0-day techniques :).
In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.
As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.
So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.
In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).
We’ve been involved in some activities in this space recently and I thought it could be a good idea to share a couple of things we’ve discussed & displayed. Furthermore some time ago – in the Is IPv6 more Secure than IPv4? Or Less? post – I announced to come up with (something like) an “IPv6 threats & controls catalogue” at some point… so here we go: in an upcoming series of a few blogposts I will lay out some typical elements of an “Enterprise IPv6 Security Strategy” incl. several technical pieces (and I plan to give a talk on the exact topic at next year’s IPv6 Security Summit).
Some readers will probably be aware that we are amongst the proponents of a quite strict stance when it comes to filtering IPv6 packets with (certain) Extension Headers and/or fragmentation, because those can be the source of many security problems (as laid out here, here or here). Actually I still think it was a very good idea of, amongst others, Randy Bush and Ron Bonica to suggest the deprecation of IPv6 fragmentation in the IETF.
On the other hand there are voices arguing that fragmented IPv6 packets will be needed in some cases, namely DNS[SEC]-related ones.
In this post I will discuss some details of this debate (taking place in many circles, incl. this thread on the ipv6-hackers mailing list which, btw, you should subscribe to).
Last week Christopher and I were the instructors of an IPv6 workshop. In this one we usually build a lab with the participants incl. a variety of routed segments and native IPv6 Internet access. Once the latter part is implemented people start poking around and surfing the Internet from their laptops, not least to find out which sites they can actually reach from an v6-only network (please note that actually there are many).
On Saturday last week I had the pleasure of delivering a workshop on IPv6 networking at the MRMCD2015 conference in Darmstadt, Germany. It goes without saying that the atmosphere was quite amicable; as usual at CCC-related events. What definitely impressed me the most was the diversity of the audience. There were around thirty attendees representing several age groups and all with seemingly differing backgrounds.
The engagement of everyone was stunning. I questioned the most engaged attendees relentlessly and they fired back. I was being constantly bombarded with questions from enthusiastic geeks and they got, hopefully, what they deserved. This provided for a great learning environment, a friendly atmosphere and in my humble opinion really constructive dialogues. Well, one has to be interested and enthusiastic in order to spend three hours on a rainy Saturday evening discussing IPv6.