Limit login to IP range

[tuxArg]

I know that this was already discussed, like here for admin panel access: #5954 and the solution was to resolve this with a reverse proxy filter.

This is a different feature request because it can't be solved with a reverse proxy filter.

I want to allow logins/signups only from allowed IP ranges but allow external access for already logged in users. Looking at the logs I can see that when a user logins it make a request to /identity/accounts/prelogin and probably all /identity/accounts/ could be blocked from external IP to limit new logins and signups.

But the endpoint /identity/connect/token is constantly accessed by already logged in users and could not be blocked. The problem is that this endpoint allows making a login right there too! See https://github.com/dani-garcia/vaultwarden/blob/main/src/api/identity.rs#L47
So, restricting access only to /identity/accounts/ is useless.

I can see that all login methods "password", "client_credentials" and "authorization_code" finally call check_limit_login for rate limiting. This isn't called when "refresh_token" is needed, I think that's ok. So, to limit logins to some IP we should only change check_limit_login to check if IP is in a valid range, that would require a new config variable like LOGIN_ALLOWED_IP_RANGES.

This can also be done if there was a whitelist for login rate limits, like LOGIN_RATELIMIT_WHITELIST, so that we can allow some IP ranges there and block all others setting LOGIN_RATELIMIT_MAX_BURST=0.

[kpfleming]

I want to allow logins/signups only from allowed IP ranges but allow external access for already logged in users.

Are you sure you want that? This means that an already-logged-in user who gets logged out for reasons outside of their control (for example a mobile app version upgrade) who isn't connected to the 'blessed' network won't be able to log in again, and will not have access to their vault contents.

[tuxArg]

Yes! I want exactly that. I want to force them to use the vpn if they need to login again. And looking at the logs it doesn't happen so frequently.

[BlackDex]

From my point of view that is more an item for a reverse proxy than Vaultwarden.

[tuxArg]

From my point of view that is more an item for a reverse proxy than Vaultwarden.

It would have been if the endpoint is only used for logins. But it's also used to "refresh" the session.
In theory a reverse proxy could read post data and filter POST requests where grant_type=refresh_token and do some special filtering, but that's not the right way to do this.

The same could be said about rate limiting by ip, already implemented in vaultwarden because it couldn't be done effectively on the reverse proxy.

[BlackDex]

Well, I think it can be done effectively on a reverse proxy though, depending on the reverse proxy of course.

But, I'm not really feeling a feature like this. Why make a difference in refreshing and login. That only makes it complex and complicated during troubleshooting.

[tuxArg]

Well, I don't really know the difference between each other. But. this distinction is already done because "refresh" isn't being rate limited now, so it's already seen as something that could be safely brute forced.

[sichkarmg]

This can be implemented using nginx + fail2ban

[tuxArg]

This can be implemented using nginx + fail2ban

No, it can't.
fail2ban would allow at least one failed attempt and would block all access to the host:port, even if a user is logged in or need access to some other service.
nginx alone: Yes, it's (in theory) possible but that would require reading the POST data, and doing some filtering. Possible yes, not the right way to do this. The standard way to filter post requests depending on field values isn't on the reverse proxy that usually only needs to forward request.