On Mar 23, 2014 8:44 PM, "Mike Hale" <eyeronic.design@gmail.com> wrote:
"Your attack surface has already expanded whether or not you deploy IPv6." Not so. If I don't enable IPv6 on my hosts, the attacker can yammer away via IPv6 all day long with no result.
I suppose it depends on the size of your enterprise. But in one our size, despite all the controls we have in place, there is no way we could ever be assured that IPv6 was disabled on every single endpoint everywhere. So you absolutely need IPv6 enabled at your perimeter so you can see what's going in and out. And the more you're able to deploy it internally the better you're able to control it. The odds are if you're an enterprise of any size and you're simply depending on disabling IPv6 for protection, then you're probably more vulnerable than you think. Moreover, most enterprises have significant quantities of Windows clients and servers deployed. While you can alter the registry to completely disable IPv6, it's not a configuration that's supported by Microsoft. All their security and regression tests is done in v4 only, dual-stacked, and v6-only networks, but never with IPv6 disabled entirely. And given that since Vista/Server 2008 their network stack was rewritten to be entirely IPv6 (using v4 mapped addresses for ipv4 support), I'm not sure that placing your hosts in an untested configuration improves your security profile. Moreover it's known to break some things in unpleasant ways. That includes HyperV clustering and Exchange 2010 services. (My own organization ran into the Exchange issue.) So it's may very well be that you can't completely disable IPv6 on hosts and, even if you do, it may make your security profile markedly worse.
For those devices that have publicly routable IP addresses, sure.
If there's no firewall and an enterprise is depending on NAT44 alone to protect internal devices, then using an RFC1918 address is no protection. NAT traversal is old hat. It's the firewall that prevents access to/from internal devices, not whether or not they have publicly routable addresses. That's true for IPv4 and IPv6.
"My organization is particularly strict at our perimeter" Then sir, you're in a fortunate and small group.
In can be a pain sometimes. By law, we have some pretty strict security requirements.
"I've simply pointed out that it really isn't any harder to plan and manage for v6 than for v4" Except it is. I get your point that there aren't any additional vulnerabilities in v6 than they are in v4. My point is that it's a lot more work. And as someone who's facing this issue right now, I promise you...it's a lot more work. I'm not saying it's not worth the effort nor that it's unnecessary...but to imply that securing v6 is an easy step up from securing v4 is inaccurate.
I don't think I ever said it was easy. IPv4 security isn't easy to do right. But if you're doing v4 right and have the processes in place to support it, it's not all that much harder to do it for IPv6. And one of my hats has been the IPv6 transition technical lead for my organization since 2011 so I feel your pain. I do mostly rely on our cybersecurity subgroup lead on the security side, but have to keep abreast of security issues myself.
"Simply pretending that if you don't enable IPv6, you're somehow immune from IPv6 threats is naïve." No. If I turn off v6 in my kernel, I am absolutely immune from native v6 threats. I'm happy to be proven wrong if you can show me a case where this isn't so.
On any given single host, sure. Until that host is compromised and v6 is enabled. But my point was that it's virtually impossible to ensure that's the case across the board for every endpoint device on an enterprise network of any size. And depending on the OS or software used, doing so might just break things or make your system less secure by placing it in an untested state. An OS running in a completely untested state must be assumed to have unknown regressions and security vulnerabilities. And if anyone doesn't believe what I've written about Microsoft operating systems, simply check Technet or ask them. They are completely open and forthright about it. Scott