Originating from a customer IPv6 deployment project, in early 2014 we defined a
number of requirements as for the IPv6 capabilities of IPAM solutions, with a
certain focus on security-related requirements (due to the specific environment
of the project). We subsequently performed a practical evaluation of several
commercial solutions, based on documentation, lab implementation and vendor
communication.
We just released
a newsletter describing the requirements and the results of the evaluation.
It
should be noted that in the interim newer versions of the evaluated products
might be available which might have enhanced features. Hence, from our
perspective, understanding the requirements of an individual environment might
even be more important than the actual results described in that document (as
those only reflect a certain point of time). We hope to contribute here to a
well-informed requirements definition and decision taking process on your
side.
Feel free to get back to us on any of the points laid out or, even better, join
us at the Troopers
IPv6 Security Summit
in Heidelberg on Mar 16th/17th in order to discuss any related points.
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!
Quite some organizations complemented their traditional AV solutions with a
technology that can best be described as behavior-based malware detection. While
we all know we are talking about products like Fireeye Email/Network Security,
zScaler Web Security/APT Protection, or Cisco WSA, there are a lot of terms
around to describe this type of products (such as next generation malware
analysis/detection, Secure Web Gateways, or behavior-based malware detection).
Those offerings typically promise the detection of malware by analyzing the
behavior of ‘samples’ (which are files captured in transit of different types,
such as executables or PDF documents). However, beyond the taxonomy challenges,
both assessment and consulting work gets us frequently in contact with those
solutions. While the main task during assessments is to bypass those solutions,
the main question in the consulting context typically is “to what degree are the
solutions suited to protect from common targeted attacks in the enterprise
context”. Luckily, the experience from assessment work allows us to tackle this
question in a structured way (which is our approach for consulting anyways:
Benefit from our assessment experiences in order to provide reasonable
consulting advice…).
Simple everyday work dialog:
“The heater in the basement is still missing a proper thermostat, the ‘binary
solution’ isn’t that effective”
– “Buy one…”
– “Ok”
– “Get one you can break…”
– “Ok, but then I’d like a few tools, too”
– “Go for it.”
(That’s the way work should be!)
Result of the dialog: a
Danfoss Living Connect Z ( 014G0013 )
and a
TI CC1100 Wireless Mini Dev Kit plus
a copy of Z-Force to start with. Goal: Talk to the thermostat!
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 first year of testing Windows Phone 8 applications we had yet
another, let’s say: “surprising” finding. It all started with the first
approaches on pentesting mobile applications on that new and rather closed
platform. Lacking jailbreak, root, and similar approaches we had a closer look
at alternate approaches to have a look at an apps interior. We quickly hooked
onto using modified firmwares (with deeper system access) and found a perfect
solution in a little flaw concerning the handling of SD cards in WP8.1. A flaw
that was, sadly for us, fixed silently….
Just recently, Dell SecureWorks Counter Threat Unit(TM) (CTU) researchers
published details (see
http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/
) on a especially nasty piece of malware that bypasses authentication on Active
Directory (AD) systems which implement single-factor (password only)
authentication. Once deployed the malware stays quite noiseless in the Domain
Controller´s (DC) RAM, and the DC´s replication issues caused by it weren´t
interpreted – in this case – during months as a hint for system compromise.
Probably the malware´s modification on the LSASS process reduced the DC´s
ability to perform DC-to-DC authentication, but this is only speculation and not
where we would like to go today.