misunderstanding scale

Mon Mar 24 02:38:00 UTC 2014

On Mar 23, 2014 8:44 PM, "Mike Hale" <eyeronic.design at 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