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).
You may remember
our last post regarding
the SGOS system and the proprietary file system. Since then, we got access to a
newer version of the system (6.6.4.2). Still not the most current one (which
seems to be 6.7.1.1) nor of the 6.6.x branch (which seems to be 6.6.5.1) though.
As this system version also used the same proprietary filesystem (although it
initially booted from a FAT32 partition), I decided to take a deeper look into
this.
This blogpost will be about my first steps with coreboot and libreboot and a
life with as few proprietary firmware blobs as possible. My main motivation were
the latest headlines about fancy firmware things like Intel ME, Computrace and
UEFI backdoors. This post is not intended to be about a as much as possible
hardened system or about coreboot/libreboot being more secure, but rather to be
able to look into every part of software running on that system if you want to.
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.
I’m happy to announce the release of several Glibc heap analysis plugins (for
Linux), resp. plugins to gather information from keepassx and zsh, which are now
included in the
Rekall Memory Forensic Framework. This
blogpost will demonstrate these plugins and explain how they can be used. More
detailed information, including real world scenarios, will be released after the
talk
at this years DFRWS USA.
Before being able to reliably analyze the heap of a process, a profile, for the
Glibc version being used, must be provided. However, this step should for most
cases be fairly simple and only consist of gathering the offset for the mp_
and main_arena variables:
I’m a big fan of Chris Gates’ publications on
DevOops
and
From Low to Pwned.
The content reflects a lot of issues that we also experience in many assessments
in general and assessments
in agile environments in particular.
In addition, we were supporting several projects recently that were organized in
an agile way. In this post, I want to summarize some thoughts on how security
work can/should be integrated into agile projects. The post was also a result
from the preparation of our upcoming Troopers workshop on
Docker Security & Devops,
which of course also covers organizational aspects, but not to the degree this
post describes them.
In this post we’ll take a detailed look at the properties of the Windows Server
2016 IPv6 stack.
I perform(ed) this exercise for several reasons:
Server 2016 is the latest OS released by Microsoft so this might give an
indication as for their plans & strategy when it comes to supporting certain
specifications.
(here you may keep in mind that the ~50 IETF meetings having passed since the
publication of RFC 2460 provided ample opportunity for creative minds to come
up with ever new ideas for “enhancing” IPv6, without too much real-life
feedback/reality checks from enterprise space though, as simply not many of
such organizations have deployed it at scale… or are incentivized to send
their employees to week-long meetings in expensive hotels on other continents
twice a year…).
as I laid out
in this post
the configuration approach an organization takes for their servers might
depend on the support of specific features.
obviously for both IPv6 planning and operations it might be helpful to
understand the respective behavior of individual operating systems (which is
why we researched stuff like
this
or
this
in the past).
many years ago Microsoft published white papers with details as for the TCP/IP
parameters of their OSs (incl. stuff like registry parameters to control it
etc.) but I’m not aware of such a document for Server 2016 or Windows 10. I
hence hope this post can somewhat contribute to public knowledge of the
intricacies of their latest IPv6 stack.
In this post I’ll discuss configuration approaches for systems which usually
have been configured with “static” IP parameters in the IPv4 age/context (like
servers in data centers). When it comes to IPv6 there are more options and we’ll
have a look at their implications and potential advantages/disadvantages.
From my perspective there’s mainly four possible approaches which we see being
implemented or considered in our (predominantly enterprise) customer
space. Before we have a closer look at those let’s quickly write down
requirements that the involved planners or sysadmins might have in mind when it
comes to provisioning the systems in question. Some of those requirements might
seem obvious but it could still make sense to note them for the discussion to
follow. These might include:
This is the 3rd part of this loose series on considerations of (operating) DMZs
in 2016 (part 1 on the role of a DMZ is can be found
here,
part 2 on reverse proxies
here).
Again,
I dare to deviate a bit from the plan & order I initially had in mind – today I
will cover one process whose maturity may significantly influence the overall
security posture of a DMZ environment: firewall rule management.
How to provide updates to IoT devices – yes, I’m aware this might be a overly
broad generalization for many different devices – has been the topic of many
discussions in the last years (for those interested the papers from the
“Internet of Things Software Update Workshop (IoTSU)”
might be a good starting point).
Given Matthias and I will moderate the respective session at tomorrow’s
IoT Insight Summit
I started writing down some points that we consider relevant in this context.