TAG | IPv6
This is a guest post from Antonios Atlasis
my name is Antonios and I am an independent IT Security Researcher from Greece. One of my latest “hobbies” is IPv6 and its potential insecurities so, please let me talk to you about my latest experience on this.
This week, I had the opportunity to work together with the ERNW guys at their premises. They had built an IPv6 lab that included several commercial IPv6 security devices (firewalls, IDS/IPS and some high-end switches) and they kindly offered their lab to me to play with (thank you guys – I always liked …expensive toys). The goal of this co-operation was two-fold: First, to test my new (not yet released) IPv6 pen-testing tool and secondly, to try to find out any IPv6-related security or operational issues on these devices (after all, they all claim that they are “IPv6-Ready”, right?).
Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.
0 Comments | Posted by Christopher Werny
Some of you may already know (the ones who are following Enno on Twitter) that Enno and I had our lab day in preparation for the IPv6 Security Summit at Troopers. We had a brand new and shiny Cat4948E as our lab device to do some testing of the current generation of Cisco’s IPv6 First Hop Security (FHS) mechanisms. The Catalyst was running the latest image available (15.1(2)SG3).
In this small blog post, we will take a look at the configuration and behavior of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping:
2 Comments | Posted by Enno Rey
This is the second part of the – presumably – three-part series on IPv6 address planning which I started here.
Before an enterprise organization (strictly speaking “their internal service provider acting as LIR”, as laid out in the first part) starts assigning prefix[es]/lengths to their networks usually another discussion has to be undertaken & solved: “go with one /32 [PI space] from one RIR or apply for /32s from several RIRs”.
The background of this reflection is mainly them being concerned along the lines: how do we know if $PROVIDER in some part of the world is actually going to route our PI space, in particular if that’s allocated from ‘a foreign RIR’?
5 Comments | Posted by Enno Rey
In an upcoming series of blog posts I will discuss some principles & considerations on developing an IPv6 address plan. In (hopefully) rather quick succession there will be three posts:
- the first on some general rules as for IPv6 address planning which we regard instrumental in the process.
- the second covering the “PI space from a single RIR or PI space from each (relevant, as for $ORG) RIR?” debate.
- the third on actual approaches to structuring/grouping each region’s /32 (or /36) into subdivisions like sites, VRFs, facilities, use types, buildings, whatever. I understand that this part is probably the one quite some readers are most interested in; still for a reasonable line of thought the others have to be covered in advance.
0 Comments | Posted by Enno Rey
Such was the title of a talk I gave yesterday at ACSAC 29. It was an updated and shortened version of a similar talk I had given at the Troopers IPv6 Security Summit (btw: this is the preliminary agenda of the 2014 event).
The slides of the ACSAC talk can be found here.
have a great weekend everybody
This is a guest post from Antonios Atlasis.
Having just finished the second “Advanced Attack Techniques against IPv6 Networks” workshop (some of the course material can be found here), organised and hosted by ERNW and their partner HM Training Solutions, I would like to take this opportunity to release publicly one of my scripting tools, an IPv6 scanner. This tool is based on Scapy (so you have to install Scapy and its prerequisites before using it). It should not be considered as a replacement or a competitor of nmap against IPv6 or of the scanners incorporated into the great IPv6 toolkits already released by Marc Heuse and Fernando Gont, but, instead, as a tool released mainly for educational purposes. Specifically, this scanner, apart from supporting some of the most well known port scanning techniques, from ping scanning to SYN, RESET, ACK, XMAS, etc., etc., TCP or UDP scanning, it also combines, by using the suitable switches, some IDS/IPS evasion techniques. As I have found out up to now, at least two of them, if used “properly”, can be effective against a very popular IDS/IPS software used by many “Fortune 100” companies out there. This means that you can launch actually any type of the supported network-scanning techniques while flying under the radar of this specific IDS software (and perhaps some other too, who knows…). But first of all, as always please check the corresponding README file.
I recently had a discussion with some practitioners about requirements to IP Address Management (IPAM) solutions which are specific for IPv6 networks. We came up with the following:
Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP etc.), by polling neighbor caches from network devices. Support SNMPv3 for this task.
Optional (read: nice-to-have): support other methods than SNMP to gather this info (e.g. SSH-ing into devices and execution of appropriate “show” commands).
Mandatory: Display connected switch port (incl. device name or CDP-type info) for all addresses.
Mandatory: Be able to sort addresses according to their categories, e.g. “show all SLAAC systems vs. all systems with DHCPv6 addresses”.
Optional: Be able to easily identify systems which have several types _simultaneously_ (e.g. “static + SLAAC address”, “SLAAC + DHCP managed address”).
Mandatory: Full support for RFC 5952 notation in all UIs (both entry and display of addresses).
Optional: be able to display addresses in other formats in reports or exported files (e.g. CSV files).
Hope that some of you might find this useful when reflecting on the topic; have a great day everybody
a) The slides of our contribution can be found here. Again, pls note that this is work in progress and we’re happy to receive any kind of feedback.
[given Fernando explicitly mentioned Troopers, we've allowed ourselves to put some reference to it into this version of the slide deck...]
b) the scripts Stefan currently puts together will be released here once they’ve undergone more testing ;-).
c) Sander Steffann mentioned that Juniper SRX models do have IPv6 support for management protocols. According to this link this seems somewhat correct.
e) I was really impressed by the work performed by these guys and I think that ft6 (“Firewalltester for IPv6″) is a great contribution to the IPv6 security (testing) space.
And, of course, Marc’s latest additions to THC-IPV6 shouldn’t go unnoticed ;-). And I learned he can not only code, but cook as well.
Eric Vyncke commented “To be repeated”. We fully second that ;-).
Next to IETF 87 going on in Berlin in a few days there will be an informal meeting of the “IPv6 Hackers” on Tuesday. We really look forward to personally meet a number of people who we (so far) only know from the associated mailing list or similar machine-enhanced exchange. We hope to contribute as well. Based on the stuff of this workshop from the IPv6 Security Summit at Troopers13 we might give a short project presentation along the lines of “Some Notes on Testing the Real-World IPv6 Capabilities of Commercial Security Products”, providing an overview of some testing done on commercial gear, together with a discussion of testing approaches, tools and key aspects.
I currently discuss this potential input with the guy who gratefully organized the meeting. In any case I encourage everybody interested in IPv6 security to show up there (you don’t have to be registered to IETF 87) as there’s not much that can substitute meeting in person to discuss how to make the IPv6 world a safer place.