Nextcloud / Immediate Unauthorized Intrusion Events / Domain Leaks?

ℹ️ Support
1

Hi Community,

new user, first serious question re security…

Got my Nextcloud instance set up as Docker container running in a VM, https access via Nginx Proxy Manager (NPM) within a subdomain of my main, let’s call it “mynextcloud.mypersonaldomain.com”. I set up 2FA and monitoring of login requests via fail2ban.

All working fine, however:
as soon as I set up my subdomain “mynextcloud” using a new CName entry, immediately, I got several intrusion attempts from various IPs.
I understand that my cloud instance can be accessed from the Internet and could therefore be targeted by criminal parties to get unauthorized access, but right away and using my personal, arbitrarily chosen subdomain ? Highly unlikely.

So I changed my subdomain from “mynextcloud.mypersonaldomain.com” to “nc.mypersonaldomain.com” and the same result - again right away several intrusion events, all caught by fail2ban.

I have several other subdomains running within NPM, and none of those have been attacked ever, so I don’t think that there are leaks within NPM, Let’sEncrypt or my DynDNS provider (where I’m registering the CNames).

The only possible leak I can think of is within NextCloud - maybe the new instances are being registered within NC, and this registration is being traced ? Honestly, I don’t have another explanation.

Can you please share your experiences and opinion from a security point of view. How is it possible that my NC instance using my private subdomain is immediately targeted by login requests ? Did I do something wrong ? Is there a central public NextCloud registry, storing all instances, which can be publicly accessed ?

Thank you for your support in this matter. I’m really worried - not because of intrusion attempts themselves, but because of the short timeframe between making my instance public and third parties trying to login.

SP

{"reqId":"GnONyakTw93Lfdu5sEHy","level":2,"time":"2023-11-30T17:20:49+00:00","remoteAddr":"2a01:6340:2:501::20","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: sven99@devaza.id (Remote IP: 2a01:6340:2:501::20)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"nP9leM7IVlbo9o2BbcdQ","level":2,"time":"2023-11-30T17:21:00+00:00","remoteAddr":"2a01:6340:2:501::20","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: sven99@devaza.id (Remote IP: 2a01:6340:2:501::20)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"hwqLZjqtzYeA3aJ0h3fw","level":2,"time":"2023-11-30T17:21:11+00:00","remoteAddr":"2a01:6340:2:501::20","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: hugolehmann92@outlook.com (Remote IP: 2a01:6340:2:501::20)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"J10JBzEXiEbHoLoTAOzt","level":2,"time":"2023-11-30T17:22:45+00:00","remoteAddr":"2a12:5940:13e2::2","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: predovicalexandria138@gmail.com (Remote IP: 2a12:5940:13e2::2)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"7xGaPRP0korP8kbcjB8Z","level":2,"time":"2023-11-30T17:22:55+00:00","remoteAddr":"2a12:5940:13e2::2","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: predovicalexandria138@gmail.com (Remote IP: 2a12:5940:13e2::2)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"0BG0nSH5pR7T4D9iDPJi","level":2,"time":"2023-11-30T17:23:08+00:00","remoteAddr":"2a12:5940:13e2::2","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: sven99@devaza.id (Remote IP: 2a12:5940:13e2::2)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"a8CzRh9NFzv68GQZVHyw","level":2,"time":"2023-11-30T17:24:46+00:00","remoteAddr":"2a04:52c0:129:c0c1::1","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: predovicalexandria138@gmail.com (Remote IP: 2a04:52c0:129:c0c1::1)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"sV7y0iFJX7cpuoDJr6Fc","level":2,"time":"2023-11-30T17:24:56+00:00","remoteAddr":"2a04:52c0:129:c0c1::1","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: hugolehmann92@outlook.com (Remote IP: 2a04:52c0:129:c0c1::1)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"uwIClVsy8WfxJRjJVrGb","level":2,"time":"2023-11-30T17:25:05+00:00","remoteAddr":"2a04:52c0:129:c0c1::1","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: sven99@devaza.id (Remote IP: 2a04:52c0:129:c0c1::1)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"zUMJQwaS0Mw265YIdzGf","level":2,"time":"2023-11-30T17:26:17+00:00","remoteAddr":"185.232.22.203","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: anastacio.turcotte@devaza.id (Remote IP: 185.232.22.203)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"TLr5FV2ZFiJ528iRhO8Y","level":2,"time":"2023-11-30T17:26:26+00:00","remoteAddr":"185.232.22.203","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: anastacio.turcotte@devaza.id (Remote IP: 185.232.22.203)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
{"reqId":"OND54ps6wuFk6omO2nT4","level":2,"time":"2023-11-30T17:26:35+00:00","remoteAddr":"185.232.22.203","user":"--","app":"no app in context","method":"POST","url":"/login","message":"Login failed: hugolehmann92@outlook.com (Remote IP: 185.232.22.203)","userAgent":"Mozilla/5.0 (Android 14; Mobile; rv:120.0) Gecko/120.0 Firefox/120.0","version":"27.1.4.1","data":[]}
2

I’m running 2 Nextcloud instances one for production and one for testing on different hostnames and don’t see any failed login attempts (my nextcloud.log and nextcloud.log.1 goes back at least 1 month). I had to generate failed logins intentionally to make sure my filter is right! feel free to use if you find it handy (parses the log using jq and selects only logins without user context):

cat files/nextcloud.log|jq 'select (.user=="--" and .url=="/login")|{reqid,time,user,url,method,remoteAddr,message}'

Definitely I see bad actors testing my IP in the reverse proxy log, but most (all?) attempts don’t reach NC as there is no right SNI (hostname/Domain name provided) so the proxy doesn’t know where to route the request and drops it.

3

Hi,

unfortunately, i have exactly the same problem as you described.

my old nextcloud instance has now been running for about 1 year without the “accesses”. However, this instance was installed manually on an Ubuntu 22.04.

Yesterday I set up the Nextcloud AIO Docker instance and immediately got accesses. I came across this thread by searching for the address “hugolehmann92@outlook.com”. I also have a few more addresses that are always structured in the same way. First name+last name+number+domain.

Both instances run via an NPM.
So our installations seem to be quite identical.

Unfortunately I have no idea or solution. But I just wanted to let you know that the problem generally appears.

Best regards

4

Hi,

I contacted my web hosting provider to check for any leaks or public APIs to some central DNS instances, since I thought I was the only one with the issue within NC. My domain provider is variomedia AG (Potsdam).

Somewhere / somehow this information about new NC instances and/or new CName entries must be published in realtime and immediately used for checking the new instance for… what ? Vulnerabilities ? Clearly these fake emails lead to nowhere.

Anyway, until these questions have been sorted out, I disabled my NPM entry, I will connect via VPN.

Kind regards,
SP

5

Hi,

i just check the uniqe visitors on my domain:

grafik

As you can see it just came across when i setup the docker instance.
I will also deactive the webaccess until i find a solutoin/answer to this wierd behavior.

Thank you.

BR

6

First of all, Let’s Encrypt certificates are public information. Anyone can find any certificate for any domain and subdomain that anyone has ever issued. For example here: Certificate Transparency Search API by SSLMate

Also, I don’t know how NPM handles the certificates, but if it adds all the subdomains to the same certificate, then anyone who accesses your server can see all of the subdomains, regardless of which subdomain they used to access your server. It’s also possible that a webserver still serves the certificate, even if it’s accessed via the IP address, in which case browsers and applications will throw a warning because the names in the certificates don’t match, but the certificate will still be loaded, and the client can then see all the subdomains it contains.

There are also services that regularly scan all IPv4 addresses on the Internet, such as shodan.io, and if your server is serving a certificate that includes all the subdomains, they will appear there. Check for yourself…

So how can you prevent people and scanners from making assumptions about the services you host based on your subdomains?

Well, there two ways:

  1. Use a wildcard certificate everywhere: *.yourdomain.tld
  2. Use cryptic names for your subdomains

Obviously number 2 isn’t a good solution, and regardless of which option you use, your public instances will still be scanned, and as mentioned above, they may still be able to find what’s hosted on your server. However they will no longer be able to draw conclusions about the applications and services your server is hosting solely based on the subdomains, which may help reduce targeted attacks or phishing attempts based on the services you run.

3 Likes
7

In my opinion geoplocking based on ip-address is the best way to reduce the attack surface. There is a community container for AIO that allows you to do exactly this https://github.com/nextcloud/all-in-one/tree/main/community-containers/caddy but you obviously cannot run that behind another reverse proxy.

2 Likes
8

In addition to what @szaimen said you could also look into things like Crowdsec or just plain old Fail2ban. And of course keep your hole software stack always up to date, use secure passwords and 2FA etc.

Security by obscurity is never a good solution. It might help to reduce the noise somewhat, but sooner or later, the bad actors will find your services, so discoverability of your services shouldn’t be your main concern.

Ultimately, the only way to reliably prevent someone from discovering your services is to not expose them to the public internet and put them behind a VPN, which, of course, isn’t very practical for a file sharing and collaboration solution like Nextcloud. :wink:

3 Likes
9

Hi,

many thanks for these helpful insights. NPM is actually creating one certificate for each subdomain, however using the link you provided, I could query all my subdomain certificates in 1 long list. That’s really interesting news - to be able to query all LetsEncrypt certificates via a public API.
Actually, I got Fail2Ban set up and working, however you never know about any hidden vulnerabilities in NC itself… so I will go for VPN and eventually geoblocking, but for this I need to get some hardware first. Or I migrate from NPM to Caddy.

Thanks again for these clarifications.

1 Like
10

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.