Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 connection limit too relaxed #15

Open
amyavi opened this issue Dec 19, 2024 · 3 comments
Open

IPv6 connection limit too relaxed #15

amyavi opened this issue Dec 19, 2024 · 3 comments

Comments

@amyavi
Copy link
Contributor

amyavi commented Dec 19, 2024

The current IPv6 connlimit mask is /64, which is typically what is given out to customers by ISPs.

Unfortunately, it's way too easy to easy to obtain bigger ranges, for example with HE's TunnelBroker which gives out IPv6 /48 blocks completly for free. That is 65 thousand /64 addresses, meaning 65 thousand possible bots connecting to the server.

Limiting by the /48 or /56 range entirely is not a very good idea either, as it's pretty likely that ISPs will assign multiple customers IPs that both fall in the same /56 range.
I suggest that the connection limits for IPv6 be set up in the following way:
/48 - max. 15 connections; /56 - max. 10 connections; /64 - max. 5 connections.

I have not seen this actually be abused yet, however it's very likely that kaboomserver/server#147 was caused by someone exploiting this to spambot the server.

@86dd
Copy link

86dd commented Dec 19, 2024

I believe a /48 or /56 is simply too large, as a /64 roughly corresponds to a /32 in IPv4 and /64 is also the only size that works with SLAAC.
The typical delegation from ISPs is ranging from a single /64, to possibly a /60 or a /56 and in very rare cases up to a /48, but most home routers only use two /64s: one for home, one for guest WiFi, and most don't even let you set custom routes. (Yes, even when you use a Tunnelbroker instead of DHCPv6 they don't let you do more!) There is simply too much variation in ISPs.
Also, most hosters only route you a /64 or even less (many only one single /128 in a /64 shared with other customers) and I believe that would cause too many issues, for example on Linode or Digital Ocean (where they give each Droplet a /120 on link, I have only seen extremely few hosters (like one or two) that give you more. Usually they'd also then simply tell you to do BGP sessions with them, usually for a fee.
Enough hosters I've seen also put a whole lot of servers on the same /64.
Also, HE TunnelBroker requires a public IPv4 address and setup is more complex.
I don't think 99% of people would go to those lengths to bot the server using IPv6, they would probably just download a free IPv4 proxy list or abuse tor. Most people simply don't care about IPv6, especially not in Minecraft which has broken DualStack and MultiHoming support (thanks Mojang!)

@86dd
Copy link

86dd commented Dec 19, 2024

Also, I believe that the same has happend on IPv4 what was described in kaboomserver/server#147 but has simply gone unreported by Hetzner for the following reason:
For IPv4 NAT, the framework uses 192.168.0.0 which is clearly a private range and thus most likely not monitored by hetzner and blindly discarded.
However, 2001:db8:: is a documentation prefix and is in 2000::/3, the range for Global Unique Addressing. I think Hetzner might have been lazy and decided to monitor the whole 2000::/3 without adding an exemption for 2001:db8::/32.
The changes to the firewall I'm working on would already prevent a lock-down of the server in the future and I just don't think it is a good idea or even necessary to change it even lower. (It used to be /32, which is usually a whole ISP)

@amyavi
Copy link
Contributor Author

amyavi commented Dec 19, 2024

I believe a /48 or /56 is simply too large, as a /64 roughly corresponds to a /32 in IPv4 and /64 is also the only size that works with SLAAC.

Which is why I suggested the use of separate connection limits for each range, as to not prevent potential players that are on the same subnet as someone who's botting the server from joining.


Anyways, I fully believe that the amount of IPv6 packets sent out was due to a spambot using a large IPv6 range to attack the server, as only a few minutes before the timestamps in the Hetzner report, a large amount of spambots joined Kaboom:
image
(my timezone is UTC-3, so this is around 2024-10-06 22:57 UTC)

Also, the report from Hetzner suggests that there were at least 640 connections open to the minecraft server at the same time, which is highly unusual, especially for IPv6 since Minecraft prefers IPv4 over v6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants