Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…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 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.
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.
That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.
If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)
Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.
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.
If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.
Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
Unlike the other poster, I'm not going to blame you for getting things wrong. It happens, we all were learning at one point. But I do think it's incredibly unreasonable to use a mistake you made as an argument against IPv6. This would be like if I rm -rf'ed my Linux box into oblivion when I was first learning and then avoided Linux after that because I had bad vibes about it. Sometimes you need to accept the L and not blame the tools.
