In this part of the series (for the other parts see
[1],
[2],
[3],
[4],
[5]) we’ll
discuss approaches to implement security measures suited to protect from
IPv6-related threats on the host level.
These can be grouped into the following generic categories each of which will be
described in more detail in the following:
“Minimal machine” approach
Static configuration of IPv6 parameters
Tweaking the behavior of IPv6-related mechanisms/protocols
Local packet filtering
Some of you might recall that we published IPv6 hardening guides for both
Linux
and
Windows a
while ago and we’ll reference those exact documents below, by [Hard_Linux]
and [Hard_Windows] respectively.
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).