Now that bruteforce protection is enabled by default I was wondering if it is IPv6 ready (aka not blocking a single IP but a /56 subnet).
Fail2ban isn’t, that is why I suspect that this app also is not?
It’s been enabled by default for about a decade. 
Just to clarify: The only change in v30 is the settings app for managing it is enabled by default too. Previously the BFP settings app was merely shipped (bundled with Server installation), but left disabled.
I was wondering if it is IPv6 ready (aka not blocking a single IP but a /56 subnet).
Yes. It blocks based on the /64.
1 Like
Would it not be better to block /56?
I am getting /48 from my ISP. In combination with let’s say 5 attempts, that is 325 000 passwords attempts.
Probably nothing for a good password policy but still.
I was worried you’d ask that. Hah. There isn’t a perfect answer. Possibly.
https://labs.apnic.net/index.php/2024/04/24/ipv6-prefix-lengths/
Let’s assume for a second, that we set the default to /56.
What would change for which user group, based on what ISP they have?
For good ISPs that hand you out a /48, there is no collateral damage possible.
Only (small) con is that the attack size is 256 higher than it needs to be (/56 instead of /48).
This could be solved by offering the option to block /48 instead in the GUI.
For normal ISPs that hand you out a /56, there is no collateral damage possible.
There are no cons compared to blocking /64.
For bad ISPs that hand you out a /64, there is no upside.
Only con is that you could suffer collateral damage, IF the attacker uses the same ISP AND is in the same /56 subnet.
| ISP | prefix | pros | cons |
|---|---|---|---|
| good ISP | 48 | no collateral damage possible | 256 times too big |
| normal ISP | 56 | no collateral damage possible | - |
| bad ISP | 64 | - | theoretical chance of collateral damage |
TLDR:
I see no reason to why we should not block by default /56 prefixes. Am I missing something?
If you have one client in your company network triggering the bruteforce detection, you will block everybody on that network sector. And it might be enough that someone deletes by accident an app password, or changes to 2FA.
Not sure about your classification about good and bad ISPs. There is just the minimal recommended network size of /64 for ipv6. Not sure why they give you more, perhaps if you want a separate guest network. And you might have ISPs for home users, VPN providers, server/cloud services that give you “just” a /64, and you risk collateral damage for all these users.
2 Likes
Agree, but this is also true if you only block a /64.
By that logic we should not even block /64 but a single IPv6.
But then an attacker like me with /48 would have 1,208,925,819,614,629,174,706,176 IPs to attack from.
The minimum recommended network size is indeed /64 for SLAAC reasons.
But the by RIPE recommended prefix size is /48.
/64 is bad, because then a user can’t even have two VLANs with two /64.
/56 ISP is a made up “default” to upsell /48 to business users.
But there is no technical reason for it.
That is why a good, honest ISP will give you a /48.
A greedy or overly cautions ISP will give you a /56.
A bad ISP will give you a /64.
I don’t know the distribution of good/bad ISPs per country, just two points:
- the Nextcloud hoster gives you a /64. If you don’t block logins linked with a user, and do a hard block via fail2ban, then someone can prevent you from connecting to the Nextcloud servers (apps, updates)
- mobile connections, do they give you more than a /64?
I wouldn’t rely too much on this feature, if attackers already consider changing the subnets, they’ll likely go further. 2FA and stuff like that can help, so just by guessing, you cannot login.
It does not matter on what prefix size Nextcloud is hosted on.*
It only matters what prefix size the attacker has.
Mobile connections probably don’t give you more than /64, but should that be a reason to compromise on security?
If we apply the same logic, should we should not ban IPv4 /32, since mobile connections most likely give you a shared CG-NAT IPv4?
The perfect but probably not as easy to implement feature would be to expand the prefix ban step by step.
*if you know that you only will access your Nextcloud instanced from your /48 internet access, then you can set the blocking to /48 without fearing collateral damage.
Sorry, this got a little bit out of hand and was overly complex.
I rewrote the github issue. Hopefully this makes my reasoning for /56 clearer.