Stop Agent's HTTP interface
Not sure this is the right place to ask, please inform me if I have to post somewhere else.
I have installed the Agent in my work laptop and as discussed in the docs it exposes laptop’s metrics on http://localhost:19999/ which is OK. I do not feel safe though to have my production servers opening the 19999 to the “world”. Is any configuration I can set up for the local Agent not to have an HTML interface?
Found it with help from Odysseas:
Open netdata.conf with
./edit-config netdata.conf. Scroll down to the
[web]section, and find the
mode = static-threadedsetting. To disable the local dashboard, change this setting to
service netdata restart
Guess this should be the default behaviour?
@zerberus893 we should offer an installation option not to bring up the Netdata agent dashboard but work as a headless monitoring agent.
Here is a relevant forum thread by @joel: https://community.netdata.cloud/topic/92/running-a-headless-netdata-agent-with-cloud-compatibility
@manos-saratsis, I think it was discussed with Austin, it’s not trivial.
As mentioned, it’s not exactly trivial. To properly run headless, we would need a few things:
- A switch in the installer to skip installing the dashboard. This is doable and actually rather easy, but not very useful without the other parts.
- A mode for the integrated web server that still responds to API calls, but nothing else (probably returning 404 for everything else). This may or may not be easy (I don’t know enough about our internal web server to comment one way or the other).
- A way to control what the default mode for the internal web server is at configure time so that when the installer doesn’t install the dashboard, it also builds Netdata with the above mentioned internal web server mode as the default. This is going to be a bit more complicated to do than the other two.
This kind of support is not quite the same as completely turning off the web server, because it still allows for API queries (which are important in some cases, such as exporting to Prometheus in certain configurations).
A comment if allowed: Shouldn’t modern software have the most secured defaults it can? I have not used Prometheus (boo) but I guess a better option would be to have web output disabled by default and then ask people to enable if when/if they want to or if they want the machine to respond to any API calls.
For reference I guess we are aware of the MongoDB situation with having very unsafe defaults (I think access to world and default read/write or something) and the huge number of data leaks it generated last year (2020 at time of writing this): https://techhq.com/2019/05/massive-mongodb-database-leak-a-data-security-wakeup-call/.