Prevent accessibility of login when coming in through status fqdn/cname

[Alestrix]

⚠️ Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find similar issue

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

📝 Describe your problem

First of all, thanks for such a brilliant and easy to setup piece of software! I started using it yesterday and have almost my whole home lab monitored through it already.

I am making my kuma's status page available from the internet via traefik (using a cname and the domain parameter in the status settings) and that's working well. This however still allows access to the /dashboard path where an external attacker could try to brute force my kuma install.

I subsequently blocked access to the /dashboard PathPrefix in the traefik configuration but am wondering whether this is enough? Could login still be attempted through other paths, for instance by posting credentials directly without first loading the login page?

Thanks!

🐻 Uptime-Kuma Version

1.15.1

💻 Operating System and Arch

Docker in lxc on Proxmox, x64

🌐 Browser

curl, python, Chrome with some plugins... anything an attacker could use

🐋 Docker Version

20.10.11

🟩 NodeJS Version

No response

[louislam]

Maybe not enough, because admin function can be done in WebSocket connection directly.

I may plan to add checkbox for if domains added as a status page domains, it will not be allowed as the dashboard link.

[iamdempa]

Hey @Alestrix and @louislam, is it possible to monitor internal services (using fqdna) with uptime-kuma? For an example, I want to monitor nginx.default.svc.cluster.local. I tried, but it still fails. I think it is polling this url as a public endpoint. Any help?

[Alestrix]

@louislam Do admin-function websockets have dedicated api paths, separate from those used to display the monitors? If so, I should be able block them in traefik just like normal http(s) requests.

@iamdempa Your question is not related to this issue and shouldn't be discussed here. Moreover, it's more a Kubernetes question than an uptime-kuma question. But in short: If the fqdn is resolvable and the ip and port accessible from the pod your kuma install runs on (check with kubectl exec), then sure, you can monitor it.

[louislam]

Normally, it should be ws://<domain>/socket.io/?EIO=4&transport=websocket.

Or if it is possible, you can just block all Websocket connections for your domain.

[Alestrix]

Or if it is possible, you can just block all Websocket connections for your domain.

I don't think traefik can distinguish between websocket and regular http. But it is possible to block all paths starting with socket.io. I'll have a run at it during the coming days.

[github-actions[bot]]

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 7 days.

[Alestrix]

I may plan to add checkbox for if domains added as a status page domains, it will not be allowed as the dashboard link.

Hi @louislam, has this been implemented without me noticing? :-)