Someone tried (or is trying) to hack my Nextcloud instance

Nextcloud version: 26.0.1
Operating system and version: Debian 11
Apache or nginx version: Apache 2.4.56-1
PHP version: 8.1.18

The issue you are facing:

I’ve recently noticed some strange login attempts in my logs:

{"reqId":"ZEx1ieQ5D1RETtASJAONNgAAAJg","level":2,"time":"2023-04-29T01:40:25+00:00","remoteAddr":"","user":"--","app":"core","method":"GET","url":"/system/console?.css","message":"Login failed: 'admin' (Remote IP: '')","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36","version":"","data":{"app":"core"}}
{"reqId":"ZE1wUQ8gcXmhfWqsNUaJrwAAAA4","level":2,"time":"2023-04-29T19:30:25+00:00","remoteAddr":"","user":"--","app":"core","method":"GET","url":"/api/v3/users","message":"Login failed: 'rocketskates' (Remote IP: '')","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.0 Safari/537.36","version":"","data":{"app":"core"}}

I have never had/created a user called rocketskates on my server. Nor have I ever tried to login using something like this.
The same goes for admin as far as I know. I use nextcloud-pi and the default admin user is ncp, not admin.

I looked up the IP that both of these requests came from and it seems that it’s from a machine in the United States.
My server is not based in the US, I have never been to the US, nor do I know anybody from the US.
Also, the number of people who know about my server (and the hostname) is limited.

What can I do to protect myself from this attack (and future ones)?
Any advice is helpful!


1 Like

this topics have been discussed often already please use the search

It is very common to see attacks on services exposed to the internet. there are lot of bots, script kiddies and other checking if they can access remote system and find something of interest… answers are always the same

  • keep your system updated
  • use MFA
  • monitor system activity and block suspicious activities

Update: take a lok at this wiki to adopt most common security measures: How to maintain, check and improve the security of your Nextcloud installation?


It’s very normal sadly to get continuous login attempts on any exposed server. Require 2FA on all accounts, keep things updated, and consider implementing geoblocking if your firewall supports it.

Blocking foreign country connections in your firewall will eliminate almost all of these login attempts.


In addition to what the previous posters have said, I would like to add a very simple thing that doesn’t add any real security, but can help to reduce the noise in your Nextcloud logs:

If there is no targeted attack, which is very rarely ever the case, the following can help to reduce actual login attempts:

Configure your FQDN (e.g. cloud.yourdomain.tld) as the only trusted domain in config.php. If you do that, bots and script kiddies that are only using the IP address of your server, rather than using the actual FQDN of your Nextcloud, won’t get access to the login page and can’t start any brute force attacks / login attempts.

and / or:

Add a Catch-All VirtualHost to Apache:

<VirtualHost *:80>
 ServerName null
 ServerAlias *
 Redirect 404 /

<VirtualHost *:443>
 ServerName null
 ServerAlias *
 Redirect 404 /

That way, any request that doesn’t use the exact FQDN of your Nextcloud VirtualHost will get a 404 Error. That will achieve basically the same thing as the trusted domain setting, but they wouldn’t even know that Nextcloud is running on your IP.

Of course, this doesn’t help against attackers who put more effort in their attempts. But many bots only scan IPs for open ports and if they don’t find any known services or login pages right away, the will move on…


I did the catch-call vhost on mine as well, but I redirected to Bing. It’s nice that they never even arrive at the NC login page when they just go to the IP.

I don’t know if the 404 would make it a more or less enticing target. On one hand, it would just look like an empty server, but on the other, they might assume it’s poorly maintained and try to exploit it.


In addition to what others have already stated, I’ll point out that those requests don’t match any valid NC related URLs. They’re are likely just the result of general automated Internet scanning.

The second request looks related to a specific platform that is called, not surprisingly, Rocket Skates. And is attempting to log in to one if it’s default accounts.

1 Like

Yes that would be another way to do it. A third option would be to serve a placeholder page. Some simple “Hello world” page or a blank HTML file. That way the bot would get a 200 OK instead of a 404. Not sure though, whether one of these options would actually decrease the risk of being exposed to a real targeted attack…

That’s a cool and unusual name! I haven’t been attacked by that “user” before :stuck_out_tongue: But it’s also incredibly common to be attacked as soon as you’re online.

I’ve seen a reduction in these attacks over the years. I used to generate logs as big as 7MB per day listing the attacks on my server, but in recent years they’re down to a few hundred KB per day.

After reading your post, I grabbed a handful of attackers from my logs. Just yesterday, I was attacked by user logins such as :

  • oracle
  • user
  • oper
  • craft
  • devops
  • Admin
  • admin
  • cloud
  • g
  • postgres
  • ansible
  • 1234
  • es
  • ubnt
  • work
  • jenkins
  • william
  • pi
  • test
  • debug
  • MGR
  • brengoz
  • mine
  • xbmc
  • nagios
  • vagrant
  • debian
  • alarm
  • guest
  • cirros
  • aaaa
  • centos
  • lighthouse
  • dolphinscheduler
  • tao
  • steam
  • cristina

Your debian logs will show something similar. Basically, take the advice of those above (harden your system), head to the Winchester for a pint, and wait for it to blow over.


Thank you all for your comments and suggestions! :wink:

I found this one on my mail server a while back… have to bleep part of it to post it…

Authentication error for user 'suckmy*****peoplethataretryingtogetmypassword': Account not found locally


My NC instance is behind HAProxy (reverse proxy) on pfsense. Also, since my ISP don’t allow standard ports like 443 so have to map the port to something of 61000 range. By having that high of a port I rarely seen failed logins from script kiddies / port scanners as they don’t scan that high.

Also, I use Fail2ban to block the failed attempts after so many tries.