Unblock an IP address from admin settings page

[BornToBeRoot]

Add a feature to unblock an ip-address from the admin settings page.

This method is far too cumbersome:
DELETE FROM oc_bruteforce_attempts WHERE ip = 'x.x.x.x';

[nickvergessen]

Maybe also via an occ command, as requested in nextcloud/server#3058

[mark-orion]

I fully support this. Please at least an occ command ASAP. People will start disabling a security feature if it is not easily to manage.

[MarkusH1975]

Please add this feature to the website, I have it running on some web space where I do not have shell access.
It should be possible to list all entries in the table and delete them item by item or just everything.
Thanks.

[MarkusH1975]

Hi,
I had again problems.
Please add a feature (show) DELETE ALL entries in oc_bruteforce_attempts.
It should work for SQLite and MySQL databases.

Thanks

[MorrisJobke]

It will be deleted on login now for that username and IP address.

[MorrisJobke]

It will be deleted on login now for that username and IP address.

See nextcloud/server#7263

[MarkusH1975]

In which release is this included ?
I have seen this issue in Nextcloud 13.0.0.

[MorrisJobke]

In which release is this included ?
I have seen this issue in Nextcloud 13.0.0.

13.0.0 - it clears the brute force logins for the combination of username and IP. So you need to login from the same machine with the same user to remove those entries.

[linucksrox]

I think that makes sense to reset the brute force attempts after successfully logging in, but in my opinion there should also be a way to do this from the occ command and from the admin interface.

The biggest problem I see with the above approach (reset after successful login) is that once you type the correct password, you still have to wait through the long delay, which in some cases it can cause timeout errors. How can you successfully log in if you get a gateway timeout?

[MorrisJobke]

How can you successfully log in if you get a gateway timeout?

You then should fix the gateway to know that there could be up to 30 seconds of delays.

[linucksrox]

Thanks @MorrisJobke, that makes sense. I didn't realize there was a maximum timeout of only 30 seconds. Actually according to https://nextcloud.com/blog/security-in-nextcloud-12-bruteforce-protection-and-rate-limiting-for-developers/ it says the timeout can go up to 60 seconds, which is still reasonable.

I just wonder if it makes sense to check the password first, then skip the timeout if it is successful. Brute force throttling only needs to happen when the password is incorrect I think. Would that be possible?

It's just that if the only way to reset is by asking the user to type in the right password, but they might potentially have to wait 60 seconds, that can be frustrating for them and if they mistype that one, we're in trouble.

Either way, are you still planning on implementing an alternative method of resetting this such as occ or in the interface?

[MorrisJobke]

I just wonder if it makes sense to check the password first, then skip the timeout if it is successful. Brute force throttling only needs to happen when the password is incorrect I think. Would that be possible?

This would then make the throttling useless. 😉 Because then the attacker only needs to wait a few seconds and knows if the password was correct and then could skip this request and go on to the next one.

[MorrisJobke]

Either way, are you still planning on implementing an alternative method of resetting this such as occ or in the interface?

Plans: yes, on the roadmap: not yet. And the entries are also only stored for 24 hours.

It's just that if the only way to reset is by asking the user to type in the right password, but they might potentially have to wait 60 seconds, that can be frustrating for them and if they mistype that one, we're in trouble.

A information will be shown in Nextcloud 14 for wait times over 5 seconds on the login screen.

[MorrisJobke]

Plans: yes, on the roadmap: not yet. And the entries are also only stored for 24 hours.

Just to have this more specific: plans: this ticket and nextcloud/server#3058

[linucksrox]

This would then make the throttling useless. 😉 Because then the attacker only needs to wait a few seconds and knows if the password was correct and then could skip this request and go on to the next one.

Maybe I don't understand the logic correctly. I imagine the current logic is like this:

user types credentials and tries to log in
if (ip address exists in brute force table) then {
    sleep for a while
}
validate credentials
if (credentials are valid) then {
    log user in
}
else {
    show wrong credentials message
}

I'm suggesting we change that to this:

user types credentials and tries to log in
validate credentials
if (credentials are valid) then {
    log user in immediately
}
else {
    if (ip address exists in brute force table) then sleep for a while
    show wrong credentials message
}

When the credentials are incorrect, there is still a delay, effectively slowing down brute force attacks. At the point where the credentials are valid, there is no way to differentiate between the actual user and the attacker, so there's no reason to make them wait if the credentials are valid. I don't see any downside to this method.

If I'm wrong in my log, can you please elaborate?

[BornToBeRoot]

@linucksrox This would bypass the entire protection.

Your logic as an example with a web browser:

Open multiple tabs with the nextcloud login page... type in every tab other credentials... if one tab has the right credentials, you are logged in with no delay...

You have to check the ip first... if there are failed logins in the brute force table... delay the login...

What would happen if there are thousands of login attempts? You have no delay... and thus no protection.

Edit:

And if an attacker knows that a successful login takes for example 1 second and a failed one 30 seconds. He can cancel threads which last longer than for exampe 3 seconds... Thus, he would be 10 times faster than without brute force protection.

In the first/current case, every login (successful or not) would take 30 seconds (if there are failed logins in the brute force table...)...

[linucksrox]

Thanks @BornToBeRoot, that clears it up for me 👍
So bypassing the delay with successful credentials negates the whole thing because the attacker should have to wait the full amount of time for every attempt whether it's correct or not.
Also I hadn't thought about the multiple tabs approach.

[melyux]

Is there a way to do this yet? An Android app glitch caused a ton of incorrect logins, and now all access from my client IP is super slow despite ultimately successfully logging in. Interestingly though, only slow from the iPhone app, and not the browser.

[linucksrox]

@melikyuksel If you're using version 13 or later it should automatically reset the throttling once you log in successfully. If not, you can check in the database and manually delete the IP address(es) that it's throttling (as stated in the first post here):
DELETE FROM oc_bruteforce_attempts WHERE ip = 'x.x.x.x';

[melyux]

@linucksrox Thanks! Looks like the auto reset upon login mechanism isn’t working even on version 16. I enabled the Brute force settings and added the IP ago the whitelist. Unfortunately it’s a dynamic IP, so I’ll do the command.

[joshtrichards]

An occ command was implemented in nextcloud/server#20005

If someone wishes to try their hand at implementing this in the Web UI (i.e. via this app), the implementation:

• can be modeled after the existing occ security:bruteforce:reset command
• that implementation is found in https://github.com/nextcloud/server/blob/master/core/Command/Security/BruteforceResetAttempts.php

The UI elements needed:

• enter an IP address and confirm it's a reasonable IP address
  • can be modeled after existing whitelist UI implementation
• confirmation message when attempts have been reset in the db