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:
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).
The current trend of social coding finally arrived at ERNW! From now on, you
will find our public released tools and scripts commonly
on https://github.com/ernw. Therefore I would like to
share some thoughts/guidelines which you have to keep in mind if you want to be
a social coder:
Github and other repository hosts are great if you want to share opensource
tools with the community, as they will find a common platform with defined
workflows to extend/fix the work to get better software for everyone. What some
should note is that (especially in terms of decentralized version control
systems (DVCSs) like git, bazaar or mercurial) public really means public. Back
in earlier days, if you shared your code with others you probably created a
source code package of a defined version of your code. They will get the files
you published, nothing more (and nothing less). Beginning with websites like
sourceforge, a broader range of public VCSs came up (mostly driven by CVS or
SVN). At this time, others were able to view your commit history (if you granted
access to them) and all your mistakes you’ve done before your published code
state (for example accidentally committed sensitive data). Those mistakes can
still happen today. The difference with the DVCS used nowadays is that most of
the time you have lesser control of your commit history (in the same way if
someone had copied your history commit by commit in SVN, but then you may had
noticed it because of the high network traffic). With DVCS, everyone gets a full
copy (clone) of your repository even on a simple “checkout” (as called in SVN).
This means he/she is able to search your history locally and has all the time
he/she needs to do it. Even if you delete your repository (or modify the
history), the original state is shared over all who have cloned it beforehand
(thats one reason why DMCA takedowns are not that powerful/useful against git
repositories). Most of the public hosting platforms even included a search over
all repositories (which is really useful if you want to find some tool or try to
find the reason why a local tool doesn’t work).
today we want to share a method on how to test an OCSP over HTTP validation
service with Burp and some Python magic. First a little background about OCSP
(Online Certificate Status Protocol): the main purpose of OCSP is to validate
the status of an X.509 certificate.
The OCSP responder is the key part of the system. It is run by the certificate
authority and responds with one of three possible different answers. The first
one is “good”, which indicates that the certificate is not banned, “revoked”
means that the certificate is banned, and “unknown” simply says that the status
could not be determined, because the issuing CA of the Cert is not known to the
responder.
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).
Python has reached a defacto standard in exploit development lifecycles and most
of the proof of concept tools you’ll find out there are written in Python
(besides the metasploit framework, which is written in Ruby). Python allows to
write scripts handling with remote services, fiddling with binary data and
interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a
fast and easy way. The huge standard library with it’s “battery included”
principle removes some of the dependency hell known from other
frameworks/languages. I want to share some of my python coding experiences with
you, and maybe this could give some helpful tips for your future work, to make
the world a bit safer 🙂 (PS: most of the examples are written in Python 3.x or
compatible to both Python branches).