Comment by alanfranz
10 hours ago
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
> I don’t have any idea how they got the ip,
You might've been using DHCPv6 assigning sequential addresses starting at 1?
Remember: friends don't let friends use DHCPv6[*]. Help out, uninstall DHCPv6 today.
[*] in IA_NA mode (address assignment). PD and stateless info-only are fine.
More useless crap to remember for a useless protocol.
Another possible explanation is that the IP was not random enough. For example: network_prefix::1
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.
Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.
I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.
My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.
I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.
Unfortunately I think one of the problems with v6 is people are just unable to apply intuition to numbers this big. The minimum number of /64s an ISP will have is around 4 billion. They generally give subscribers a /56 which is 256 /64s. It's all simple power-of-2 arithmetic. Computer people used to get how big 2^64 is.
1 reply →
Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.
There was a report a few years back about people running NTP servers to harvest IPv6 addresses.
Security via obscurity will only get you so far.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
It's a pain in the ass to configure the /128 setup, particularly when your ISP can change your /64 at any point in time.
1 reply →