Forgive me if I omit all the system info since this is more of a general config question.
Recently, the rate limiting was triggered while a user was uploading to a public link. I would like to have rate limiting in place for the login page and other public API endpoints by default but I would like my users to be able to upload and download large numbers of files to public links without being rate-limited.
This problem doesn’t happen frequently and it is quite hard to test, so I would appreciate some config advice before I start tweaking.
I see the ratelimit_overwrite config parameter might be relevant, but I’m not too sure which route to modify for all public links (if it is indeed possible). Would it be the routes in the category files_sharing.externalshares?
If anyone has any examples of configs that are a bit more sophisticated than the one in the docs here, I would very appreciate seeing them.
Thank you! Yes, I did end up whitelisting and resetting an IP recently. However, I was hoping for a way to prevent the problem for the next time. Often, by the time I can get into the logs and react to a problem, it’s already too late.
Hmm. That surprises me a bit. The rate limit should be triggered if a user authenticates incorrectly multiple times (password or token), not for uploads or downloads.
Unless I am misunderstanding something. From documentation:
The brute force protection feature is meant to protect Nextcloud servers from attempts to guess passwords and tokens in various ways. Besides the obvious “let’s try a big list of commonly used passwords” attack, it also makes it harder to use slightly more sophisticated attacks via the reset password page or trying to find app password tokens. It is used throughout the Nextcloud ecosystem, including by other apps, if they have sensitive entrypoints (and choose to enable support for it).
Could it be that the affected user or another user on the same network has set up an Nextcloud client (or contacts or calendar client) with an old/invalid user/password? This would leads to repeated incorrect login attempts.
Are you sure that a public IP address was blocked? If it is a private one (e.g., that of the front proxy), then something in your Nextcloud is configured incorrectly.
Is Nextcloud also protected by BasicAuth or another additional security measure? This sometimes leads to strange effects, as the login is passed on, but then a login does not work because the access login is different.
Can you see the reasons for the block in your nextcloud.log?
Thanks for your help. Indeed it surprised me as well as I expected Brute Force Protection to apply to places where you can enter passwords. Rate limiting for public links makes sense if the link if very public and you want to prevent DOS attacks, but our public links are short term and limited to one or two people so I am happy to turn off rate limiting for public links, as long as I can keep the brute force protection for passwords.
The logs do not show login attempts from the same IP.
Yes. The IP did not fall in any of the private ranges.
Just by fail2ban, firewall, etc. but nothing at the Nextcloud application level.
The logs show many entries like:
IP address throttled because it reached the attempts limit in the last 12 hours [action: public_dav_auth, attempts: 109, ip: ##]
and
Bruteforce attempt from "##" detected for action "public_dav_auth".
The URL in the logs is show as /public.php/dav/files/####/.
By contrast, I do see some Bruteforce attempt logs from unknown IPs to the URL /login, which I presume are malicious. So I am happy to have the bruteforce protection working for the login page.
So, no one has tried the ratelimit_overwrite config?
I did a little more research. Apparently, the rate limit also triggers if you call up a lot of invalid shares. Which makes sense, so that you can’t brute force the share URLs.
/**
* Overwrite the individual rate limit for a specific route
*
* From time to time it can be necessary to extend the rate limit of a specific route,
* depending on your usage pattern or when you script some actions.
* Instead of completely disabling the rate limit or excluding an IP address from the
* rate limit, the following config allows to overwrite the rate limit duration and period.
*
* The first level key is the name of the route. You can find the route name from a URL
* using the ``occ router:list`` command of your server.
*
* You can also specify different limits for logged-in users with the ``user`` key
* and not-logged-in users with the ``anon`` key. However, if there is no specific ``user`` limit,
* the ``anon`` limit is also applied for logged-in users.
*
* Defaults to empty array ``[]``
*/
'ratelimit_overwrite' => [
'profile.profilepage.index' => [
'user' => ['limit' => 300, 'period' => 3600],
'anon' => ['limit' => 1, 'period' => 300],
]
],
Shares are under /s/, so I would search for that with occ router:list:
$ php occ router:list | grep '/s/'
| files_sharing.publicpreview.directlink | GET | /s/{token}/preview |
| files_sharing.share.authenticate | POST | /s/{token}/authenticate/{redirect} |
| files_sharing.share.downloadshare | GET | /s/{token}/download/{filename} |
| files_sharing.share.showauthenticate | GET | /s/{token}/authenticate/{redirect} |
| files_sharing.share.showshare | GET | /s/{token} |
