snmpd supports the View-Based Access Control Model (VACM) as defined in RFC 2575, to control who can retrieve or update information. To this end, it recognizes various directives relating to access control.
Traditional Access Control
Most simple access control requirements can be specified using the directives rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for SNMPv1 or SNMPv2c).
rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]rwuser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
specify an SNMPv3 user that will be allowed read-only (GET and GETNEXT) or readwrite (GET, GETNEXT and SET) access respectively.
By default, this will provide access to the full OID tree for authenticated (including encrypted) SNMPv3 requests, using the default context.
An alternative minimum security level can be specified using noauth (to allow unauthenticated requests), or priv (to enforce use of encryption). The OID field restricts access for that user to the subtree rooted at the given OID, or the named view. An optional context can also be specified, or "context*" to denote a context prefix. If no context field is specified (or the token "*" is used), the directive will match all possible contexts.
rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
specify an SNMPv1 or SNMPv2c community that will be allowed read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET) access respectively.
By default, this will provide access to the full OID tree for such requests, regardless of where they were sent from.
The SOURCE token can be used to restrict access to requests from the specified system(s); see com2sec for the full details.
The OID field restricts access for that community to the subtree rooted at the given OID, or named view. Contexts are typically less relevant to community-based SNMP versions, but the same behavior applies here.
rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
are directives relating to requests received using IPv6 (if the agent supports such transport domains). The interpretation of the SOURCE, OID, VIEW and CONTEXT tokens are exactly the same as for the IPv4 versions.
In each case, only one directive should be specified for a given SNMPv3 user, or community string. It is not appropriate to specify both rouser and rwuser directives referring to the same SNMPv3 user (or equivalent community settings). The rwuser directive provides all the access of rouser (as well as allowing SET support). The same holds true for the community-based directives.
More complex access requirements (such as access to two or more distinct OID subtrees, or different views for GET and SET requests) should use one of the other access control mechanisms. Note that if several distinct communities or SNMPv3 users need to be granted the same level of access, it would also be more efficient to use the main VACM configuration directives (see below).
VACM Configuration
The full flexibility of the VACM is available using four configuration directives -
com2sec,group, view and access. These provide direct configuration of the underlying VACM tables.
com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITYcom2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
map an SNMPv1 or SNMPv2c community string to a security name, either from a particular range of source addresses or globally ("default"). A restricted source can either be a specific hostname (or address), or a subnet; represented as IP/MASK (e.g.10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or the IPv6 equivalents.
The same community string can be specified in several separate directives (presumably with different source tokens), and the first source/community combination that matches the incoming request will be selected. Various source/community combinations can also map to the same security name.
If a CONTEXT is specified (using -Cn), the community string will be mapped to a security name in the named SNMPv3 context. Otherwise the default context ("") will be used.
com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
is the Unix domain sockets version of com2sec.
group GROUP {v1|v2c|usm|tsm|ksm} SECNAME
maps a security name (in the specified security model) into a named group. Several group directives can specify the same group name, allowing a single access setting to apply to several users and/or community strings.
Note that groups must be set up for the two community-based models separately: a singlecom2sec (or equivalent) directive will typically be accompanied by two group directives.
view VNAME TYPE OID [MASK]
defines a named "view" - a subset of the overall OID tree. This is most commonly a single subtree, but several view directives can be given with the same view name (VNAME), to build up a more complex collection of OIDs. TYPE is either included or excluded, which can again define a more complex view (e.g. by excluding certain sensitive objects from an otherwise accessible subtree).
MASK is a list of hex octets (optionally separated by '.' or ':') with the set bits indicating which sub identifiers in the view OID to match against. If not specified, this defaults to matching the OID exactly (all bits set), thus defining a simple OID subtree.
Examples
view iso1 included .iso 0xf0 view iso2 included .iso view iso3 included .iso.org.dod.mgmt 0xf0
These directives would all define the same view, covering the whole of the iso(1) subtree (with the third example ignoring the sub identifiers not covered by the mask).
More usefully, the mask can be used to define a view covering a particular row (or rows) in a table, by matching against the appropriate table index value, but skipping the column sub-identifier:
view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0
Note that a mask longer than 8 bits must use ':' to separate the individual octets.
access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY
maps from a group of users/communities (with a particular security model and minimum security level, and in a specific context) to one of three views, depending on the request being processed.
LEVEL is one of noauth, auth, or priv. PREFX specifies how CONTEXT should be matched against the context of the incoming request, either exact or prefix.
READ, WRITE and NOTIFY specifies the view to be used for GET*, SET and TRAP/INFORM requests (although the NOTIFY view is not currently used). For v1 or v2c access, LEVEL will need to be noauth.
Typed-View Configuration
The final group of directives extends the VACM approach into a more flexible mechanism, which can be applied to other access control requirements. Rather than the fixed three views of the standard VACM mechanism, this can be used to configure various different view types. As far as the main SNMP agent is concerned, the two main view types are read and write, corresponding to the READ and WRITE views of the main access directive.
authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
is an alternative to the rocommunity/rwcommunity directives. TYPES will usually be read or read/write respectively. The VIEW specification can either be an OID subtree (as before), or a named view (defined using the view directive) for greater flexibility. If this is omitted, then access will be allowed to the full OID tree. If CONTEXT is specified, access is configured within this SNMPv3 context. Otherwise the default context ("") is used.
authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
is an alternative to the rouser/rwuser directives. The fields TYPES, OID, VIEW and CONTEXT have the same meaning as for authcommunity.
authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
is a companion to the authuser directive, specifying access for a particular group (defined using the group directive as usual). Both authuser and authgroup default to authenticated requests - LEVEL can also be specified as noauth or priv to allow unauthenticated requests, or require encryption respectively. Both authuser and authgroup directives also default to configuring access for SNMPv3/USM request. Use the -s flag to specify an alternative security model (using the same values as for access above).
authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
also configures the access for a particular group, specifying the name and type of view to apply. The MODEL and LEVEL fields are interpreted in the same way as for authgroup. If CONTEXT is specified, access is configured within this SNMPv3 context (or contexts with this prefix if the CONTEXT field ends with '*'). Otherwise the default context ("") is used.
setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
is a direct equivalent to the original access directive, typically listing the view types as read or read/write as appropriate. All other fields have the same interpretation as with access.