One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6
in some other posts – many
practitioners have been waiting for quite some time now, is full support of
RFC 6939 (Client Link-Layer Address
Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC
6939 support would allow a number of things which large organizations use in
their DHCPv4 based networks, incl.
reservations (assigning a kind-of fixed DHCP address based on the MAC address
of a system which in turn allows for “centralized administration of somewhat
static addresses”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC
address.
(some type) of security enforcement based on the MAC address of a host
gathered in the course of a DHCP exchange (see for example slide #29 of
this presentation of the IPv6 deployment at CERN,
btw: slide #9 might be helpful when discussing IPv6 transition plans with
your CIO. or not).
So far it seemed very few components support RFC 6939. When
Tim Martin mentioned at Cisco Live that Cisco
devices running IOS XE support it by default, we decided go to the lab ;-).
We’re using our smart phones every day to manage contacts, calendar entries,
e-mail, and social communication (please note that we at ERNW still have a
strict “no company data on smartphones/tablets” – which includes email).
Everything is easy to use and automated syncing provides access to our data from
anywhere. Data is stored in most cases on premises of a cloud service provided
by the OS vendor of your smart phone – mostly Google, Apple or Microsoft. You
don’t need to pay for this service – and the cloud provider could use your data
for personalization and service improvements.
We’re currently involved in a complex RfP procedure for global network services
of a large organization. As part of that we were asked to define a list of IPv6
related requirements as for the Internet uplink and MPLS circuit connections.
The involved service providers/carrier offerings will be checked to comply with
those.
As a source of inspiration we mainly used the excellent
“What To Ask From Your Service Provider About IPv6”
document from Cisco, and enhanced that with stuff we observed in other
environments (go wrong), namely with regard to MTU/PMTUD and in the
space of prefix filtering.
Here’s the first draft list we came up with:
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.