SNMP v3 at least has some security in mind, but a lot of devices are just v1 or v2c which are basically unsecured. Allowing ANY write access via SNMP is a bad idea in my opinion, unless you segment it out into it's own secured management or out-of-band network. Even then... I'd be worried.

Network infrastructure security has a lot of unsolved gotchas and not a lot of industry desire to fix. Most of what everyone interacts with is in an abstracted or virtualized layer on top of the old plumbing.

▲

elevation 2 days ago | parent [-]

SNMP v2c is still common in the embedded world because it's protected with a simple password so it just works out of the box. SNMPv3 requires key management and an established PKI, and there's no equivalent of Let's Encrypt for isolated use cases in small orgs.

	▲	ay 2 days ago \| parent \| next [-]
		SNMPv3 absolutely doesn’t require PKI nor key management, it works fine with shared keys. You can take a look at an implementation of that, which I had built for entertainment: https://github.com/ayourtch/oside/blob/main/examples/snmpwal...
	▲	mkipper 2 days ago \| parent \| prev [-]
		I never looked into the guts of how this was implemented, but I worked on a product which had an SNMPv3 agent that was only restricted by a username and password. I could flash a PC with a fresh Ubuntu image, apt install Net-SNMP and start sending SNMPv3 requests without every futzing with any keys. If I remember right, handling SNMPv3 traps required some messy key stuff so the agent still sent SNMPv2 traps, but there was no requirement for keys for GET/SET.