Some ISPs, when pressed for refunds from downtime or poor service, ask if you have any reports. SNMP and connection monitoring has been the mainstay in my local network that’s provided those reports with an always-on server that captures my router traffic info. Specifically, I use PeakHour for MacOS.
With the reports I provide, they give me refunds. Death before dishonor.
SNMP is how PDUs let us monitor power consumption over a telco's whole hosting infrastructure (hundreds of sites). Security at protocol level is inexistent, so it runs on a very isolated and very monitored network. Not suitable for infrastructures that can't provide that sort of sophistication to compensate for SNMP's gaps.
If using netsnmp, it will work without problems, always (in my experience). Anything that doesn't work exactly the same (bugs and all) - good luck. The reason is that everyone seems to use netsnmp when developing, and when it works, the work is done. Doesn't work elsewhere? Yeah, that's too bad.
So, 4 years later, and SNMP is still alive and well. It has (a lot of) rough edges, but it works, is ubiquitous and all sysadmins know how to work with it. Not even such a bad standard once you get used to it. I can't imagine anyone running a (smallish, not G-size) corporate network without it.
If you're polling a device you can put wrieguard on, not a problem. If you're not, wireguard to a device on the same LAN and ACL off SNMP traffic at the router.
SNMP is very useful for sending one-way commands to satellite-connected computers because it allows you to recover computers that have lost uplink connectivity - not so with HTTP/TCP which requires two-way handshake.
A common scenario is that a satellite-connected terminal loses uplink connectivity with the ground network, so the ground network issues a reset to the terminal via SNMP, which has a high likelyhood of going through (since downlink is simpler/more stable than uplink). I suppose you could also use UDP, but when I worked for the telecom industry, SNMP was a common use-case for this problem of one-way communication.
Yeah you're right, I think SNMP is based on UDP; I just meant you could use "raw" UDP datagrams to send one-way commands if you didn't want to use SNMP
As the video says, SNMP has a lot of problems. But not everyone needs the kind of precision and scale that Google does. For now most of us will plug along with SNMP because it's good enough.
I like the idea of what's being proposed, I'm just not sure I'll be able to use it with my networking hardware any time soon.
Both! vulnerabilities in the SNMP implementation do happen sometimes, and misconfigurations aren't unheard of. I once found an SNMP listener on a router that allowed _writing_ values, and it made it trivial to add a port forwarding rule that allowed me to skip right over the ingress firewall and some IDS system. I was also able to add a route table entry that joined separate VLANs so machines in those could talk to each other directly (which greatly aided my task).
Even if it's read-only, SNMP can contain all the info you need to build a network map: IPs, hostnames, and even a description (like "accounting-printer" :-D). In one I looked at, it even had information on when the configuration was last updated, so I was able to see which devices were recently given attention by the sys admin, and which devices weren't. I found a few hosts that had slipped through the cracks and were running really old kernels that were exploitable.
If you're defending a network, I definitely recommend scanning for any SNMP listeners, especially on anything that routes packets. If you're trying to compromise a network, I give the same advice.
On Wellfleet/Bay Networks/Nortel routers, all configuration is exposed as SNMP variables. Very common to find weak/trivial authentication on them, exposing complete configs as well as all tables (arp, irp/igp, etc) needed to construct a detailed picture of a network, as well as being able to change things to suit the attacker.
Many Cisco routers allow downloading and uploading(!) of configuration files using special SNMP fields in conjunction with FTP/SCP. There are many of these misconfigured routers exposed to the internet and I'd be surprised if they all haven't been backdoored.
We use SNMP to control industrial power distribtion units. It might not be the best solution but the alternative of implementing multiple http interfaces depending on the vendor (been there, done that, pretty sucky) it worse.
With a good IT dept, SNMP running on close loop networks and such, it's good enough.
I've got a bunch of 'smart' switches from various vendors. Each one has different ways of logging into it and commands to execute to see what devices are on the ports. Some of them even have ancient ssh running on it such that I have to special case the ciphers/algos in my .ssh/config file just to log into these things.
Other than SNMP, what would I use to figure out which device MAC is on which port or if the port is even active or not?
I believe that at the time of ratification, Craig Partridge withdrew his counter-proposal which was (as i understand, i have never found a draft) based on a lightweight sandboxed interpreter running on the target. i think it would have been a great model. snmp security was always sad, alarms, the data model, the getting wrapped around the asn.1 axle. somehow it was enough of a clumsy mess to prevent any real tooling from taking off. generations of vendors burning resources to implement mibs that were probably more often accessed by test harness than real users.
I'm working on a system now that uses a query language, bearer tokens with delegation and presents a tabular model ala sql. probably better?
> I'm working on a system now that uses a query language, bearer tokens with delegation and presents a tabular model ala sql. probably better?
Have you got a link? I'm very interested in a tiny (less than 2KB) replacement for SNMP. A minimum implementation size larger than 2KB is probably a non-starter.
The draw of SNMP is that the agent is available on almost every tiny router or networked device there is, even those that don't have a user interface. This means that a protocol over http(s) is too heavy for most devices[1].
Additionally, because network monitoring tools are using this pretty much constantly, even a few bytes of overhead adds up pretty quickly, so using http(s) is again out of the question.
Same for supporting a query language, or even tabular data.
Agreed, the replacement is lightweight agents that can stream useful data to a place where it can be consumed. I feel like this is where most people are going given the offerings we see from datadog, sentry, splunk, etc...
A shiny nickel says that if your router is smarter than a box full of forwarding tacks, it does or can emit SNMP. Same for managed switches. Printers. Cable modems.
With the reports I provide, they give me refunds. Death before dishonor.