During our blogpost regarding DHCPv6 Guard evasion, one of the side-effects was that Access Control Lists (ACLs) configured to block access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers. Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco routers can be evaded, as well as under which conditions this can take place. To this end, several representative scenarios from enterprise environments or other potential ones are examined.
I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state – you know, “stateful” firewalls and the like 😉 – before (here and here. btw, the widely discussed IPv6-related network outage at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the unfortunate relationship of MLD and ND).
One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.
Given that Enno and I are network geeks, and that I am responsible for setting up the Troopers Wifi network I was curious which components might be used at Cisco Live and which IPv6 related configuration was done for the Wifi network to ensure a reliable network and reduce the chatty nature of IPv6. Andrew Yourtchenko (@ayourtch) already did an amazing job last year at Cisco Live Europe explaining in detail (at the time session BRKEWN-2666) the intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these networks. He was also a great inspiration for me when setting up the Troopers Wifi network a couple of weeks later. Thank You!
We’ve finalized the agenda for this year’s IPv6 Security Summit. Here’s an overview of the event:
The “IPv6 Security Summit” is a special two-day convention in the context of the Troopers security conference. It will be run in two tracks of both half-day workshops and 90 minute presentations on specific topics. The goal is to foster the discussion of IPv6 security aspects & issues and to provide practical advice for security officers, network planners and practitioners in the IPv6 security field.
We’re sometimes approached with the question “Which IPv6 mailing lists do you guys read/subscribe to?” – here’s a quick overview of the main ones guys like Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at, to discuss IPv6 (network|security) related stuff with other practitioners and to learn from them:
during our BlackHat US 2014 talk titled “Evasion of High-End IPS Devices in the Age of IPv6”, among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:
RA Guard Evasion is well-known in the IPv6 “circles”; there is RFC 7113 Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one here, here, and this excellent write-up here that discuss this issue.
Moreover, as Jim Smalls states in his comprehensive “IPv6 Attacks and Countermeasures” presentation given at the North American IPv6 Summit 2013, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.
Most of you are probably aware of the recently discovered/-closed severe ntpd vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see also the initial ntp.org security notice). Some days ago the Project Zero team at Google published a blog post “Finding and exploiting ntpd vulnerabilities” with additional details. In this one they mentioned a seemingly minor but quite important detail: on a default OS X installation one of the built-in protection mechanisms of ntpd (that is the restriction to process certain packets only if they are sourced on the local machine) can easily be circumvented by sending IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1 in IPv4 which would be discarded by the kernel once received from an external source).
After we recently released the “Linux IPv6 Hardening Guide” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the ipv6hackers mailing list).
Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It can be found here.
Once more we’d like to emphasize that the approach described is only suited for very specific environments with high security requirements and an associated ratio of “generous operational resources”. From our perspective this guide is intended mostly to serve as a source of inspiration (“what could be done”) and for documentation purposes (“how to do it”). Everything described should be carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an organization where the Windows guys (completely legitimately) came up with a stance of “before we fully accept and ratify the strategy and policy just discussed, we’d like to get feedback from Microsoft, if we still have full support once we follow this path”.
We were recently approached by a customer asking us for support along the lines of “do you have any recommendations as for strict hardening of IPv6 parameters on Linux systems?”. It turned out that the systems in question process quite sensitive data and are located in certain, not too big network segments with very high security requirements.
They indicated they were willing to spend significant operational resources on “securely configuring them”. So Antonios deciced to write a small hardening guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much everything (including neighbor cache entries 😉 with accompanying deactivation of all automatic mechanisms, together with ip6tables based local packet filtering.
The document can be found here.