Securing SNMPD with Access Control
Available Access Control methods
The SNMP daemon provided by the net-analyzer/net-snmp package offers four distinct methods of controlling which users have which kinds of access and to which parts of the MIB tree.
Community-Based Access Control
Traditional or community based access control is the only supported access control method available when using SNMPv1 or SNMPv2c. It provides simple access control based around the concept of a community identifier. Clients which connect using community based authentication are required to provide a community identifier which is then used to allow or deny access depending on the configuration.
As the community identifier is usually identical for all clients and is transmitted in plain-text over the network this authentication method only offers a bare minimum level of security and should therefore never be used over the public Internet or on an untrusted network, especially to provide write access.
User-Based Security Model (USM)
SNMPv3 introduced the concept of users to the traditional access control model. Unlike community identifiers, which are usually identical across clients and transmitted in clear-text, users are intended to be unique and can make use of advanced authentication features and optional encryption.
The User-Based Security Model (USM) offers three security levels.
- noAuthNoPriv
- The noAuthNoPriv level provides no authentication or privacy. This security level is therefore compatible with SNMPv1 or SNMPv2c clients.
- authNoPriv
- The authNoPriv level provides user authentication but no privacy. This security level is often used over trusted networks where authentication is desired but the overhead of encryption and decryption of every packet is not.
- authPriv
- As expected the authPriv security level provides user authentication and privacy. This security level is often used over untrusted networks where authentication is desired and privacy of the transmitted data is also essential.
View-Based Access Control Model (VACM)
The View-Based Access Control Model (VACM) adds the concept of views and groups to the USM authentication infrastructure. A view may be defined to include either the entire OID tree or a subset of the tree and access may be restricted to a particular community or group of users.
Typed View-Based Access Control Model (TVACM)
The Typed View-Based Access Control Model (TVACM) extends the VACM by providing the concept of types of view. Currently the Typed View-Based Access Control Model (TVACM) is beyond the scope of this document and will not be discussed further here.
Using SNMPv1 and SNMPv2 Community-Based Authentication
We have already configured very basic Community-Based Authentication in the Installing the SNMP software section of this document. The most basic configuration directives used to define a read-only community are shown below. The rocommunity directive declares a read-only community for clients connecting using the IPv4 protocol, while the rocommunity6 directive declares a read-only community for clients connecting using the IPv6 protocol.
rocommunity COMMUNITY [SOURCE [OID]]
rocommunity6 COMMUNITY [SOURCE [OID]]
As you can see the only required parameter is the community identifier which must be supplied by clients for authentication to succeed. Access can be further limited by specifying a source address mask restricting clients to particular network addresses. An OID can also be specified restricting access to a single branch of the MIB tree. Multiple entries may be present if required to express the full range of authentication options and the first entry which matches the client request will be used.
For forward compatibility with SNMPv3 VACM the rocommunity configuration directive can also be used to specify access to a particular named view, as shown below. When defining a read-only community which provides access to a named view the source address mask is mandatory.
rocommunity COMMUNITY SOURCE -V VIEW
rocommunity6 COMMUNITY SOURCE -V VIEW
Using SNMPv3 User-Based Authentication
Creating a USM user
The SNMPv3 User-Based Security Model (USM) uses the createUser configuration directive to specify the login details for a user. As you can see from the example below the syntax is fairly straightforward requiring, at minimum the name of the user, the type of message digest which the password should be encrypted with and the password. Optionally the desired encryption routine for network communication may be specified and, if desired, an additional private pass phrase used to compute the encryption keys. If no encryption routine is specified then the default will be to not support encryption therefore limiting the clients to authentication only. By default the encryption pass phrase will be the same as the authentication password if none is specified.
createUser [-e ENGINEID] username (MD5|SHA) authpassphrase [DES|AES] [privpassphrase]
The example below demonstrates how to add a new user called max with a password using an SHA message digest. We have specified a rather insecure password of "password", which should clearly be changed. We have also specified that we wish client connections to be able to make use of AES encryption to ensure network level security and that the encryption key should be derived from "secret string" rather than the user's password.
As you can see, the first step is to stop the SNMP daemon. If the /var/lib/net-snmp/snmpd.conf is edited while the SNMP daemon is running it will be overwritten the next time the daemon is started. Once the SNMP daemon has been stopped the next step is to add a createUser entry to the persistent configuration file located at /var/lib/net-snmp/snmpd.conf so that the user will be created when the SNMP daemon is started.
createUser max SHA "password" AES "secret string"
Once the createUser directive has been added to the persistent configuration file the SNMP daemon can be started, as shown below.
We can verify that the new user has indeed been created by using the grep utility to search the persistent configuration file for the usmUser string as shown below.
usmUser 1 3 0x80001f88807d7704671a87784e 0x6d617800 0x6d617800 NULL .1.3.6.1.6.3.10.1.1.3 0xc8b8e818f3957026a3dfe6d9195b575a852918be .1.3.6.1.6.3.10.1.2.4 0x33931b3664b5d04fad48023bfd7c04e0 ""
Granting a USM user access
Now that we have successfully created a new USM user we can configure access rights to allow this user to interact with the SNMP daemon. To grant read only access to a user the rouser directive may be used while to grant read / write access to a user the rwuser directive should be used. The syntax of the rouser and rwuser directives is shown below.
rouser USER [noauth|auth|priv [OID]]
rwuser USER [noauth|auth|priv [OID]]
As you can see, the only required parameter is the username to which this directive applies. Optionally the minimum security level may be specified (with auth being the default). As with Community-Based Authentication an OID may be specified restricting this user to a particular branch of the MIB tree. Multiple rouser and rwuser directives may be used for a single user to fully describe the desired access control requirements with the first matching rule being used.
rouser max priv
The example above declares that the user identifying themselves as max will be allowed full read only access to the entire MIB tree and that they must use both authentication and encryption. Once the correct directives have been added to the daemon configuration file to implement the access controls you desire the configuration must be reloaded as shown below.
Testing USM user access
With our newly created user in place and access granted as desired we can now test the configuration using the snmpwalk utility (or indeed any of the other utilities provided in the net-analyzer/net-snmp package), as shown below.
SNMPv2-MIB::sysDescr.0 = STRING: "An SNMP enabled device"
Assuming that the test worked we can greatly reduce the typing overhead on future invocations of the command by setting some local defaults, as shown in the example below.
defSecurityName max
defAuthType SHA
defSecurityLevel authPriv
defAuthPassphrase "password"
defPrivType AES
defPrivPassphrase "secret string"
defVersion 3
The defaults values specified will be automatically used by all of the utilities provided in the net-analyzer/net-snmp package allowing the above command to be executed using the much simpler code below.
SNMPv2-MIB::sysDescr.0 = STRING: "An SNMP enabled device"
Using the View-Based Access Control Model (VACM)
The View-Based Access Control Model (VACM) is much more complex than either of the previous two authentication models consisting of users (which are defined using exactly the same syntax as when using the User-Based Security Model described above), groups which may contain more than one user (or com2sec community mappings for backward compatibility with SNMPv1 and SNMPv2c), views which describe collections of MIB objects and access directives which provide groups access to views.
The example configuration below creates four distinct groups. The first group is named limited_grp and will be used by the com2sec mapping above which maps all requests for the public community to the limited user. The second and third groups, named hw_admin_grp and sw_admin_grp are used by hardware and software administrators (john and holly) respectively. The fourth and final group, named management_grp, is used by managers (max).
The next block of statements declares the three views. The first is named basic_view and only includes the branch starting at SNMPv2-MIB::system. The second view, named hardware_view, provides access to all hardware related information (although in the case of our example this is actually limited to the LM-SENSORS-MIB::lmSensors branch for brevity) while the third and final view provides access to all software related information (again, our example only provides access to the UCD-SNMP-MIB::systemStats branch). Clearly, in a real configuration more of the MIB tree would need to be accessible and therefore more included entries would be needed for each view.
# Mappings between community strings and security names
# security name source mask community id
com2sec limited 10.0.0.0/8 public
# Mappings between security names and group names
# group name security model security name
group limited_grp v1 limited
group limited_grp v2c limited
group hw_admin_grp usm john
group sw_admin_grp usm holly
group management_grp usm max
# View definitions
# view name included/excluded subtree
view basic_view excluded .iso
view basic_view included SNMPv2-MIB::system
view hardware_view excluded .iso
view hardware_view included LM-SENSORS-MIB::lmSensors
view software_view excluded .iso
view software_view included UCD-SNMP-MIB::systemStats
# Access control directives
# group name context model level match read write notify
access limited_grp "" any noauth exact basic_view none none
access hw_admin_grp "" usm priv exact hardware_view none none
access sw_admin_grp "" usm priv exact software_view none none
access management_grp "" usm priv exact all none none
The final block of statements grants access for the named groups to the named views and provides additional information relating to the security requirements of the connection. The first line provides unauthenticated read access to the basic_view for any members of the limited_grp, which in our example is any client using the SNMPv1 or SNMPv2c community based authentication. The remaining lines provide read access to the hardware_view for members of the hw_admin_grp group, read access to the software_view to members of the sw_admin_grp group and finally read access to all views to members of the management_grp group. We also specify, by using priv for the security level, that all views besides the basic_view view may only be accessed over an encrypted connection after authentication.