During our blogpost regarding
DHCPv6 Guard evasion,
one of the side-effects was that Access Control Lists (ACLs) configured to block
access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers.
Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs
under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco
routers can be evaded, as well as under which conditions this can take place. To
this end, several representative scenarios from enterprise environments or other
potential ones are examined.
I’ve discussed the heavy complexity of IPv6 and its negative impact on security
architectures relying on state – you know, “stateful” firewalls and the like
😉 – before
(here
and
here.
btw, the widely discussed
IPv6-related network outage
at MIT last year was a state problem as well: switches keeping
track of multicast groups, of which in turn many existed due privacy extensions
combined with the
unfortunate relationship of MLD and ND).
One of the conclusions I’ve drawn in the past was recommending to minimize the
amount of state one might use within security architectures in the IPv6 world.
First, this is bad news for quite some well-established security controls that
need a certain amount of state to work properly, like IDPS systems – which
subsequently
have hard times to work properly
in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco
Live Europe, in Andrew Yourtchenko‘s excellent
breakout session on “Advanced IPv6 Security in the Core”, this carries some
consequences for stateless (and hence: seemingly “unaffected”) security
controls, too.
Given that Enno and I are network geeks, and that I am responsible for setting
up the Troopers Wifi network I was curious
which components might be used at Cisco Live and which IPv6 related
configuration was done for the Wifi network to ensure a reliable network and
reduce the chatty nature of IPv6. Andrew Yourtchenko
(@ayourtch) already did an amazing job last year
at Cisco Live Europe explaining in detail (at the time
session BRKEWN-2666) the
intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these
networks. He was also a great inspiration for me when setting up the
Troopers Wifi network
a couple of weeks later. Thank You!
We’ve finalized the agenda for this year’s IPv6 Security Summit. Here’s an
overview of the event:
The “IPv6 Security Summit” is a special two-day convention in the context of the
Troopers security conference. It will be
run in two tracks of both half-day workshops and 90 minute presentations on
specific topics. The goal is to foster the discussion of IPv6 security aspects &
issues and to provide practical advice for security officers, network planners
and practitioners in the IPv6 security field.
We’re sometimes approached with the question “Which IPv6 mailing lists do you
guys read/subscribe to?” – here’s a quick overview of the main ones guys like
Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at,
to discuss IPv6 (network|security) related stuff with other practitioners and
to learn from them:
during our BlackHat US 2014 talk titled
“Evasion of High-End IPS Devices in the Age of IPv6”,
among others we discussed a Snort preprocessor rule (116:456) which, when
enabled (not the case by default), triggers an alert when an IPv6 datagram with
nine (9) or more IPv6 Extension Headers is used (such a header was used by us to
evade Snort). However, we mentioned that:
RA Guard Evasion is well-known in the IPv6 “circles”; there is
RFC 7113 Advice for IPv6 Router
Advertisement Guard (RA-Guard) and many interesting blog-posts like this
one here,
here,
and this excellent write-up
here that discuss
this issue.
Moreover, as Jim Smalls states in his comprehensive
“IPv6 Attacks and Countermeasures”
presentation given at the
North American IPv6 Summit 2013,
DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but
(only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at
that time there wasn’t any known attack tool in the wild that had the
fragmentation evasion built in.
Most of you are probably aware of the recently discovered/-closed severe ntpd
vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see
also
the initial ntp.org security notice).
Some days ago the Project Zero team at Google published a blog post
“Finding and exploiting ntpd vulnerabilities”
with additional details. In this one they mentioned a seemingly minor but quite
important detail: on a default OS X installation one of the built-in protection
mechanisms of ntpd (that is the restriction to process certain packets only if
they are sourced on the local machine) can easily be circumvented by sending
IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1
in IPv4 which would be discarded by the kernel once received from an external
source).
After we recently released the
“Linux IPv6 Hardening Guide”
we got a number of suggestions “could you pls provide a similar document for
$OS?” (btw: thanks to you all for the overwhelming interest in the Linux
document and the active discussion of ip6tables rule approaches on the
ipv6hackers mailing list).
Hence Antonios thankfully decided to put together a list of configuration steps
for Windows servers. It
can be found here.
Once more we’d like to emphasize that the approach described is only suited for
very specific environments with high security requirements and an associated
ratio of “generous operational resources”. From our perspective this guide is
intended mostly to serve as a source of inspiration (“what could be done”) and
for documentation purposes (“how to do it”). Everything described should be
carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an
organization where the Windows guys (completely legitimately) came up with a
stance of “before we fully accept and ratify the strategy and policy just
discussed, we’d like to get feedback from Microsoft, if we still have full
support once we follow this path”.
We were recently approached by a customer asking us for support along the lines
of “do you have any recommendations as for strict hardening of IPv6 parameters
on Linux systems?”. It turned out that the systems in question process quite
sensitive data and are located in certain, not too big network segments with
very high security requirements.
They indicated they were willing to spend significant operational resources on
“securely configuring them”. So Antonios deciced to write a small hardening
guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much
everything (including neighbor cache entries 😉 with accompanying deactivation
of all automatic mechanisms, together with ip6tables based local packet
filtering.
The document
can be found here.