MIB (Management Information Base)
Objects that could be polled or configured by a manager are organized in a MIB (Management Information Base). The MIB is organized in a hierarchical fashion with objects at the end of the tree. Objects are mapped or named using OID (Object Identifiers) which are displayed in a dotted integer format. The integers map the parameter from the top level of the hierarchy through the tree. For example 22.214.171.124.2.2.1 would be the system objects under the MIB-II category. See the picture below for a graphical view (keep in mind that this is only showing a portion of the entire MIB tree).
MIB-II & Private MIBs
The OIDs under the MIB-II branch are defined by the SNMP standard. Common objects such as "sysName" or "sysContact" are located here. The webpage oid-info.com/get/126.96.36.199.2.1 is a great place to browse the avaliable objects under the MIB-II category. As mentioned above, private OIDs can be used by vendors. The OID used by vendors for private use is 188.8.131.52.4 (as you can see in the image above). The OID 184.108.40.206.4.1.2636 220.127.116.11.4.1.2636 is specifically used by Juniper Networks. The webpage Juniper Networks Enterprise-Specific-MIBs outlines the various objects Juniper has created for their products.
SNMP uses specific types of messages to send and receive information. The three main messages are 'GET', 'SET' and 'TRAP' (there are additional messages such as GETNEXT, however this detail isn't necessary for this post.)
GET: Is a message type where a manager would send a request to the agent. The OID would be used to specify which object the manager wished to query.
SET: Is a message type where a manager would set or modify an object on the agent. Again, the OID would be used to specify which object the managed wished to set/modify.
TRAP: Is a message type where the agent alerts the manager of an event.
In SNMPv1 the concept of communities is used. These communities can be thought of as passwords. The protocol supports a two communities one for 'read' and another for 'read&write' permissions. SNMPv2c uses the same community and message structure as SNMPv1 with the addition of more message types.
I find the explanation of SNMPv3 to be confusing but at the simplified level SNMPv3 maintains all of the same message types as SNMPv1/v2c with the addition of security.
The same basic lab topology will be used for these exercises.
The image below outlines the basic SRX SNMP configuration. Standard parameters such as 'name' and 'location' are set. The SNMP read and read/write communities (passwords) are defined. Also we have used the 'clients' option under the read/write community to only accept SNMP requests from the specified host of 192.168.1.108. Alternatively we could use a firewall filter on an interface to accomplish this as well. Lastly we need to allow the SNMP protocol under host-inbound-traffic.
Below is how the configuration appears.
Using the resrouces listed above we know that 18.104.22.168.4.1.2636 is the Juniper private MIB. The command 'show snmp mib walk' can be used to display all of the OIDs.
This command can also be used to display the SNMP MIB-II defined OIDs.
To test the configuration we will use Net-SNMP and will use the sysContact object under MIB-II for demonstration.
The wireshark captures below outline the SNMP request that was made for the sysContact OID.
The following commands were used to configure SNMPv3 on the SRX100:
set snmp v3 usm local-engine user v3user authentication-md5 authentication-password simplepass
set snmp v3 usm local-engine user v3user privacy-des privacy-password simplepass
set snmp v3 vacm security-to-group security-model usm security-name v3user group v3group
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy read-view snmpview1
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy write-view snmpview1
set snmp v3 vacm access group v3group default-context-prefix security-model any security-level privacy notify-view snmpview1
set snmp view snmpview1 oid 1.*
The first two commands configure a user 'v3user' and assign authentication and encryption settings with passwords. The next commands configure a security group and adds the user 'v3user' to this group. The next three commands configure parameters of the security group. The privacy statement ensures that authentication and encryption are used for this security group. Also the access this security group has is defined by the view of 'snmpview1'. We used a wildcard in snmpview1 to allow any OID, you could apply a detailed policy here to allow/deny certain OIDs. The following diagram helps to outline a simplified description of SNMPv3 configuration.
To test the configuration we will use the same sysContact object under MIB-II as we demonstrated with the previous exercise.
The following wireshark capture outlines the SNMPv3 request. Notice that the PDU messages are now encrypted.