This blog post is about SNMPv3, and why you should be using it instead of SNMPv1/v2c on your network. It is not about SNMP in general – most readers will have a pretty good idea of what it does, and why/where/how you should use it. If you’re not familiar with it, you may want to take a look at some of the many resources available online.
SNMP currently has 3 main versions – v1, v2c and v3. Pretty much everything that says “supports SNMP” on the tin will support v1 and v2c. This provides a very handy protocol for retrieving all sorts of wonderful information from the systems running on your network. Routing tables, interface status, uptime, versions, etc. If you’re extra brave, you can also use it to make changes to systems – using SNMP “set” calls to do things like change switchport VLANs, reboot systems, etc.
The problem with the earlier versions (v1 and v2c) is that their security model is almost non-existent. (Yes, there were attempts to improve security with v2, but pretty much everyone just uses v2c). In order to retrieve (snmpget) or set (snmpset) an OID value, all you have to do is provide the right community string. This acts as a simple password. This is passed in cleartext – i.e. no real authentication at all. Consider this snippet from a packet capture:
(Packet capture from the library at Packetlife.net)
It might be a tricky to see here – click the image to see the Cloudshark-hosted packet capture. This is a very nice tool that works like Wireshark in your browser. But the key point in the highlighted section above is that we can see the community string (R0_CActi!) in plaintext in that output. We can also see all values being passed between the managed node and management server. Not good. To make things worse, there’s plenty of systems that respond to “public” and “private” community strings out of the box, and no-one changes it. You and I change vendor-supplied defaults, but it seems many of our colleagues do not. That’s probably a different discussion though.
But does it really matter? Who’s sniffing my network traffic anyway? Maybe they don’t need to intercept traffic – maybe your network discovery tools are just broadcasting it to everyone. Typical behaviour for NMS systems doing auto-discovery is to cycle through a list of known community strings when trying to find new systems. You could of course say, “Well, who cares if someone else can see my current memory utilisation on my routers? Besides, I use ACLs to restrict management stations.” Fair enough. ACLs are highly recommended for SNMP. But what if you’ve got SNMP read-write configured? And remember it’s UDP, so I could easily fake my source IP. Do you have proper anti-spoofing rules configured everywhere in your network, along with a separate management network? Would they help anyway? Even if you only have read-only, it can be depressingly easy to max out the CPU on low-end systems with a few snmpwalks.
Enter SNMPv3. Standardised in RFCs 3411-3418, and recognised by the IETF as the “current standard version of SNMP,” it soundly deals with the problems of simple authentication, and data passed in the clear. SNMPv3 doesn’t change the protocol, apart from introducing proper message security. It gives us Confidentiality, Integrity and Authentication. Sweet. Initial implementations offered MD5 for authentication/integrity, and DES for encryption. Later additions include SHA-1, 3DES and AES, but these are not as widely supported (see more below).
Systems need to have SNMP users configured. It’s not enough to just have a community string – you need a username, and then you can define separate passphrases for encryption and authentication. Depending on the system, you’ll also need to define the encryption/hashing method. This does make things a bit more complicated to setup, but there’s real benefits – see the packet captures below.
This capture shows the use of both authentication and encryption – note that Wireshark can decode some parts of the message structure, but it can’t decode the full message contents:
This section shows something a little bit different – authentication without encryption. You may not care in the least who knows what interface utilisation you have on switch 13, interface G0/21. But you don’t want just anybody running queries. SNMPv3 gives you the option to choose just what you want out of authentication and encryption. In this capture, the actual data returned in the SNMP get response is in plaintext.
(Packet captures from the Wireshark library)
Note that some systems will let you configure “noAuth noPriv” – i.e. no authentication, and no encryption (privacy), but I’m not really sure why you would…
Configuration is a little more complicated than SNMPv2, but it’s not too difficult. You’re using templates, and configuration management tools anyway, right? Right? Well, maybe configuration management tools are a topic for another day.
Here’s an example configuration for Cisco IOS – the main point to note is that you also need to define views and groups – you can’t just define a user in one line:
access-list 99 permit 172.16.2.100
snmp-server view V3View iso included
snmp-server group V3Group v3 auth read V3View
snmp-server user V3User V3Group v3 auth sha strongpassword priv aes 128 complexpassword access 99
This config defines an access list used to restrict SNMP access. It sets up a view – you can limit a view to specific parts of the MIB if you wish. A group is defined, to map that view to users. The group can allow read access, write access, or both. It can also restrict the version – in this case it’s just for v3. Finally the user is defined, along with authentication and privacy tokens. Access lists can be applied to either the user or the group. Note that SNMP users will not show up in the running config – you can see them with “show snmp user”.
For some reason, SNMPv3 configuration on RHEL requires the net-snmp-devel package. Red Hat has more documentation on configuring SNMP.
SNMPv3 can of course also be used for traps as well as SNMP polling.
One rather frustrating thing with SNMPv3 is that it’s still not as well supported as it should be. Low-end gear is hit and miss as to whether it supports it or not, while expensive kit may support it, but only with MD5/DES. E.g. Check Point supports SNMPv3 on SecurePlatform, but it appears to be only with MD5/3DES. No SHA-1/AES. NMS systems are similar – e.g. Nagios supports SHA-1/AES, but others like Zabbix only support MD5/3DES. Meanwhile, it appears the standard agent on Windows 2008 doesn’t support SNMPv3 at all. There’s other ways of managing your Windows Server fleet anyway. Cisco support is generally very good, including supporting AES-256, which very few other systems seem capable of.
Make sure you know what your systems support before you start rolling out SNMPv3, and hit up your vendors if they don’t support it as well as they should. They’ve had enough time to get it sorted out…