In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.
As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.
So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the second part we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.
In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).
We’ve been involved in some activities in this space recently and I thought it could be a good idea to share a couple of things we’ve discussed & displayed. Furthermore some time ago – in the Is IPv6 more Secure than IPv4? Or Less? post – I announced to come up with (something like) an “IPv6 threats & controls catalogue” at some point… so here we go: in an upcoming series of a few blogposts I will lay out some typical elements of an “Enterprise IPv6 Security Strategy” incl. several technical pieces (and I plan to give a talk on the exact topic at next year’s IPv6 Security Summit).
Some readers will probably be aware that we are amongst the proponents of a quite strict stance when it comes to filtering IPv6 packets with (certain) Extension Headers and/or fragmentation, because those can be the source of many security problems (as laid out here, here or here). Actually I still think it was a very good idea of, amongst others, Randy Bush and Ron Bonica to suggest the deprecation of IPv6 fragmentation in the IETF.
On the other hand there are voices arguing that fragmented IPv6 packets will be needed in some cases, namely DNS[SEC]-related ones.
In this post I will discuss some details of this debate (taking place in many circles, incl. this thread on the ipv6-hackers mailing list which, btw, you should subscribe to). Continue reading “Some Notes on the “Drop IPv6 Fragments” vs. “This Will Break DNS[SEC]” Debate”
Last week Christopher and I were the instructors of an IPv6 workshop. In this one we usually build a lab with the participants incl. a variety of routed segments and native IPv6 Internet access. Once the latter part is implemented people start poking around and surfing the Internet from their laptops, not least to find out which sites they can actually reach from an v6-only network (please note that actually there are many).
Given there’s quite some speculation and, as we think, misinformation going around we think it’s helpful to add/clarify the following information:
we fully comply with the injunction and we have no intentions to violate it. we do not plan to publish any technical information besides the report (agreed upon with FireEye themselves) and the slides (based on the former) anyway. No 3rd parties except for the ones involved (FireEye, lawyers) have received any additional technical information from our side, let alone an earlier version of the report.
the injunction covers accompanying details mostly within the architecture space, but not the core vulnerabilities themselves. Those are not part of the injunction.
we stand by the timeline as provided below. In particular, the following two points:
– FireEye received a draft version of the report which had the objectionable material (as identified by the cease and desist letter) fully removed on August 11th.
– according to the cease and desist letter FireEye’s lawyer sent us, they were informed – from our side – about the planned talk at 44CON on Jul 23rd.
there’s an injunction, but not a lawsuit. I used the term “sue” after consulting Merriam-Webster which states: “sue: to seek justice or right from (a person) by legal process”, but this might have been misinterpreted by some readers. As stated, there’s a pending injunction, but not a lawsuit.
Please note that we won’t share legal documents with 3rd parties or publish them as we consider this inappropriate.
Please note further that, during the whole process, our goal was to perform a responsible disclosure procedure with its inherent objectives (namely vulnerability remediation by vendor and education of various stakeholders involved, see also here or here). We consider this disclosure process as concluded. We don’t see a need to add technical details from our side as we feel that the objectives of responsible disclosure are met (not least as patches are released since quite some time and both vendor & finder have released reports).
===
We’ve just released an ERNW Newsletter titled “Playing With Fire: Attacking the FireEye MPS” which describes several (meanwhile patched) vulnerabilities in FireEye‘s “Malware Protection System” (webMPS) version 7.5.1. Right now Felix gives a talk at 44CON in London on the topic, including some demos. He will release the slides after the talk => to catch the respective announcement you might follow him on Twitter (which is probably a good idea anyway if you’re interested in vulnerability research).
This year’s Black Hat US saw a number of quite interesting talks in the context of Windows or Active Directory Security. For those of you too lazy to search for themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to Vegas due to heavy project load) I’ve compiled a little list of those.