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
<ro...@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
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
