Some years ago I discussed the meaning of the term “control” in
this post,
but at the time I was mainly referring to the noun “control”. Given I’ll
extensively use the term “control” as a verb in the next parts of “the
DMZseries”
and some upcomingtalks I reflected a bit on its meaning
(as a verb). In the following I’ll lay out the definition/understanding to be
employed at those occasions.
This is the second part of a series with considerations on DMZ networks in 2016
(part 1 can be found
here).
Beforehand I had planned to cover classification & segmentation approaches in
this one, but after my little rant on how “the business” might approach & think
about reverse proxies in the first part, I felt tempted to elaborate a bit
further on this particular topic. I kindly ask for your patience 😉 and will
digress a bit for the moment.
I’m currently involved in a “DMZ Redesign” effort in a sufficiently large
enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity
to reflect on some aspects of “DMZ networks” in a series of posts.
Some of you already know that, at ERNW, we have a
tendency to discuss stuff starting with some formal definitions and a bit of
abstract (overview) approach. It’s not different this time ;-), so let’s first
find out what the term “DMZ” means, what such a thing is considered to be and to
deliver, and what the actual state of affairs might be in 2016. Different people
within an organization might have quite different understandings in this
space.
Further it’s entirely possible that the DMZ networks are not operated by
a company themselves but by an outsourcing partner which then means that
“placing a system in the DMZ” becomes “ordering a DMZ [network] port” by means
of some web-based procedure or ticket system, which in turn might have a number
of interesting implications (we’ll have a dedicated post on those).
After seeing
Christopher’s post I
decided to create a proof using GNS3 and Virtualbox.
The aim is to perform the exact attacking using Antonios Atlasis’
Chiron tools and run a Wireshark packet
capture to prove the hop limit drops below 255.
The following topology is used in GNS3:
The
routers used are Cisco C372 and the machine labled Ubuntu is running 14.04 LTS
Ubuntu Desktop, default installation. F0/0 is on the right and F0/1 is on the
left.
I won’t be in Vegas for Black Hat this year as there’s a direct conflict with
one of my kids’ birthdays, but I thought one or another reader might find it
helpful to get some inspiration as for selecting the talks to catch (not least
as there’s so many interesting ones). I hence decided to quickly write this
post.
Here’s my would-be schedule for the first day (second day to follow, maybe, in
another post), under the assumption to attend exactly one talk per slot. I could
give a longer rationale per talk than the one below, based on several (mostly
technical) factors, but this is just about providing suggestions in a brief
form.
Disclaimer: I was on the
BH guest review board this year so
I might be biased in some cases.
Tomorrow, I will join a meeting where I’m expected to contribute, amongst
others, to a discussion on the impact of IPv6 on threat intelligence. To prepare
for that I started putting together some thoughts & ideas on the topic, and I
even thought I might share this in a post (the one you read right now ;-), not
least to, maybe, stimulate a discussion.
I don’t know much about threat intelligence so it might happen that, at times, I
use some misguided terms or I expose a (too) naïve understanding of some
concepts. Happy to be corrected in one way or another.
In November 2014, after quite some controversy in the IETF OPSEC working group
(for those interested look at the
archives),
the InformationalRFC 7404 “Using
Only Link-Local Addressing inside an IPv6 Network” was published. It is authored
by Michael Behringer and
Eric Vyncke and discusses the advantages
& disadvantages of an approach using “only link-local addresses on
infrastructure links between routers”.
So it’s (merely) about “infrastructure links” which some people call “transit
networks” or “point to point” (ptp) links. I’m aware that there might be subtle
differences between all these, depending on your specific use of the terms.
Still I assume that most readers will have an understanding of what types of
links are in focus of the RFC, and subsequently of this post.
Right now, I’m in Buenos Aires for IETF95 where, amongst others, an
Internet-Draft authored by
Eric Vyncke,
Antonios Atlasis and myself will be presented
(and hopefully discussed) in two working groups. In the following I want to
quickly lay out why we think this is an important contribution.
As some of you may remember about two years ago we started an internal research
project on the IPv6 “helper procotol” Multicast Listener Discovery (MLD) and
its security properties. One outcome of this research project was
Jayson Salazar‘s excellent thesis on the topic
(the full document
can be found here),
another outcome were the related talks we gave at DeepSec 2014 and at
Troopers15.
I had the pleasure to sit in Mark Townsley
“Addressing Networking Challenges With Latest Innovations in IPv6”
session at Cisco Live yesterday and – somewhat inevitably – there was a mention
of Facebook having implemented an IPv6-only approach in their data centers
(here’s a talk from Paul Saab/FB
laying out details). So, with the
“IPv6 Panel” looming,
I started reflecting on “Why don’t we see this in our customer space?”. This
post quickly summarizes some observations and thoughts.
I’ll be on the
“IPv6 Panel”
at Cisco Live next week and somewhat in
preparation I started thinking about what we currently see when it comes to IPv6
deployment in our customer space. We notably observe a large gap between
“textbook planning & transition strategies” and what’s happening in real-life in
those organizations. I hence decided to write down some of these observations in
a quick series of posts to be published in the upcoming days and, maybe more
importantly, to reflect on the reasoning of this apparent mismatch between
theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.