Grafana is publicly accessible by default

[lostmsu]

This configuration is insecure, Grafana and all monitoring in general should only be accessible from the node.

Enabling ufw does not fix the issue.

[itenev]

Could you elaborate why do you consider exposing Grafana to be insecure? As far as I can see, there is no sensitive information being displayed.

Also, the main use-case for Grafana is remote monitoring so making is accessible only from the node sounds counter-productive. Note that the rocket pool documentation contain instructions on configuring the firewall to allow access to Grafana from the local network, subnets or from anywhere : https://docs.rocketpool.net/guides/node/grafana

[lostmsu]

Could you elaborate why do you consider exposing Grafana to be insecure? As far as I can see, there is no sensitive information being displayed.

If there are any RCE vulnerabilities in Grafana or its server stack and it is exposed for the entire Internet to access you can lose your crypto.

Also, the main use-case for Grafana is remote monitoring so making is accessible only from the node sounds counter-productive.

This would be fine if I could whitelist IPs or SSH tunnel into the node. But by default it should not be available. Defaults must be secure for any network-accessible services. Even more so for anything related to finance.

Note that the rocket pool documentation contain instructions on configuring the firewall to allow access to Grafana from the local network, subnets or from anywhere

The instruction on Grafana is wrong or at least is out of context - it does not apply to the default Docker-based setup. In reality ufw rules do not apply to Docker. If you enable firewall as described in https://docs.rocketpool.net/guides/node/securing-your-node (note no mention of opening Grafana ports) and then enable Grafana, that Grafana will be publicly accessible.

[freakynl]

If there are any RCE vulnerabilities in Grafana or its server stack and it is exposed for the entire Internet to access you can lose your crypto.

That seems far-fetched.

1. They would need to break out of the grafana container and be able to access private keys.
2. Even if they could do that and exit your validator your funds would go to withdrawal wallet (if configured, but that's strongly advised). They could access what funds are available in the node wallet, but the advise is not to leave much in there anyways. Just a bit for transactions.
3. In the case of IPv4 (and the containers don't seem to use IPv6 by default at all) even though the port is open on the node (and with it the local network), for it to be internet accessible it would need to be forwarded on the router which isn't in the instructions anywhere that I've seen. -- Unless you have an external IP directly on your docker host, but I would hope you'd know the risks and how to mitigate them to begin with it that case. Having public v4 space directly on the node isn't quite the norm.

[lostmsu]

@freakynl

1. Docker is not a security boundary, so that's just a matter of coding.
2. There are usually funds on the node wallet itself.
3. Node's security should not rely on external happy circumstance. In this case I am concerned because my network has IoT devices, which is not uncommon, and they are on the same subnet. Famously, s in IoT stands for Security. Funnily enough this probably was the exactly same argument from which IoT got its security from.

[jshufro]

Hi all, I'm a part-time maintainer. We're aware of the ufw/docker incompatibility. This isn't a bug in smartnode itself, it's an issue at the system level.

If you're concerned about RCE (as you probably should be, since the log4j exploit, etc), then you can configure smartnode to bind the grafana port to a tailscale or wireguard interface. Simply modify ~/.rocketpool/override/grafana.yml to contain a port section that does the binding, and leave the port set to "closed" in the tui.

[lostmsu]

I think there might be a decent chance to get it secured by adding Nginx or some other similar service and setting it to filter incoming requests based on source IP.

I sort of worked around the problem for myself by just disabling grafana node. The issue is more to push for secure by default configuration.

[jshufro]

Generally we expect most of our users to be behind a NAT barrier, but I agree that running a reverse proxy instead is probably better.

[lostmsu]

@jshufro there's no setting to close Grafana port in the TUI, only for Prometheus.

[jshufro]

Well, that is an oversight. I'll see that it gets added.