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.