Because Google started to delete hacking related blog posts without using a single brain cell, I had to learn just another framework. Thx Google
Secure IPv6 deployment checklist think twice, deploy once
Published on 10 Dec 2013
Before deep-diving into IPv6, I'm going to summarize my views on IPv6:
- Start now(!) to plan your IPv6 deployment - in case you have not done so.
- IPv6 is the future! There is no other choice.
- NAT is the root of all evil.
IPv6 is coming. We've heard this 10 years ago as well, but it is really coming now. If you live in Asia, you can see this in real life. If you live in Europe or the USA, you can feel the pain of triple NATed devices.
Deploying IPv6 is not a binary task, you can do it in small steps. Get a public IPv6 address space, assign IPv6 addresses to your servers (e-mail, web, DNS).
Great, you are now ahead of the world!
Now, what about clients who want to access IPv6 web or email? You are lucky if you use an IPv6 compatible web/email proxy because the clients can still stay on IPv4.
Now, what about your clients/servers accessing IPv6 services on the Internet directly (without a proxy)?
- If your network supports IPv6, your clients can directly access IPv6 services.
- If your network does not support IPv6, clients can still use tunneling protocols, e.g. ISATAP for Windows clients.
This might sound easier than it is. But do you have the budget/people/management support to do this?
Anyways, before you deploy IPv6 in your corporate environment, you have to think about the security issues. The next list is far from comprehensive or complete. Beware, here be dragons!
It is a myth that IPv6 is more secure than IPv4. The only practical security addition in IPv6 is called IPSEC, and has been backported to IPv4 many years ago.
Most networking people are not familiar with the new terms, best practices introduced with IPv6. It is important to educate the networking and security personnel about IPv6, and let them play with the technology.
IPv6 can reintroduce basically all security vulnerabilities which has been mitigated in IPv4:
- If the vulnerability is not in the IP layer, the vulnerability will stay there. Although it sounds obvious, most people tend to forget this. Your MS08-067 vulnerability won't magically disappear if you use IPv6. OK, but you closed port 445 on the firewall. Oh crap, it is open on IPv6...
- Man-in-the-middle attacks: Organizations have already guarded themselves against ARP spoofing and DHCP server spoofing with mitigation techniques like DAI (Dynamic ARP Inspection) and DHCP snooping in the world of IPv4. The only thing which has been changed is the name of the attacks and defenses. Search for ICMPv6 attacks, and Neighbour Discovery attacks.
- Source routing: Source routed IPv4 packets have not been seen for a while bypassing firewalls, but "luckily" the IPv6 standard reintroduced source routing in IPv6, in the name of Type 0 Router Headers. You should check whether your OS/network equipment support Type 0 Router Headers. If you have time, play with Scapy to test it.
- Blocking ICMP: Let's face the truth: In order to effectively use IPv6, some ICMPv6 messages has to traverse through firewalls. Like it or not, you can't hide your clients anymore.
- Router advertisement: Let's play a game. Go into any network, and start broadcasting IPv6 router advertisement packets in the network. Guess what, the clients are going to connect to you, and you will be the default IPv6 gateway for the clients. If there is no web proxy configured on the client, this means all Google, Youtube and Facebook traffic will be routed through your box, because IPv6 is preferred over IPv4. This can be the next generation WPAD attack :) If you don't want to be vulnerable, better search for RAGuard or similar solutions.
- Translation/tunneling: If all your network equipment support IPv6 and configured to use it, you are lucky, because your clients can use native IPv6. Otherwise, your clients have to use 6to4/ISATAP/Teredo/NAT64 or whatever IPv6 translation/tunneling. Do you know these protocols? Do your security products know these protocols?
- Dual stack: Your clients have to use both IPv4 and IPv6 together for a while. Be aware of the additional operating costs of maintaining 2 network protocol parallel.
- Fragmentation: In the first era of IDS/IPS devices, one of the main bypassing technique was IPv4 fragmentation. Have you checked whether your current solutions (IPS/IDS) parse fragmented packets the same way as your protected assets?
- The IPv4 implementations have been tested thoroughly, and not much implementation bug is left there. But IPv6 implementation bugs, there will be a lot from them. Most of the programmers still don't know the basics of secure coding practices.
- IPv6 evercookie: Now that your clients don't have the same NAT IP, they static IP can be used to track them online. Luckily Microsoft solved the issue with IPv6 privacy extension, so clients will use temporarily IPv6 addresses to communicate with the Internet. Great, now how do you know in your security logs, which IPv6 address is which client???
Do your current security devices fully support IPv6? Have you tested this?
- Hardware Firewall (with all dual-stack/translation/tunneling nightmare)
- Do you block all outgoing UDP from the clients, especially 3544?
- Can you maintain rules for both IPv4 and IPv6?
- If you remove an IPv4 rule, do you remove the same rule for IPv6?
- Log collection, log analysis, correlation:
- Do the logs contain IPv6 addresses?
- Is it parsed by the SIEM application?
- Do you know that the DHCP IPv4 address is the same asset (workstation) as the IPv6 address with a privacy extension?
- IPS, IDS:
- Can these applications monitor/block all kinds of IPv6 translation/tunneling protocols?
- WAF:
- Is your WAF IPv6 ready/aware?
- What about fragmentation?
- VPN:
- Can your clients connect to IPv6 services through VPN?
- Is your IPv6 VPN firewall rule as restrictive as the IPv4 one?
- If you remove a rule on IPv4, do you remove the same in IPv6?
- Software firewall:
- Is your software firewall IPv6 ready/aware?
- Does it understand all translation/tunneling protocols?
- Does it filter incoming traffic to the Teredo interface?
- AV/endpoint protection:
- Is your AV/endpoint protection IPv6 ready/aware?
- What about files downloaded via IPv6, is it scanned the same way as IPv4?
- DLP (if you are in the 1% who actually bought one and enrolled it in production):
- Is your DLP IPv6 ready/aware?
- Can it monitor tunneled traffics?
And last but not least, the bad news: you are already using IPv6 if you have Windows7 notebooks leaving your company, not having access to the domain controller. Or have you checked your servers link-local IPv6 addresses recently? Do you have a Windows2008 cluster? It is using IPv6 already!
The good news? In the not so far future (I estimate 2050) you can turn off your last device with IPv4 address, and forget all the nightmare around NAT and dual-stack. Because remember: NAT is not a security feature. It never was.
Useful links: