[Nut-upsuser] Client behind firewall

[Arjen de Korte]

>>> The problem is I really don't want to open a port form the dmz
>>> to the internal network where the master UPS machine resides. I have
>>> data from various clients that I can't have comprised.
>> What has opening a port to do with that?
> Arjen, I think Mike was referring to the fact that the client
> initiates the TCP connection to the server, and not the other way
> around. This requires opening a hole in the server's firewall (grant
> access to port 3493, or another port if configured by ./configure
> --with-port).

Initiating traffic is only one thing. Regarding the security of this
setup, it doesn't make a whole lot of difference whether the connection is
initiated from the DMZ or internal network. For some firewalls it may be
somewhat easier to setup, but security is just as bad either way. See
below.

> I don't see any reason, in principle, why the server could not
> initiate the connection to the client instead. However, this would
> require a lot more configuration on the server side (which clients to
> connect to, what to do if it fails etc), and might also upset the
> startup sequence (currently the server is started before the clients).
> So in practice it would be quite difficult to implement.

It wouldn't help. If you can't trust the upsmon client on the DMZ, you're
toast anyway. Someone might have compromized the system in the DMZ and
replaced upsmon by a malicious program, trying to gain entry through upsd.
Then he only needs to wait for upsd to call in and the connection is
there. The real issue here is that we need two-way communications in NUT.

Only if you do something like broadcasting server status via UDP and don't
listen for replies, it might make a difference. In that case, one might
place the UPS master on the internal network and forward the broadcast
packets to the DMZ. There would be no communication from DMZ to internal
network, so security is not compromized in any way. But in that case, it
would be impossible to wait for slaves to shutdown before the master takes
the UPS down. And on a network with multiple UPS'es, the traffic would
explode, since you would have to broadcast the full server state (and all
variables) as there is no way to know when slaves start listening.

To facilitate configurations like the one mentioned, we might add a
'ups.status' broadcast mode in upsd and provide an additional
'listen-only' mode in upsmon, but I certainly wouldn't recommend such a
setup.

Regards, Arjen