Some more control and visibility

[MariusBluem]

Some ideas:

• IP blacklist (...also showing IPs that are currently blocked with a countdown)
• Edit the time an IP is blocked
• Edit the attempts a user can do without being blocked

...very eccentric wishes would be 😜

• make it possible to disable brute-force protection at all? [implemented; see config.php.sample / Admin Manual]
• define those settings per group/user

What do you think? @rullzer @LukasReschke

[ghost]

Hi!

I miss the ability to edit these settings too. I like Wrodpress Loginizer-plugin abilities very much and think that functionality could fit perfectly in this project.

Reset Retries - How long the attempts should be stored in database. Email Notification - Send an email to the cloud admin/user (opinions?) after X number of short time lockouts per user/IP-address (opinions?).

EDIT:

A list of failed attempts could also be added to the settings page, the table could also be used to provide the functions @MariusBluem mentioned above.

[e-alfred]

Maybe another feature could be a warning shown to certain admins (maybe also selected users) after logging into the web interface if a lot of brute force attacks were logged (alongside sending mails).

[Luto73]

country blocking would be great, too

[ymolinet]

It could be usefull to add a comment field on a whitelist entry.

[MariusBluem]

country blocking would be great, too

This has nothing to do with brute-force protection, and should be done in a separate app ;)

[MariusBluem]

It could be usefull to add a comment field on a whitelist entry.

This is a seperate request ;)

[nursoda]

It seems that the app blocks SUCCESSFUL login 'attempts' also. If so, these should NEVER be counted.

Anyway: I spent a whole day chasing down why on ONE of my instances, I could not Sync using the PC client while everything else worked fine. Turned out it was this app. Deactivated -> all back to normal.

So when it comes to SETTINGS, there may also be a DISPLAY neccessary: Some info THAT certain IPs were blocked and why (a login counter maybe?).

[e-alfred]

@nursoda Exactly. All blocked attempts should be logged and then be viewable in the admin settings just like the general log view. This would make the admin aware of brute force attempts if he wants to audit the log as well as for looking into errors. It would be really bad if a legitimate client can't connect because it got blocked but it is nowhere visible to the admin.

As a bonus, having a dedicated log that could be sent to a log management system (Graylog or Splunk, for example) would make auditing/alerting/troubleshooting a lot easier for the operators.

[DanScharon]

I'd also be happy about a setting whether to only register failed logins as bruteforce attempts. Currently you only need a handful of users who click on an expired link and their IP range gets on the naughty list and blocked real fast

[joshtrichards]

It seems that the app blocks SUCCESSFUL login 'attempts' also. If so, these should NEVER be counted.

@nursoda This was a note from you awhile ago, but at least today the only login attempts that get registered are invalid ones. If you see evidence otherwise, please create a dedicated Issue so it can be looked into.

All blocked attempts should be logged and then be viewable in the admin settings just like the general log view. This would make the admin aware of brute force attempts if he wants to audit the log as well as for looking into errors. It would be really bad if a legitimate client can't connect because it got blocked but it is nowhere visible to the admin.

@e-alfred: Listing all invalid login attempt records in the UI would be challenging since you could be talking about a nearly infinite quantity of attempt records/IP addresses, but with #560 we'll add the ability to look up the status of a specified IP address (in the same way as is now already supported via the occ security:bruteforce:attempts command).

All registered (invalid) attempts are logged at the NOTICE level by the BFP implementation. Also, outside of BFP, invalid login attempts are additionally logged by Nextcloud Server at the WARNING level.

If someone wants to create a dedicated Issue to explore/discuss some design/implementation ideas for a feature where the attempt records table can be arbitrary scrolled through that's fine, but I'll let someone that really wants that feature create a dedicated issue for it. :-)

As a bonus, having a dedicated log that could be sent to a log management system (Graylog or Splunk, for example) would make auditing/alerting/troubleshooting a lot easier for the operators.

If the existing NOTICE (and WARNING) level logs aren't sufficient, feel free to create a dedicated issue so we can drill down into what's missing/what's needed.

Currently you only need a handful of users who click on an expired link and their IP range gets on the naughty list and blocked real fast

@DanScharon I've created a dedicated issue for your comment: #562