Check WMI issue

[CFT6Server]

Looks like the field "State" is Running but it could be looking for the "Status" field which is shown as "UNKNOWN".

Code: Select all

              'Started' => 'True',
              'Status' => 'UNKNOWN',
              'DisplayName' => 'DPS',
              'State' => 'Running',
              'Name' => 'DPS',
              'StartMode' => 'Unknown'

Code: Select all

              'Started' => 'True',
              'Status' => 'OK',
              'DisplayName' => 'DHCP Client',
              'State' => 'Running',
              'Name' => 'Dhcp',
              'StartMode' => 'Auto'

This means some additional permissions issues I gather...

Also one question about further obfuscating the password so it is saved in hash and not plain text in resource.cfg? Is that possible?

[Box293]

Also one question about further obfuscating the password so it is saved in hash and not plain text in resource.cfg? Is that possible?

No, the listener at the other end doesn't know how to un-hash it.

[CFT6Server]

Don't mean to hash the value sent to the WMI listener, that can go in plain text. What we would like to avoid is to have the password in plain text in the config file. Is there any way to obfuscate that value and have nagios convert it to plain text prior to assembling the check command ? Maybe a built-in function or macro in Nagios that would convert the string from the text file on the fly ?

Thanks

[jdalrymple]

I want to say this has been asked and answered, but it's so hard to find because it always ends up being at the butt-end of a thread titled something like "Check WMI issue"

So that doesn't really work for a couple of reasons. Hashes are non-reversible, for a reason. If it was reversible then a malicious user could just reverse the hash and know the password, makes the whole exercise pointless. As Box293 said since there is no way to compared the hashed value at the receiving end it becomes an impossible journey.

Furthermore, even if you did have a construct to obfuscate the password (perhaps a pgp managed .auth file holding all the passwords?) - if said malicious user was stifled by that process they're going to be able to tcpdump the interface and just watch the password go out on the line anyway.

I'm not going to profess to be a security expert, I just can't wrap my mind around how you would actually go about adding the security construct (no cleartext in config files) you're seeking.