IPv6 Focus Month: How to say no!
Oops, it's on!
Even if you could not care less about IPv6, there are quite serious security consequences to it being out there and to your devices having it. Even if you're not actively participating, you need to address the risk IPv6 poses in some environments.
IPv6 is equiped with the ability to connect with IPv4 networks - which sounds logical as before IPv6 is globally rolled out (if that ever happens), all globally accessible services (like "the web") are on the old IPv4 network. But even when you least expect it, IPv6 can open up tunnels through IPv4 networks and connect anyway - even where you have disabled the transition of IPv6 packets in perimeters and the like.
Now there are places you want no complications from having to deal with 2 concurrent IP stacks. Eg. an easy to audit high security setup (aka a donjon) that is not likely to run out of addresses is much easier if you can do it without added complications.
So what can we do ?
Host
At the host level we can try to tell it not to participate in IPv6, but it might be not all that easy. Beck when IPv6 started to become implemented some of us ripped out IPv6 support in our more critical machines' kernels. But even if you still succeed in that (it's not so easy anymore as in the early days), there is more and more you have to do as more and more of the system tools are IPv6 aware and will complain loudly if the kernel doesn't do IPv6 anymore.
There's a point where this doesn't pay off, anymore and obviously it's not something you can do in proprietary OSes anyway.
Many devices anlso simply cannot be configured not to do any IPv6 on their interfaces.
So your options on hosts are often limited. And it often lacks central control to enfoce it across all hosts you might have.
Network
The more intelligent your network is, the more likely you can write filters in it not to transmit IPv6 packets. This is still not your perimeter that blocks it, but it's you best approach to make sure machines do not start to talk IPv6 among themselves within your perimeter.
In larger networks one can e.g. use netflows to monitor for IPv6 traffic on the inside as well.
Perimeter / Firewall
Your firewall is essentially a router that filters traffic. Now most highend environments will have a default closed policy and as long as that policy is also applied to IPv6 you should be in the clear for traffic that passes through your perimeter.
But: how do you know it is in fact closed for IPv6 when you have e.g. a bit older software that only knows about IPv4. How can you be sure it's blocking IPv6 ?
The answer lies in detecting IPv6 traffic.
Similarly, if you policy isn't a fully closed policy, you need to work to make sure that IPv6 packets that disguise themselves as IPv4 do not leave your secured area as they would become accessible from the outside through tunnels they create themselves.
Monitoring
Your IDS/IPS and other monitoring might need to monitor for IPv6 use if you do not want it to be used.
Encapsulation
So that leaves us to try to enumerate how IPv6 can be embedded in IPv4.
-
If you look at the IPv4 protocol numbers (official list here), you'll notice there are a lot of them in there related to IPv6. Yes, IPv4 can be encapsulated next to ICMP (1) , TCP (4) and UDP (17) etc.
The most commonly known one is 41, but there are quite a few others, all relating to IPv6. -
In order to pass through out IPv4 NAT gateways (technically some will call it port address translation - as more often than not we're doing an N to 1 mapping) it's easier for those building a tunnel to encapsulate their IPv6 in a UDP packet.
So you need to know these too. I know of Teredo which is built into windows and enabled by default.
Teredo connects to UDP port 3544 by default. - Essentially nothing prevents a determined -or malicious if you're enforcing policies- entitiy on the inside of your perimeter to tunnel any protocol over any other allowed one - even if proxied, nothing changes there obviously. As soon as you allow communication there is a potential for those on the inside and outside to work together to build a tunnel - fact of live.
Well known endpoints
There are a number of well known endpoints for IPv6 tunnels.
- DNS request for isatap.MyCompany.com. indicate a ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) in action
- DNS request for teredo.ipv6.microsoft.com indicate Teredo in action.
- 192.88.99.* is used by 6to4
Those can be blocked and/or monitored. But again no guarantees exist no new tunneling mechanisms will be invented are existing be intentionally modified to escape anyway.
Papers
In a quick search I found this at vendors on how to block IPv6:
- http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-629391.html
- http://technet.microsoft.com/en-us/library/bb726956.aspx
Well, then it's off to you, our readers: feel free to comment on how you prevent IPv6, your experiences in getting out to the rest of IPv6 without a cooperating perimeter etc.
--
Swa Frantzen -- Section 66
https://www.sans.edu
