We’re currently involved in a number of IPv6 activities in different
organizations and one of the questions we are still facing – even in cases where
there’s already a (in most cases networking team driven/originated) “project”
(incl. budget, project sponsor, milestones etc.) – is along the lines of “How to
sell IPv6 to our management?”.
In the following I will shortly lay out the line of reasoning and the
terminology we usually employ for the task. Furthermore I’ve anonymized a
presentation which we recently prepared as “input” for the network team of an
enterprise organization;
it can be found here. In
case you want to get this as a PPT (for recyling purposes) pls send me a direct
email (in exchange, we might ask you for a small donation of your will to the
Troopers charity project…
).
Some weeks ago, at RIPE 68 in Warsaw,
Sander Steffann gave a
presentation about revising RIPE 554
which, in his own words, “is a template guideline for procurement of stuff that
should do IPv6” (here’s the
steganography transcript of the IPv6 working group session). Some of you will
probably know RIPE 554 as a quite
helpful document for identifying reasonable real-world requirements for IPv6
capable network devices (in particular at times when vendors quite willingly put
an “IPv6 ready” sticker on all their gear…).
Past month we (which is me and a group of other ERNW students, supported by some
of the “old” guys — I hope my team lead won’t yell at me for this 😉 ) attended
the Haxpo and Hack in the Box in Amsterdam. Starting from 28. May, we had three
days at this great conference (HITB) and exposition
(Haxpo). The two events took place in the former building of
the stock exchange in Amsterdam, called:
“Beurs van Berlage”. Upon entering the
building for the first time we were given details on where our booth was and
where the talks would take place — setting up our booth and planning the shifts
was just another thing to do before exploring the Haxpo area:
regularly we get requests from customers where the idea of using Skype as a VoIP
solution in their corporate environment is brought up. There are a lot of
eavesdropping and more conceptual concerns (e.g. refer to
this
or
this,
and of course the legendary
“Silver Needle in the Skype”
paper from Black Hat EU 2006), but those won’t be covered in this post (just to
say this: at ERNW the use of Skype is strictly prohibited at by policy).
As we continue our research in the 3GPP protocol world, there is a new tool for
you to play with. It is called s1ap_enum and thats also what it does 😉
The tool itself is written in erlang, as i found no other free ASN.1 parser that
is able to parse those fancy 3GPP protocol specs. It connects to an MME on
sctp/36412 and tries to initiate a S1AP session by sending an S1SetupRequest
PDU. To establish a S1AP session with an MME the right MCC and MNC are needed in
the PLMNIdentity. The tool tries to guess the right MCC/MNC combinations. It
comes with a preset of known MCC/MNC pairs from
mcc-mnc.com, but can try all other combinations as
well.
Last October I had a quick look at pfSense 2.1
regarding the IPv6 support that it offers. It was the first stable support of
pfSense that offered the capability for IPv6 network connectivity (a few
comments about it can be found
here). However,
I knew that m0n0wall supported IPv6 quite a long time
ago and that their developers had incorporated the support of IPv6 features
which are not available in pfSense yet, so today I decided to have a look at it
too.
As it is well known to the IPv6 enthusiasts, one of the most significant changes
that IPv6 brings with it, apart from supporting a really huge address space, is
the improved support for Extensions and Options, which is achieved by the usage
of IPv6 Extension headers. According to
RFC 2460, “changes in the way IP
header options are encoded allows for more efficient forwarding, less stringent
limits on the length of options, and greater flexibility for introducing new
options in the future.” So, by adding IPv6 Extension headers, according to the
designers of the protocol, flexibility and efficiency in the IP layer is
improved.
I recently stumbled over a
document from
Microsoft which lists all services/applications that support IPv6. Most of the
content wasn’t new for me, but one item caught my attention. Windows Update. I
haven’t heard before that Windows Update can be done over IPv6 (but this could
just be me not looking hard enough ;)), so I was eager to test it out seeing if
this is really the case. I was also curious why Microsoft referenced this
document
in the respective column.
In the course of a recent penetration test, we came across an Image validation
vulnerability in Django when using the
Python-Imaging-Library (PIL) which we
want to explain in this post.
Everybody who doesn’t know what Django and/or
the PIL is:
Django is a framework to create web applications with Python (comparable to
Rails or Zend). The PIL is a powerful standard python library which provides a
toolset to modify, display and verify images of many different formats.
This is the third – and hence presumably last – part of the series of posts on
IPv6 address planning (first part can be found
here,
second one
here).
It’s split into three main pieces. In the beginning I will lay out some general
objectives to be considered when designing an address plan. Then I’ll have a
look at potential hierarchy levels and finally I’ll discuss some real-life
samples we’ve seen recently.
