Nut upsuser - Jan 2014 - NUT clients - merits of authenticating

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)

Are there other merits of authenticating clients ?

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.

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.

Any guidance is appreciated.

Lonnie

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

On Jan 11, 2014, at 2:03 PM, Charles Lepple wrote:

-- snip --
> Authentication does not affect the behavior: in NUT, status is pulled from
upsd, not pushed.
Ahhh, thanks much for the clarification, Charles.

>> 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?
If they were to authenticate, NAS equipment such as Synology have hard coded NUT
credentials.


-- snip --
>> 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.
I understand, so for the common case where ups at localhost is the only valid
"master", the master password could even be randomly generated as the
"superdupersecret" and then the "monuser" password is less
important since a slave basically can't do anything.  Such as:

-- upsd.users --
[master]
password = superdupersecret
upsmon master

[monuser]
password = notsosecret
upsmon slave
--

I guess this still begs the question if the "monuser" user is really
necessary, other than providing the satisfying feeling of valid logins. :-)

> -- 
> Charles Lepple
> clepple at gmail
Thanks again,

Lonnie