SNMPv3 is the successor to the more commonly deployed SNMPv2c. While the underlying structure of MIBs & OIDs are not impacted by v3, the way those objects are accessed are. While SNMPv2c offers read-only and read-write community strings (essentially passwords) to secure access to the device MIB, the data flow was in plaintext, easily readable by anyone in the data path with a sniffer. SNMPv3 offers a an authentication and encryption scheme that, should you so desire, the SNMP data flowing between the querying workstation and network device can be completely hidden to prying eyes.
With most technology networking uses, additional power comes with a penalty of additional configuration steps. And so it is that SNMPv3 is a bit more complex to configure than SNMPv2c. The security model moves from simple community strings to User Security Model (USM). Users defined by USM are then assigned specific rights to access some or all of the MIB tree. User authentication and encryption methods are also defined.
High Level Steps
Once you wrap your brain around the basics of what SNMPv3 does and the mechanisms it’s using to do it, it’s not so daunting.
- You need to create a user.
- You need to define how the user will authenticate, and whether or not their communications will be encrypted.
- You need to create a view. That is, you need to create a list of OID objects and describe whether they will be included (or excluded). Like an access list, a view by itself does nothing. The view must be applied to something, which is done next.
- You need to create a group and apply a view to the group.
- You need to assign the user to the group.
Taking a step back from this seemingly convoluted process, recognize that SNMPv3 security follows a scheme for typical hierarchical object management. Create some set of rights. Assign those rights to a group. Put individual users in the group. While different network devices implement this scheme in roughly the same way, I haven’t seen any two network devices look exactly alike when it comes to SNMPv3. But if you remember what’s going on in the background, it can be helpful.
Building The Template
My first brush with SNMPv3 on any device is often tricky. For instance, getting the keys pasted into a Cisco ASA configuration the way it wanted was always confusing. Getting any sort of result back from a Cisco IOS device was hard the first time around. And Junos was no exception, in no small part because the documentation is a bit scattered. You have to drill around to many different pages and read through all of the command hierarchies and definitions to get it right. Plus, the Junos SNMPv3 “minimum configuration” isn’t minimum at all. There’s substantially more configuration than you actually need, depending on your goals. But since the Junos doc doesn’t start out by telling you what the configuration actually achieves, it’s hard to tell what’s important and what’s not until you’re more familiar with the individual commands.
Another frustration I ran into is that the Junos SNMP implementation changes if you are implementing routing instances. You can NOT query a non-default routing instance without creating a special context qualifier in the query, which I have yet to determine exactly how to format (see below in the quote about this, I just haven’t played with it enough yet). This doc about SNMP and routing instances in a FAQ contained the quote below that was absolutely critical to understanding why I could authenticate to the SNMP engine, but not get any data back when querying an IP address attached to a non-default routing instance.
Can the SNMP manager access data for routing instances?
Yes, the Junos OS enables SNMP managers for all routing instances to request and manage SNMP data related to the corresponding routing instances and logical system networks.
Two different routing instance behaviors can occur, depending on where the clients originate:
- Clients from routing instances other than the default can access MIB objects and perform SNMP operations only on the logical system networks to which they belong.
- Clients from the default routing instance can access information related to all routing instances and logical system networks.
Routing instances are identified by either the context field in SNMPv3 requests or encoded in the community string in SNMPv1 or SNMPv2c requests.
When encoded in a community string, the routing instance name appears first and is separated from the actual community string by the @ character.
I knew I was having an access issue because of the response I’d get back when attempting an SNMP get as so:
workstation:~ ebanks$ snmpget -v3 -u USERNAME -l authPriv -a SHA -A PASSWORD -x AES -X ENCRYPTKEY hostname.mycompany.com sysDescr.0
Error in packet
Reason: authorizationError (access denied to that object)
This is the result I’d get when running the get against an IP in a non-default routing instance. As soon as I lit up an IP in the default routing instance, this same query immediately worked. Assuming the same command above, the output I’d receive instead was as follows:
SNMPv2-MIB::sysDescr.0 = STRING: Juniper Networks, Inc. mx80 internet router, kernel JUNOS 11.4R7.5 #0: 2013-03-01 10:32:43 UTC email@example.com:/volume/build/junos/11.4/release/11.4R7.5/obj-powerpc/bsd/kernels/JUNIPER-PPC/kernel Build date: 2013-03-01 09:35:45 UTC Copyri
Junos SNMPv3 Baseline Code Example
That was a lot of background information to get to the actually code I settled on, but here we go. What the code below does is allow a remote SNMP station (like SolarWinds, Observium or your CLI tools) to query any SNMP OID on a device running Junos. This has been tested on an MX router running 11.4R7.5. Comments inline, plus I highlighted certain object names in color so that you could see how they are related throughout the configuration.
# Define the username and set the authentication password. Here, we’re using SHA, but MD5 is also an option.
set snmp v3 usm local-engine user MYSNMPUSER authentication-sha authentication-password MyAuthPassword
# Set the privacy password. Here, we’re using AES-128, but DES, 3DES, high bit AES, and even no encryption might be options, depending on the device you’re using.
set snmp v3 usm local-engine user MYSNMPUSER privacy-aes128 privacy-password MyPrivPassword
# Assign the user MYSNMPUSER to the group ALL-ACCESS (defined next).
set snmp v3 vacm security-to-group security-model usm security-name MYSNMPUSER group ALL-ACCESS
# Assign a view for read, write, and notify of the ALL-ACCESS group. You may or may not need write or notify, depending on what you’re trying to do. I’m not using notifies in this configuration, so I don’t actually need the third line below. I just put it in for reference. Note that the GLOBAL view is defined below.
set snmp v3 vacm access group ALL-ACCESS default-context-prefix security-model usm security-level privacy read-view GLOBAL
set snmp v3 vacm access group ALL-ACCESS default-context-prefix security-model usm security-level privacy write-view GLOBAL
set snmp v3 vacm access group ALL-ACCESS default-context-prefix security-model usm security-level privacy notify-view GLOBAL
# In almost all SNMP configurations I’ve build, the SNMP engine ID is assigned automatically. However, Junos documentation insists that you have to have the statement in the configuration. The command provides a few other choices to identify the engine, including MAC address. I haven’t actually tried to run an SNMP query without this command.
set snmp engine-id use-default-ip-address
# Create a view called GLOBAL, and include the oid “internet” in it. “Internet” in this context is a plaintext way to describe OID 18.104.22.168. Practically speaking, this translates to everything of value in the MIB tree.
set snmp view GLOBAL oid internet include
Other configuration options include the configuration of SNMP notifications (i.e. traps or informs) and limiting what IP addresses can access the SNMP engine. I am no longer inclined to filter SNMP queries by IP address, as you need more than just an easily stolen community string to access the engine. You need a user name, authentication password, and encryption key. If an malicious user has access to that information, faking an appropriate IP address should be trivial. I don’t see the point except in highly secured environments where such controls might be required. I rather like being able to perform SNMP queries from any part of the network using encrypted SNMPv3. Convenient, yet secure.
Also note that SNMPv3 is not exclusive of SNMPv2c. You can run both at the same time if you wish.
SNMPv3 – Do It Now (packetpushers.net)