[Nut-upsuser] ISE review of I-D: deprecate command VER?

[Manuel Wolfshant]

On 3/20/22 22:02, gene heskett wrote:
> On Sunday, 20 March 2022 15:10:00 EDT Manuel Wolfshant wrote:
>> On March 20, 2022 5:02:36 PM GMT+02:00, Roger Price
> <roger at rogerprice.org> wrote:
>>> I received the following comment from the Independent Submissions
> Editor (ISE):
>>>   The command VER is hazardous because it encourages exploiting of
>>>   implementation peculiarities that are not well documented in a
>>>   protocol.  The best example of such a failure is the browser version
>>>   field in HTTP.  A complete disaster.  You should warn against use of
>>>   this command, or even better, deprecate it.
>>>
>>> I was not aware of the disaster in the browser version field, but I
>>> will warn against use of VER, and deprecate it, if you agree.
>>>
>>> Roger
>> Hello
>>
>> I do not know of anyone calling the situation of browsers  "a
>> disaster". It's true, the version field can be and is used - together
>> with other data that the browser sends (!!!) - to create an almost
>> unique signature of the user. But OTOH it is used to adapt the looks
>> of the site to the capabilities of the browser because , well, no two
>> browsers behave 100% the same and site developers try to make sites
>> that look as bright and shiny as possible in the eyes of the users .
>> For a start, that's how the desktop and mobile versions of
>> dynamic/responsive sites differentiate the clients and adapt
>> themselves to present the best look and feel to clients.
>>
>> Leaving that aside, I see no issues in warning users about the
>> potential nefarious uses of any command. In this particular case I'd
>> also add a reference to restricting the communication between nut
>> servers and clients to the smallest possible subset of devices (by
>> using dedicated VLANs, firewalls etc) and ask them to reread the
>> security section.
>>
>> wolfy
> Even better, hide your local network by getting a good router, reflashing
> it to something like dd-wrt or its ilk, and using it to NAT your local
> net somewhere in the 192.168.xxx.yyy address space but which is not
> transmitted thru a router without coming under the control of the NAT in
> the router. All your stuff behind such a router is invisible to the black
> hats, making all your machines at least 1000 times more secure unless you
> leave the router passwd at its default, in which case you'll be powned by
> 10 seconds after its powered up and the modem cable plugged into it.

That's not really feasible for enterprise locations. At home I used 
dd-wrt since 2013 until 2 months ago when I replaced my router but I 
will certainly not insert such a router in my work environment when I 
could simply configure the enterprise-grade switches to use dedicated 
VLANs for the various equipment. I have one VLAN  for video cameras, 
another one for the management of the network equipment and so on . And 
yes, I know very well that VLAN's primary role is separating broadcast 
domains, not security. However coupled with proper firewall rules 
separating the VLANs, one can create a decent environment.

And no home user will dedicate a separate router for an UPS. On top of 
that, separating the UPS from the other devices is possible but not easy 
because any and all home-grade routers by default will inject a single 
rule that NATs the single class defined behind it. Separating the UPS 
from the rest requires manual intervention, many times directly in the 
CLI. And please do not imagine for a single second that you will be safe 
simply because you NAT everything,  as there are miriad of scripts that 
rely on UPNP or client vulnerabilities to propagate inside user 
networks, behind any firewalls.

For the record, I was referring to 
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-07.html#name-security-considerations 
as a reply to ISE's comment on 
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-07.html#name-ver