Lamont’s Monitored Network Objects Protocol (a.k.a. LMNOP). Has a nice ring to it, don’t you think? OK … I’ve been thinking about the sucky things with SNMP, the Simple Network Management Protocol. One of the bigger problems, in my not so humble opinion, is the compleet lack of any security. I know, you can use the Community Strings to specify what people have access to. Several problems abound with this approach, but it boils down to a complete lack of basic security:
- No encryption; you just can’t do it.
- No authentication; you couldn’t do it securly, anyhow.
- Access control via publicly visible group-shared, non-credentialed ID; In other words, anyone on the network can detect the community names that are in use and then use them and there’s never going to be any way to stop them.
- In some cases, the ability to manage can not be disabled; this is a huge security hole.
Now, in defense of SNMP, one could use your firewalls to control packet flows and funnel them only towards the workstations you want. Though this can work in fixed environments, our network are becoming more and more fluid, dynamic and mobile every day, making this approach extremely difficult to maintain, at best. Another approach, often used in the real world, is to confine SNMP traffic to an issolated "management network", a physically separate network segment that is not interconnected with the rest of the network. One problem with this approach is that not all devices that one might want to monitor/manage have the ability to confine their SNMP activity to a particular port, especially those devices that aren’t network switches. SNMPv3, does have a user based access control mechanism (see RFC3414 (Standard 62) — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)), which does include provision to encrypt authentication related messages and an ACL mechanism RFC3415 (Standard 62) — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)). These security features are an improvement, however, only DES (in CBC mode, which is good for DES) is available for encryption. There is no cryptographically strong message integrity, either. Nowhere in the rest of the SNMPv3 RFCs RFC3411(, RFC3412, RFC3413, RFC3416, RFC3417, RFC3418 and RFC3584), is there any mention of any better encryption or cryptographic protections. At the very least, the lack of adequate protection in the user authentication process is a security hole so large as to render all security mechanisms in its design useless. At worst, people using RFC3414 authentication could have a false sense of security and expose extensive details about the operations (as well as full administrative control) of their infrastructures to anyone who can transfer packets in their network. The long and short of all this? I simply avoid SNMP in almost all situations. You can’t make it secure for managing anything and most of the benefits of SNMP, except one, can be acheived in other ways with most devices. The one exception is that SNMP is one, central way of dealing with lots of stuff. The protocol has been around for a long time and, of the top of my head, I don’t know of any vendor’s SNMP capable device that is not compatible in some way. Thus, I’ve often thought a little about how we might improve SNMP. In the past, I’ve decided that it would have been much better if SNMP had originally stood for Simple Network Monitoring Protocol. Most of the security concerns would simply disappear. If we "remove" the management or write capabilities from the SNMP specification, then we would have just such a monitoring protocol. But that will still leave us with some pretty ugly security concerns, not to mention confusing people if we still called it SNMP. So, here’s my list of desirable features:
- Authentication & Authorization Service
- Monitoring Output Configuration
- Multicast and/or Unicast
- Mixed use of TCP and UDP
Once a protocol like this is standardized, we could build upon it to create SNMPS (or SSNMP?), a secured form of SNMP for management operations. I think it shouldn’t have the monitoring elements, as LMNOP would cover monitoring. In that case, devices and applications which want to use both monitoring and management features should implement support for both LMNOP and SNMPS. There might be a new RFC to write for this idea. I’ve never done that before. Perhaps I will. Whether I do or not, I thought the acronym was worth writing down.