Brute force protection, how to debug

my nextbox gets some requets trying to brute force passwords. I know, because normal login via web is delayd 30 seconds…for myself as well. Looks like the gateway ip is banned (the one!)…but how can I debug this?

Found: Brute force protection — Nextcloud latest Administration Manual latest documentation

Before I log in via SSH, trying to mysql into my nextcloud db: is there no other way than having a look directly via mysql?! (i.e. a GUI, in the nextcloud web interface?).

thanks for any pointers.

hey @benzkji,

sounds legit, I guess the gateway/router can be translated to “load balancer” within the context of Nextcloud’s brute-force documentation, therefore your router will be flagged as brute-force source.

One possible solution (please understand before applying) is to whitelist IPs. You can do this in: settings/admin/security if you have the brute-force settings app installed. But do not add your gateway there, this will essentially disable brute-force detection for your NextBox, just your local machines’ IPs make sense to add here, as specific as possible.

Further Nextcloud has a mechanism to handle IPs as “proxy”, thus not count these as sources, but try to use the hop before (although I am not totally aware of how this exactly works). The backwards-proxy configuration uses this like that inside the nextcloud config:

    'trusted_proxies' => 
      array (
        0 => '',
      ), is then to be replaced with your gateway IP. I’ve not tried this and can’t really tell if it will solve your issue. Keep in mind that this will be overwritten, if you activate the backwards proxy…

Last but not least, if your current solution is logging in via ssh, you might also automate this via a single ssh command like this:

ssh nextuser@ docker exec nextbox-compose_db_1 -- \
 mysql -u root -p yourmysqlpass nextcloud -e \
 'DELETE FROM bruteforce_attempts WHERE <some-identifcation-for-row>'

But on the other side, this implies your are logging in from a LAN IP, then you could also simply whitelist this IP, guess this should help (if the whitelist works as I expect currently).


feel free to share what helped best,

1 Like

thanks, with your docker pointers, I was able to find out the mysql password, and finally watch the brutoforce table.

  • login from a local LAN computers still logs the gateway’s IP, not my real one - traffic passes interwebs here??
  • after a few minutes/seconds, I already got a new failed login. from the gateway, obviously. I’m not sure if it is myself (username matches), because of a misconfigured client somewhere.
  • will check proxy setting, this should help I guess (at least for further debugging :wink:

to better understand things.

…to change trusted_proxies, I’ll need to ssh login, then do sudo -i, then do docker exec -t -i nextbox-compose_app_1 /bin/bash, then install vim (or vim-light or whatever) via apt, then edit the config/config.php file, directly in the container.

besides: as far as I can tell, every nextbox user that is not using the backwards proxy solution is affected by this scenario, no? maybe a general solution via nextbox app would be helpful?

nope it doesn’t go through the internetz, this is just how IPv4 works:

[PC] -> [router] -> [nextbox]
  • PC asks for IP(v4) for this IP is your router's WAN IP
  • on the router port-forwarding will forward the request to your NextBox
  • that’s likely the reason why Nextcloud identifies requests to come from

if your PC is inside your LAN the same path is used, but only from your LAN to your router, despite the DNS-request no data leaves your LAN in this situation (best case not even the DNS request, as this will mostly be cached)

Nope, this is not necessary, just install vim on your host system (nextbox), you can find the configuration for nextcloud here: /srv/nextcloud/config/config.php. Be careful with any changes there and consider that things you change there might get overwritten by the nextbox-daemon

Technically, if our assumptions all hold true, then yes. BUT so far you are the only one reporting this, so I see some chances that my (our) conclusions here might not hold true. Might it be that you have a missconfigured (nextcloud) client which tries to connected repeatedly? Are there no other IPs inside the sql-table?

1 Like

thanks again. learnt a lot, for example that having an account with expired credentials under ubuntu’s “online accounts” is not a good idea and can cause confusion…

our (my!) assumptions were wrong, failed logins from external sources, like from my phone, show with correct ips, without any additional configs in nextcloud.

always welcome! good that you found it…

uh great, thx for checking :wink: