[170190] in North American Network Operators' Group
Re: misunderstanding scale
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 24 21:53:32 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAN3um4zthUtBizdDBozwPtuw7e1_MWFQQUjwtGTCPnZ4U7tnpw@mail.gmail.com>
Date: Mon, 24 Mar 2014 18:41:03 -0700
To: Mike Hale <eyeronic.design@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> "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.
If that were true, yes. The reality is that to make that a true =
statement,
you would have to modify it to:
=93If I specifically disable IPv6 on every single one of my hosts well =
enough
that a compromised host cannot have IPv6 turned back on, the attacker
can yammer away via IPv6 all day long with no result.=94
Best of luck achieving that with any operating system newer than, say,
Windows ME.
> "And if an enterprise doesn't have firewalls in place, then their
> devices are already accessible."
> For those devices that have publicly routable IP addresses, sure.
Even for those that do not. It=92s actually not that hard to craft a =
sequence
of packets that can get past a NAT if you have even one compromised
host somewhere behind the NAT.
> "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.
It=92s a little more work, but it doesn=92t have to be a lot more work =
to achieve
roughly the same security posture in IPv6 that you have in IPv4.
It is, actually, a fairly easy step up in most cases. A little bit of a =
learning
curve, but otherwise, most of the mitigation strategies are very similar =
and
take about the same amount of effort. The difference comes from the fact
that you=92re facing all of the IPv6 stuff at once where you built the =
IPv4
mitigations over many years as vulnerabilities were discovered.
> "Simply pretending that if you don't enable IPv6, you're somehow
> immune from IPv6 threats is na=EFve."
> 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.
Is it so thoroughly turned off that a compromised host can=92t modprobe =
it back on?
If not, then absolutely immune is an interesting statement.
Are you sure you have done that on every single host that has any =
ability whatsoever
to get onto your network, including whatever laptop a vendor might bring =
into a wireless
network or conference room? Whatever networks service technicians might =
plug their
devices into? etc.?
You can=92t just not turn on IPv6=85 You have to actively turn it off on =
absolutely every single
device everywhere in order to achieve what you claim.
> Everything you've said is correct. But my point is simply that there
> *are* security considerations when deploying v6, and they're bigger
> than some rare and esoteric bug that's only exploitable when all the
> stars align. With v6, a simple misconfiguration can open up every
> single host directly to the outside. The same simply isn't true with
> NAT where you have to explicitly define inbound rules.
It is, actually=85 You don=92t have to explicitly define inbound rules =
to open up
all the hosts. True, the attacker doesn=92t have quite the easy ability =
to target
each host specifically, but there are lots of ways to attack hosts =
behind a NAT
that happen to be kind enough to initiate outbound sessions. With many =
firewalls,
there are even ways to exploit interesting artifacts of the way certain =
=93savings=94
are implemented in the NAT table process that allow you to create =
sessions that
don=92t exactly match the outbound traffic.
Owen
