Comment by ghshephard
12 hours ago
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
IPv4 Target: 192.168.0.1
IPv6 Target: 2001:1868:209:FFFD:0013:50FF:FE12:3456
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
FDC2:1045:3216:0001:0013:50FF:FE12:3456
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
No, that's the whole point.
Imagine I've shared output of "ifconfig" on my machine, or "netstat" output, or logs for some network service which listed local addresses.
For IPv4, this will is totally fine and leaks minimal information. For IPv6, it'll be a global, routable address.
That's a pretty weird threat model. Like, yeah commands you run on your machine can expose information about that machine.
2 replies →
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hardest to attack:
fcab:cdef:1234:5678:9abc:def0:1234:5678
The whole point is that your devices on the inside of your network can't be routed to at all.
1 reply →
It took me less than 1 second to access that 192.168.0.1 address! It wasn't that hard to find.
(;-)
Fast, too, isn't it? Must be on at least a 1Gbps connection.
Deeply ironic that Cisco would teach this, because it's the opposite of what they said when they introduced NAT.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
1 reply →
If the IP address was leaked, wouldn't it be the address of the unit doing the NAT translation instead of the standard-gateway?
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
> You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
TIL that IPv6 is a cryptosystem
You can use Shannon's maxim instead if you're going to be deliberately obtuse. The point is true for any system intended to be secure, and a network is such a system, as is the security software such as the claimed NAT software.
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?