Just a short addition to the previous posts ([1], [2]) on IPv6 security today. In the last two days I had the opportunity to sharpen my understanding of some aspects of IPv6 behavior in (Windows-) LANs. Actually I gave an IPv6 workshop for some members of the “Project Services” team of Hamburg-based computer & competence IT-solutions provider [btw: thanks to Mr. Wendler of CuC for organizing it, and thanks to Mr. Cassel for the breakfast…].
Those guys were amazingly adept with Wireshark (I got a ‒ long-needed ‒ refresher on display filters ;-)) and networking technologies in general so it was a workshop in the purest sense: lots of practical hands-on, lots of tinkering, lots of enligthening discussions.
I pretty much like every part of my work (I mean, from my humble perspectice infosec is the most exciting discipline anyway, isn’t it ;-)) but workshops like this one are sth I particularly enjoy. Huge personal progression and getting paid for it 😉
Ok, enough enthusiasm… let’s get back to earth. Based on the stuff we did I’d like to raise two points.
a) I found out that the latest MS Windows versions all seem to dispose of a parameter allowing to disable the processing of router advertisements at all. Being an old-fashioned networking guy I’m not sure if I like this (given it seems a violation of core IPv6 architecture fundamentals), still ‒ wearing the hat of a network security practitioner ‒ I recognize there are certainly use cases where this comes in handy, e.g. DMZ segments with a mostly (and deliberately so) static configuration approach.
The parameter can be set on an interface level by
netsh int ipv6 set int [index] routerdiscovery=disabled
Checking the actual state of it can be done by
When set the box (interface) in question will not process router advertisements anymore which might provide some protection against RA based attacks (notably the spoofed RA attack described in this post). The configuration of the basic IP parameters must then either be done manually or by means of DHCPv6. It should be noted that DHCPv6 currently does not provide an option to distribute a default route/gateway (this IETF draft on Default Router and Prefix Advertisement Options for DHCPv6 was seemingly discontinued, see also the extensive discussion in RFC 6104) so in case of a DHCPv6 based (stateful) configuration approach the respective systems won’t have a default route (which, again, might be helpful for their security, in certain scenarios).
Obviously, once you use this one for hardening purposes, you should closely keep track of the affected systems. Else troubleshooting might became a nightmare …
b) I had a closer look at the router advertisements generated by fake_router6 from the THC-IPV6 attack suite. Those are generated with a “High” (value: 01) router preference. So going with a high router preference on one’s own might just provide equal terms. Of course we still recommend to use this approach (discussed in this post, and in RFC 6104) to protect from “mislead entities emitting router advertisements on the local link”.
Post on tunnel technologies to follow ;-), thanks
Enno
Howdy! I could have sworn I’ve been to this site before but after checking through some of the post I realized it’s new to me.
Anyhow, I’m definitely delighted I found it and I’ll be book-marking and checking back frequently!