Delete IP from oc_bruteforce_attempts via occ command

[guddl]

At the moment you have to delete an IP address which was blocked by a brute-force-detection via an SQL command on the database.

https://help.nextcloud.com/t/how-can-i-unblock-an-ip-blocked-through-brute-force-detection/5731

It would be nice to to this via an "occ" command.

[nickvergessen]

I think it makes sense

[LukasReschke]

Works for me. :)

[aweinert]

Would it make sense to allow deleting an IP from this table via the admin-panel?

[LittleNo]

since the brute force protection is not working properly for all users (for example NATted networks are a big problem) this feature definately should be there

[nickvergessen]

Maybe this could be part of the app that was developed around bruteforce protection already:
nextcloud/bruteforcesettings#9

[MorrisJobke]

Another approach to relax the situation here: #6376 #3156

[MorrisJobke]

I meant #3156

[Wikinaut]

Any progress here ?
It would be nice to to this via an "occ" command.

[Wikinaut]

ping @jospoortvliet as discussed publically after your 36c3 talk. I regard a final solution of this issue as easy and as important.

[kesselb]

Would you mind to share your use case? The throttling is only for a certain ip address. This is only a issue for nat or your reverse proxy configuration is invalid (nextcloud do not see the correct ip).

server/lib/private/Security/Bruteforce/Throttler.php

Lines 256 to 274 in 5bf3d1b

	public function resetDelay($ip, $action, $metadata) {
	$ipAddress = new IpAddress($ip);
	if ($this->isIPWhitelisted((string)$ipAddress)) {
	return;
	}
	$cutoffTime = (new \DateTime())
	->sub($this->getCutoff(43200))
	->getTimestamp();
	$qb = $this->db->getQueryBuilder();
	$qb->delete('bruteforce_attempts')
	->where($qb->expr()->gt('occurred', $qb->createNamedParameter($cutoffTime)))
	->andWhere($qb->expr()->eq('subnet', $qb->createNamedParameter($ipAddress->getSubnet())))
	->andWhere($qb->expr()->eq('action', $qb->createNamedParameter($action)))
	->andWhere($qb->expr()->eq('metadata', $qb->createNamedParameter(json_encode($metadata))));
	$qb->execute();
	}

If anyone want's to submit a patch. You can reuse some of the code from there. Happy coding ☕

[Wikinaut]

@kesselb use case? Very stupid simple use case: Nextcloud on a rented server. User/s try to hack a password, get blocked by the mechanism. Same happens, if your clients (not using the dedicated token method but password) use the wrong password - because user had changed that on via the web interface--- so there are many use cases.

As an admin I wish to have a plugin or admin setting which allows to safely delete specific or all blocked IP from the table.

[kesselb]

Very stupid simple use case: Nextcloud on a rented server. User/s try to hack a password, get blocked by the mechanism.

So? Their IP address is blocked. You can still login.

[Wikinaut]

No. my own IP address is blocked, because my own other devices, in the same network and coming with the same IP to the server - when connected via username/password, not with token - were using the old (wrong) password.

It took me a long time to figure out, what the problem was.

You do really not understand the problem, whereas @jospoortvliet does. Please ask him.

[kesselb]

You do really not understand the problem, whereas @jospoortvliet does.

That's rude. Please use a more polite language the next time. Anyway I do understand the problem. Probably someone will pick it up. I don't see a strong urge to implement such a feature.

Please refrain from asking for progress. 👍 the issue and subscribe for updates is enough.

[joeried]

I would like to take a look at this issue.
What would be the correct namespace of such a occ command? 'security:bruteforceattemps:reset-for-ip'?

@kesselb You quoted code that can be reused. My first thought would be to extend the resetDelay function so that:

• metadata and action are optional arguments
• another optional argument exists, which switches whether the given IP or the whole subnet of the given IP is used/unblocked

Does that make sense?

[kesselb]

Cool 👍

I think that's much additional complexity for this method.

As start you might write a command to delete a single IP from the list. We can always extend later. Probably not bad to also write a command that lists the current blocks (if there is no such command yet).

[joeried]

It would increase complexity, but on the other hand a new method would be relatively similar to the existing one.
The querry to delete the attemps for one IP would need one different where condition ('ip' instead of 'subnet') and omit two other where conditions
With my proposal I actually wanted to delete only one IP. The proposed flag for switching between subnet and ip would have been needed at this point to switch the where condition from 'subnet' (current usage) to 'ip' (usage for this case).

But I also understand your argument and that was also one of the reasons why I wanted to ask.