Securing Netdata Agents
Netdata is a monitoring system. It should be protected, the same way you protect all your admin apps. We assume Netdata will be installed privately, for your eyes only.
Upon installation, the Netdata Agent serves the local dashboard at port 19999
. If the node is accessible to the
internet at large, anyone can access the dashboard and your node's metrics at http://NODE:19999
. We made this decision
so that the local dashboard was immediately accessible to users, and so that we don't dictate how professionals set up
and secure their infrastructures.
Viewers will be able to get some information about the system Netdata is running. This information is everything the dashboard
provides. The dashboard includes a list of the services each system runs (the legends of the charts under the Systemd Services
section), the applications running (the legends of the charts under the Applications
section), the disks of the system and
their names, the user accounts of the system that are running processes (the Users
and User Groups
section of the dashboard),
the network interfaces and their names (not the IPs) and detailed information about the performance of the system and its applications.
This information is not sensitive (meaning that it is not your business data), but it is important for possible attackers. It will give them clues on what to check, what to try and in the case of DDoS against your applications, they will know if they are doing it right or not.
Also, viewers could use Netdata itself to stress your servers. Although the Netdata daemon runs unprivileged, with the minimum
process priority (scheduling priority idle
- lower than nice 19) and adjusts its OutOfMemory (OOM) score to 1000 (so that it
will be first to be killed by the kernel if the system starves for memory), some pressure can be applied on your systems if
someone attempts a DDoS against Netdata.
Instead of dictating how to secure your infrastructure, we give you many options to establish security best practices that align with your goals and your organization's standards.
Disable the local dashboard: Simplest and recommended method for those who have added nodes to Netdata Cloud and view dashboards and metrics there.
Expose Netdata only in a private LAN. Simplest and recommended method for those who do not use Netdata Cloud.
Fine-grained access control: Allow local dashboard access from only certain IP addresses, such as a trusted static IP or connections from behind a management LAN. Full support for Netdata Cloud.
Use a reverse proxy (authenticating web server in proxy mode): Password-protect a local dashboard and enable TLS to secure it. Full support for Netdata Cloud.
Other methods list some less common methods of protecting Netdata.
Disable the local dashboard
This is the recommended method for those who have connected their nodes to Netdata Cloud and prefer viewing real-time metrics using the Room Overview, Nodes tab, and Cloud dashboards.
You can disable the local dashboard (and API) but retain the encrypted Agent-Cloud link (ACLK) that allows you to stream metrics on demand from your nodes via the Netdata Cloud interface. This change mitigates all concerns about revealing metrics and system design to the internet at large, while keeping all the functionality you need to view metrics and troubleshoot issues with Netdata Cloud.
Open netdata.conf
with ./edit-config netdata.conf
. Scroll down to the [web]
section, and find the mode =
static-threaded
setting, and change it to none
.
[web]
mode = none
Save and close the editor, then restart your Agent. If you try to visit the local dashboard to http://NODE:19999
again, the connection will fail because
that node no longer serves its local dashboard.
See the configuration basics doc for details on how to find
netdata.conf
and useedit-config
.
If you are using Netdata with Docker, make sure to set the NETDATA_HEALTHCHECK_TARGET
environment variable to cli
.
Expose Netdata only in a private LAN
If your organization has a private administration and management LAN, you can bind Netdata on this network interface on all your servers.
This is done in Netdata.conf
with these settings:
[web]
bind to = 10.1.1.1:19999 localhost:19999
You can bind Netdata to multiple IPs and ports. If you use hostnames, Netdata will resolve them and use all the IPs
(in the above example localhost
usually resolves to both 127.0.0.1
and ::1
).
This is the best and the suggested way to protect Netdata. Your systems should have a private administration and management LAN, so that all management tasks are performed without any possibility of them being exposed on the internet.
For cloud based installations, if your cloud provider does not provide such a private LAN (or if you use multiple providers),
you can create a virtual management and administration LAN with tools like tincd
or gvpe
. These tools create a mesh VPN
allowing all servers to communicate securely and privately. Your administration stations join this mesh VPN to get access to
management and administration tasks on all your cloud servers.
For gvpe
we have developed a simple provisioning tool you
may find handy (it includes statically compiled gvpe
binaries for Linux and FreeBSD, and also a script to compile gvpe
on your macOS system). We use this to create a management and administration LAN for all Netdata demo sites (spread all over
the internet using multiple hosting providers).
Fine-grained access control
If you want to keep using the local dashboard, but don't want it exposed to the internet, you can restrict access with access lists. This method also fully retains the ability to stream metrics on-demand through Netdata Cloud.
The allow connections from
setting helps you allow only certain IP addresses or FQDN/hostnames, such as a trusted
static IP, only localhost
, or connections from behind a management LAN.
By default, this setting is localhost *
. This setting allows connections from localhost
in addition to all
connections, using the *
wildcard. You can change this setting using Netdata's simple
patterns.
[web]
# Allow only localhost connections
allow connections from = localhost
# Allow only from management LAN running on `10.X.X.X`
allow connections from = 10.*
# Allow connections only from a specific FQDN/hostname
allow connections from = example*
The allow connections from
setting is global and restricts access to the dashboard, badges, streaming, API, and
netdata.conf
, but you can also set each of those access lists more granularly if you choose:
[web]
allow connections from = localhost *
allow dashboard from = localhost *
allow badges from = *
allow streaming from = *
allow netdata.conf from = localhost fd* 10.* 192.168.* 172.16.* 172.17.* 172.18.* 172.19.* 172.20.* 172.21.* 172.22.* 172.23.* 172.24.* 172.25.* 172.26.* 172.27.* 172.28.* 172.29.* 172.30.* 172.31.*
allow management from = localhost
See the web server docs for additional details about access lists. You can take access lists one step further by enabling SSL to encrypt data from local dashboard in transit. The connection to Netdata Cloud is always secured with TLS.
Use an authenticating web server in proxy mode
Use one web server to provide authentication in front of all your Netdata servers. So, you will be accessing all your Netdata with
URLs like http://{HOST}/netdata/{NETDATA_HOSTNAME}/
and authentication will be shared among all of them (you will sign-in once for all your servers).
Instructions are provided on how to set the proxy configuration to have Netdata run behind
nginx,
HAproxy,
Apache,
lighthttpd,
caddy, and
H2O.
Use Netdata parents as Web Application Firewalls
The Netdata Agents you install on your production systems do not need direct access to the Internet. Even when you use Netdata Cloud, you can appoint one or more Netdata Parents to act as border gateways or application firewalls, isolating your production systems from the rest of the world. Netdata Parents receive metric data from Netdata Agents or other Netdata Parents on one side, and serve most queries using their own copy of the data to satisfy dashboard requests on the other side.
For more information see Streaming and replication.
Other methods
Of course, there are many more methods you could use to protect Netdata:
Bind Netdata to localhost and use
ssh -L 19998:127.0.0.1:19999 remote.netdata.ip
to forward connections of local port 19998 to remote port 19999. This way you can ssh to a Netdata server and then usehttp://127.0.0.1:19998/
on your computer to access the remote Netdata dashboard.If you are always under a static IP, you can use the script given above to allow direct access to your Netdata servers without authentication, from all your static IPs.
Install all your Netdata in headless data collector mode, forwarding all metrics in real-time to a parent Netdata server, which will be protected with authentication using an nginx server running locally at the parent Netdata server. This requires more resources (you will need a bigger parent Netdata server), but does not require any firewall changes, since all the child Netdata servers will not be listening for incoming connections.
Do you have any feedback for this page? If so, you can open a new issue on our netdata/learn repository.