Before his infosec career Graeme was a street performer, then security
researcher, now he calls himself a defender. The talk was built around the
following sentence: “The infosec industry and community have completely failed
to create meaningful change in the behavior of people”.
The following example is a resume of how hacking worked from 1988 to 2017:
Following my work with the
FreeBSD implementation of RFC 6980
I was happy to present my work at last week’s DENOG 9 meeting.
To make it available to anyone who did not meet me there and go into some more
detail that would have exceeded the boundaries of the talk, I will cover the
topic here.
After the preceding work on
Windows Server 2016
and the FreeBSD testing, as a Linux user, lover and administrator, I of course
wanted to take a look at how different Linux systems complied with the RFC 6980
standard.
Looking at IPv6 deployment graphs like
this one it
becomes clear that IPv6 still is not widely deployed in enterprise space (the
reason for the apparent oscillation in that curve is the difference between
working days – where people use their office computers – and weekend where they
preferably use their smartphones or their home equipment connected by means of
broadband networks).
There’s a number of good reasons for this (in a nutshell: the overall IPv6
architecture is oriented around, and benefits, the decoupling of mostly
autonomous, self-organized endpoints from a well-managed/provider-managed
network infrastructure which isn’t exactly the operations model many large
enterprise organizations have in mind for their networks. also you might have a
look at
these slides
from RIPE74 to understand some of the reluctance to deploy IPv6 in certain
companies).
A while ago I wrote a short paper laying out options for an enterprise
organization to get global IPv6 address space from the RIPE NCC, discussing the
advantages and disadvantages of different approaches. As I think the topic may
be of interest for others, too, I’ve distilled an anonymized version. It can be
found here. I hope
some of you find it useful.
Last week I had the pleasure to participate at the
first RIPE IoT Roundtable Meeting
in Leeds (thanks! to
Marco Hogewoning
for organising it). It was a day with many fruitful discussions. I particularly
enjoyed Robert Kisteleki‘s talk on RIPE NCC’s own
design & (security) process considerations in the context of
RIPE Atlas (at TR17 NGI there was an
intro to Atlas,
too).
In this post I’d like to quickly lay out the main points of my own contribution
on “Balanced Security for IPv6 CPE Revisited” (the slides can be found
here).
As you may remember, back in 2014 we published
a whitepaper (compiled
by Antonis Atlasis) on the support of
IPv6 in different pentesting tools. This is almost three years ago and we
thought it is time for an update. In short not much has changed. Most of the
tools which didn’t support IPv6 are still not supporting it or haven’t got any
update since then.
This post will cover the tools where we could identify some progress on
supporting IPv6.
As you may know, we published a
whitepaper
discussing the behavior of different operating systems once they receive IPv6
configuration parameters from different sources two years ago. At that time, the
results were quite a mess. We were curious whether the situation is still so
“dire” like two years ago. We fired up the lab, updated the tested operating
systems and performed the tests again.
To summarize, at least in scenarios were only one router is involved, the
results look way more consistent (even cross operating system) then two years
ago. So we made progress on this front. Unfortunately, as soon as a second
router is introduced into the segment it gets messy and the operating systems do
show inconsistent behavior.
Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a
virtualized data center) with a customer. I’d like to take this as an
opportunity to lay out potential approaches for local packet filtering of IPv6,
which in turn might somewhat depend on the address configuration strategy chosen
for the respective systems (for the latter you may refer to
this post
or
to this talk
from the Troopers NGI event).
Some of this has already been discussed in
RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
but that document is from 2007 and things may have changed in the interim.
Let’s start with a quick look at the traffic which might be of interest. We will
take a server perspective here, read: which types of IPv6 traffic might have to
be accepted by a host/NIC firewall in order to support proper operations? I will
discuss the following, with a focus on the implications of filtering them
locally:
A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M”
version 15.2(2)E4 connecting
A Linux based attacker system running Chiron and
A FreeBSD target system, running different OS versions and configurations and
A Linux based laptop running a control script that remotely performed the
necessary tasks on the two machines mentioned above
The main question was: Would the impact on the target system and the possible
attacks that were observed with the Windows Server 2016 victim be reproducible
on other operating systems? Or would those behave totally differently?
I’m on my way back from the
RIPE74 meeting in Budapest. It was a great event:
quite a few nice technical talks in the plenary, productive working group
meetings and some really good hallway discussions.
Big thanks to the RIPE NCC team for the smooth organization and for taking care
of us!
Here’s some stuff I found particularly interesting:
Andrew Alston’s take on “Anti-Shutdown
Policies” (slides
and video incl. extensive mic
discussion)