SNMP Security and SNMPv3

This section describes briefly the security aspects for SNMP requests specifically about authentication and authorization. The authentication mechanism is built into Net-SNMP

  • Authentication in SNMP Versions 1 and 2c is provided by a password (community string) sent in clear text between a manager and agent.

  • SNMP v3 defines a number of security-related capabilities. The initial specifications defined the USM and VACM, which were later followed by a transport security model that provided support for SNMPv3 over SSH and SNMPv3 over TLS and DTLS.

The Net-SNMP build used by netconfd-pro must include the TSM security model and the required TLS or DTLS transport to accept SNMPv3 TSM requests. Configure the listener using the Net-SNMP agentaddress setting in snmpd.conf; for example, agentaddress dtlsudp:localhost:161 selects a DTLS-over-UDP listener on port 161. This replaces the default UDP listener unless additional endpoints are specified. Configure the certificate-to-security-name mapping and VACM group/access rules in the same Net-SNMP configuration, using security model tsm. NACM continues to control access to YANG data.

Listener directives are cumulative: use comma-separated endpoints on one agentaddress line or repeat the directive to enable multiple listeners. The spelling agentAddress is also accepted.

SNMP uses Net-SNMP's certSecName directive. In snmpd.conf, certificate transport options require the [snmp] section prefix, for example [snmp] localCert ... and [snmp] trustCert .... The netconf-tls-certificate, netconf-tls-key, and cert-usermap server parameters configure NETCONF TLS, not SNMP TSM. A plain udp: listener cannot accept DTLS; configure dtlsudp: or tlstcp: explicitly and use the matching transport in the manager command.

TLS/TCP protocol support is also constrained by the linked Net-SNMP transport and the OpenSSL security policy. For example, Net-SNMP 5.9.1 limits its TLS/TCP server to TLS 1.0; OpenSSL policies that disallow TLS 1.0 will reject that connection before SNMP processing. Use a compatible Net-SNMP/OpenSSL combination rather than weakening the system security policy.

Warning

Net-SNMP 5.9.1 performs a blocking TLS handshake when accepting a tlstcp: connection. A client that connects without completing the handshake can hold snmp_read2() and delay other work in the netconfd-pro server loop until the connection closes. The select timeout used by the server does not bound this handshake. Use dtlsudp: where appropriate, or restrict the TLS/TCP port to trusted managers with a firewall. Certificate authentication alone does not prevent this stall, which occurs before authentication completes.

netconfd-pro implements NACM (NETCONF Access Control Model) to manage and control the access to YANG objects supported by the device. Since NACM already provides the authorization, VACM has to be disabled when processing SNMP v3 read requests. SET additionally requires the Net-SNMP write view to permit every requested OID before NACM edit permissions are checked. More information about the configuration and management of Net-SNMP authentication is available on-line as part of Net-SNMP documentation.

NACM Read and Write Identities

For compatibility, SNMP GET, GETNEXT, and GETBULK requests use the shared NACM user name snmp, including requests authenticated through TSM. Certificate mapping authenticates the connection and supplies the Net-SNMP security name; it does not select a per-certificate NACM read identity. Configure NACM read permissions for snmp. Granting read permissions only to the certificate-mapped security name is not sufficient. All admitted SNMP readers share those read permissions.

SET requests instead use the request's Net-SNMP security name for NACM edit authorization. For TSM, this is the name produced by certSecName. SET must also pass the Net-SNMP write-view check. A read-only rouser does not acquire write permission from NACM.

When a rwuser or rwcommunity rule omits its OID subtree or named view, it uses the standard _all_ view. This permits all OIDs at the Net-SNMP view layer; NACM and the SIL still control whether edits succeed. Specify a subtree or named view to restrict the write scope.

When upgrading from a release that did not initialize _all_, audit existing write rules with no subtree or named view: requests that previously failed the write-view check may now pass that check. Keep explicit write subtrees or named views and verify NACM edit permissions. Community rules can also restrict the manager's source address. The sample configuration limits writes to ifAdminStatus and limits the write community to loopback; SNMPv3 rwuser rules have no source-address argument, so use a firewall when a source restriction is required.

Use an agent-specific configuration, not an unchanged standalone snmpd.conf. Stock snmpd instrumentation directives such as proc, disk, and extend are not provided by this integration.

Security Configuration Files

Net-SNMP makes use of 2 configuration files to control its operation and the management information provided.

  1. /var/net-snmp/snmpd.conf

    • This file contains the SNMP v3 specific configuration related to allowed user names and passwords.

  2. /usr/local/share/snmp/snmpd.conf

    • This file contains generic configuration information including SNMP v1 and v2c related community strings that perform basic authentication. If not found in the path specified before, the configuration file may be found in the /etc/yumapro/snmpd.conf.

Adding an SNMPv3 User

Adding a new SNMP v3 user can be performed by using the scripts available as part of Net-SNMP as below. The command below adds a user “admin” with authentication and privacy. Authentication makes use of SHA and the password for authentication is “password1”. Similarly for privacy, DES is used and the associated password for privacy is “password2”.

sudo net-snmp-config --create-snmpv3-user -ro -a SHA -A 'password1' -x DES -X 'password2' admin

Note

The netconfd-pro server must be stopped before running the above command. Once the command above is run, then the netconfd-pro can be run again which will make use of this updated configuration file.

Adding an SNMPv1/v2c User

SNMP v1 and v2c make use of community strings for authentication. The allowed community strings along with the access permissions is configured in the 'snmpd.conf' file. The tokens that control these parameters are “rocommunity” for read only access and “rwcommunity” for read-write access.

For SET, configure a write-enabled user rather than the read-only user in the example above. The security name must also have the required NACM permissions; a write-enabled Net-SNMP user does not bypass NACM. See SNMP SET Operations.