[Nut-upsuser] NUT clients - merits of authenticating

[Charles Lepple]

On Jan 9, 2014, at 4:00 PM, Lonnie Abelbeck wrote:

> Hi,
> 
> I'd like to better understand the merits of NUT clients (slaves) properly authenticating with the NUT server (master).
> 
> NUT allows clients to retrieve UPS status (upsc ups at 10.10.10.1) without authenticating, shutdowns are properly trigger via polling.
> 
> From testing one apparent benefit of authenticating is the client receives the shutdown event more quickly rather than the polling interval. (it seems)

upsmon polls upsd at the pollfreq (and pollfreqalert) rates. upsd gets its status from the driver at a different polling rate, which is explained here:

   http://article.gmane.org/gmane.comp.monitoring.nut.user/8275

If you are comparing upsmon (authenticating to upsd) and writing a loop around upsc (not authenticating), then for equivalent polling periods, there is no difference in how quickly the shutdown event gets delivered. Authentication does not affect the behavior: in NUT, status is pulled from upsd, not pushed.

Here's the loop in upsmon that polls upsd:

   https://github.com/networkupstools/nut/blob/master/clients/upsmon.c#L1999

> Are there other merits of authenticating clients ?

I honestly don't know. Having not written the original code, I see authentication for slave mode as something that is easier to leave in than take out, given that authentication is a little more relevant for the master connections.

Also, as you point out below, it does limit the mischief a bit.

> On the flip side, since commercial products like NAS drive implementations use fixed, well known user/pass credentials, all clients would need to be configured with such well known credentials if they were all to authenticate with a common user.

Why do they need well-known credentials?

I will point out that some of this is rhetorical - the NUT security model was designed over a decade ago, when different assertions could be made about the security of the physical network, and the trust relationships between the servers running upsmon and upsd.

The only time I would recommend well-known credentials is when strict certificate checking is being done over SSL/TLS. At that point, there is no need to worry about credential spoofing if the client cannot even connect without a valid certificate.

> The NUT /etc/ups/upsd.users file has only one entry:
> --
> [monuser]
> password = superdupersecret
> upsmon master
> --
> Is this a security issue if the password is well known ?  Searching the mailing list I only found the comment: "All a upsmon slave can do, is delay shutting down for a handful of seconds." ... seems like limited mischief.


If you have "upsmon slave", I would agree with the "limited mischief" comment. The entry above says "upsmon master", which allows setting "fsd". This fools other clients into thinking that the UPS has been commanded to shut down, and if the clients are running upsmon, they too will shut down.

-- 
Charles Lepple
clepple at gmail