← Back to context

Comment by zamadatix

13 hours ago

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:

  Hard to attack:   FDC2:1045:3216:0001:0013:50FF:FE12:3456
  Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456

  • > 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.

    When using the stateful firewall provided by Linux's packet filter, the IPv6 NAT "masquerade" works very similar to IPv4 NAT. 1:1 mapping is NOT required.

    For example internal hosts are configured as follows:

    inet6 fd00::200/64 scope global noprefixroute

    ip -6 route add default via fd00::1

  • 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.