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.
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.
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.
Readit News
With the reports I provide, they give me refunds. Death before dishonor.
SNMP Concepts are not only excellent but essential:
* A curated listed of universal codes for monitoring common attributes
* Some sort of standardized plug/play protocol that can allow things from one thing to monitor things from another thing
* Oh and it's UDP
It ticks all the boxes except for security.
I'm not sure how to get past that one without pushing a private key or a shared secret onto each managed device (maybe with SNMP SET?).
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.
My knowledge is a little rusty, but aren't SNMP packets enclosed in a UDP datagram?
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.
An absolute gold mine, and (for some reason) it's one of the last things people think about when securing their networks.
If you use SNMP, consider it a sensitive system and protect it accordingly.
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.
With a good IT dept, SNMP running on close loop networks and such, it's good enough.