Nagios Support Forum

Hello there,

In almost every documentation online I could read, that the resource.cfg is a good way to store passwords. I needed to store a password for a database user and I just stored my password as a user-variable ($USER5$) in the resource.cfg.

Then I looked into the systemctl status nagios to check if there are any problems. Thats when I noticed, that one of my perl-plugins was listed as a process with its variables fully resolved - which means, the password was written there. This is a bit shocking since everyone can execute the systemctl status nagios and can get the password with almos no effor.

Is there a way to prevent this? Or am I doing it completely wrong?

Greetings

corax90 wrote:Is there a way to prevent this?

You could alter your systemd definition for Nagios Core, but that won't stop command arguments from being exposed in ps or practically any other process utility.

It 100% depends on the plugin you're using. Some of them have options for creating tokens, hashing/encrypting passwords, loading passwords directly from a file, etc. Most of them don't and only accept credentials as plain-text arguments.

You could store encrypted credentials in resource.cfg, sure, but your plugins would still need to know #1 that the credentials are encrypted and #2 how to decrypt those credentials.

So to your original question, yes there is a way to prevent this. By writing plugins that don't accept plain-text credentials as arguments

One option would be to run everything via check_by_ssh and then everything runs on the client side. You have the same issue with the plugin needing the password, but it may be more acceptable to have this all spread out and just limit access to those machines. You can, of course, just limit access to the nagios server as well.