A
talk
about DirectAccess (an IPv6-only VPN solution) was given by our colleague Ali
Hardudi during IPv6 summit. Ali has recently finished his master thesis on this
topic.
The DirectAccess VPN technology was introduced by Microsoft starting from
Windows server 2008. It allows users remotely, seamlessly and securely connect
to their internal network resources without a need to provide user credentials,
which is done using different technologies such as Windows domain group
policies.
Jasper Bongertz is a Senior Technical Consultant at Airbus Defence and Space
CyberSecurity. He is focusing on IT security, Incident Response and Network
Forensics.
During the IPv6 summit on Troopers16 he had given a
talk
on anonymization IPv6 in PCAPs and presented his new tool.
Sometimes you need to share your packet capture files (PCAPs), but distributing
them involves a risk of exposing the confidential information. To avoid this,
you must sanitize your PCAPs. The goal of sanitization is to remove the critical
details but keep enough information for the PCAP to still be useful. The
original-to-sanitized ratio is based on your goals.
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.
Fernando Gont, who is specializing in the field of communications protocols
security, gave a
talk
during this year’s Troopers IPv6 summit. He spoke about network reconnaissance
techniques in IPv6 area and presented a brand new set of tools for this purpose.
Comparing with methods for IPv4, reconnaissance techniques for IPv6 should be
different. It offers much larger address space, so such attacks as brute force
address scanning are not feasible anymore, because it would take too much time
to send one packet to each and every possible address. Fernando has also noted
that in general network reconnaissance support in security tools has
traditionally been poor. Together these facts prompt that it’s time for
something new, and recently a new
IETF RFC 7707 was published.
Yet another interesting 180-minute workshop in IPv6 Security Summit of
TROOPERS16, which aimed to introduce the IPv6 troubleshooting and monitoring
tools, which are essentially needed by users in order to know how to deal with
IPv6 in any IPv6-enabled network.
Before we dive into this post, let me introduce you in few words “Gabriel
Müller” the speaker and the instructor of this workshop. Gabriel works as a
senior consultant at AWK Group by mainly assisting clients in the public and
private sectors as a project manager and an expert in the network area.
Christopher Werny leads the network security team for ERNW and since 2005 he is
involved in numerous IPv6 projects where he is responsible for planning,
implementation and troubleshooting existing projects.
The first topic he approached was “How to build a conference WLAN Network in
General”. The very first suggestion was to put it to the 5GHz channel because
there could be a lot of interferences in the 2.4 GHz channel. The basic idea
here is to disable 802.11b completely if it´s possible in your environment and
no-one is using it anyway. Further you should also consider nearby Wi-Fi signals
and on which channels they reside. His next recommendation was about setting the
inactivity timer to short intervals, this will avoid unnecessary resource
spending from the APs when they try to track down moved or shut down devices.
His last general recommendation from him was regarding a central DHCP Server.
This will enable the roaming from mobile devices without getting a new
IP-Address when bridged mode is enabled for the APs.
The Troopers experience will never be the same without the
“IPv6 summit”. It is one of
kind of two-day special event where different security experts gather to discuss
IPv6 current challenges. It addresses different topics ranging from a broad
introduction of the IPv6 to how secure the protocol is and what the latest
standards are.
The summit is divided into 2 different tracks that run simultaneously. For the
first day on the second track, Christopher Werny and Rafael Schaefer have
carried out the first three sessions.
Wireshark in IP version 6 workshop was a part of IPv6 summit sessions of
Troopers 16. It was held by Jeffery Carrell on the second day of IPv6 summit on
Tuesday, the 15th of March. The workshop was generally divided into two
sections: a short introduction to IPv6 and analyzing some IPv6 packets on
Wireshark.
Introduction to IPv6
IPv6 protocol was defined at the end of 1990’s, mainly to provide a huge address
pool after realizing that the world would run out of IPv4 addresses quickly. The
work on IPv6 started before the introduction of NAT and Private addressing to
IPv4, which are considered temporary solutions of IPv4 address shortage problem.
IPv6 address consists of 128 bits, divided into 8 groups called nibbles,
quibbles or hextets separated by colons. Each nibble consists of four
hexadecimal digits. The 128 bits address length provides 340 trillion trillion
trillion addresses. An IPv6 address is divided into two parts: the left part is
the network identifier while the right one is the host identifier. The default
prefix is /64 which divided the IP address into two halves. An IPv6 address
looks as follows: 2001:0db8:1010:61ab:f005:ba11:00da:11a5/64
**tldr;**This blogpost presents a measurement study of a current security state
regarding to open ports on a direct comparison of IPv4 and IPv6. The study
analyses almost 58,000 dual-stacked domains in order to find discrepancies in
applied security policies. We further discuss the potential reasons and, more
importantly, the implications of the identified differences. \tldr;
For those of you who couldn’t participate at Troopers Conference 2016 in
Heidelberg or watch my talk at the IPv6 Security Summit, I want to recap some of
the most important parts of my research in this blogpost.
Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))!
After things have settled, I want to take the opportunity to reflect my thoughts
and impressions on the IPv6-only WiFi we had deployed during the conference. To
make sure that everybody is on the same page let’s start at the beginning.
In the last couple of years we had provided Dual-Stack connectivity on the main
“Troopers” SSID but also had an additional IPv6-only SSID. This year we decided
to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while
providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a
feeling how many clients and applications can work properly in an IPv6-only
environment. We intentionally didn’t announce it vastly beforehand, hoping that
attendees would just connect to the main SSID without noticing anything. We were
aware that some applications might expose issues but, as I said , we wanted to
get a feeling to which degree problems actually occured.