Thursday, 25 October 2012

System Services - SNMP

SNMP (Simple Network Management Protocol) is a client/server protocol used for querying and setting parameters or objects on a device. Versions 1, 2c and 3 exist for this protocol. SNMPv1 and SNMPv2c are similar, the main difference being that some extensions were added into v2c. SNMPv3 provides additional features to provide security to the protocol. SNMPv1 and v2c are criticized from a security perspective as the passwords and data are passed in clear-text format. The term managers and agents is used to describe the entities involved in SNMP (there are exceptions to these terms in SNMPv3, but we won't worry about these). A manager could be something like a NMS (Network management station) and a agent could be a device such as a Juniper SRX device.

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 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 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 (as you can see in the image above). The OID is specifically used by Juniper Networks. The webpage Juniper Networks Enterprise-Specific-MIBs outlines the various objects Juniper has created for their products.

SNMP Messages
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.

SNMP Versions
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.

SNMPv2c Configuration 
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 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 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.

SNMPv3 Configuration
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.
Below is a screenshot of the 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.

No comments:

Post a Comment