Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

IPv6 Focus Month: How to say no!

Published: 2013-03-12
Last Updated: 2013-03-12 17:14:25 UTC
by Swa Frantzen (Version: 1)
2 comment(s)

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:

 

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

Keywords: IPv6
2 comment(s)
Diary Archives