Chapter 4 Managing Security

This chapter provides background information, practical procedures, and examples related to security within the System Management Agent. With its SNMPv3 features, the System Management Agent provides an enhanced and configurable level of security for the management of users and network devices.

This chapter contains information on the following topics:

• Security Overview.

• Using USM for Authentication and Message Privacy.

• Using VACM for Access Control.

• Creating and Managing Users.

Security Overview

The System Management Agent supports SNMPv1, SNMPv2c and SNMPv3. The SNMPv1 and SNMPv2c authentication service is based on community strings defined on the management station. The SNMPv3 authentication service is based on users. Each request must contain either a community name or a user name depending upon the protocol being used.

The SNMPv3 authentication process implements the User-based Security Model (USM) to obtain a security name and security level from a user name. Similarly, both SNMPv1 and SNMPv2c determine the security level from the community string. The security name and security level are then used together with a context string, a group name and a view name to perform access control. Access control is done through the View-based Access Control Model, (VACM). This access control model is used after the authentication process. So, while USM is designed and used for authentication, VACM is designed and used for authorization.

For information about the supported versions of SNMP within the System Management Agent, see SNMP Versions.

Using USM for Authentication and Message Privacy

The User-based Security Model (USM) is used by the System Management Agent for authentication, encryption, and decryption of SNMPv3 packets. USM is used for the following reasons:

• Authentication of SNMP users

• Privacy of communication

• Integrity of messages

• Replay protection

The snmpusm utility is an SNMP application for basic maintenance of an SNMP agent's USM table. You must have write access to the usmUserTable MIB table. For more information, see the snmpusm(1M) man page.

The snmpusm subcommands are not supported for v1 or v2c versions of SNMP. Without proxying, only SNMPv3 users can execute these commands.

The agent enables you to manage user entries through the main snmpd.conf configuration file and by use of the snmpusm command, through the USM MIB. The USM MIB enables the System Management Agent to find information about the user, including whether the user exists. Every request from a user is checked against the USM MIB. If the user exists, the USM MIB checks the following permissions:

• Is the user allowed authenticated requests?

• What type of auth encoding is allowed?

The USM MIB uses the local store key to compute a new digest that is based upon the authentication protocol specified by a particular user in the MIB. The computed digest is compared to the digest saved from the incoming packet. If the digests are the same, the user is authenticated. For more information on message digests, see Authentication Protocol Algorithms.

The following list describes the USM settings:

User

Identifies the user that is authorized to communicate with the SNMP engine.

Authorization Type

Specifies the authentication protocol algorithm to be used: MD5 and SHA. For more information, see Authentication Protocol Algorithms.

Authorization Password

Specifies the user's authentication password. Passwords must consist of at least eight characters.

Privacy Type:

Specifies the privacy protocol to be used. For the System Management Agent, the privacy protocol is DES (Data Encryption Standard). For more information, see Message Privacy.

Privacy Password:

Specifies the user's privacy password. Passwords must consist of at least eight characters.

Security Level:

Indicates the security level of the user with regard to authentication and privacy:

noAuthNoPriv

Uses just the user name match for authentication.

authNoPriv

Provides authentication that is based on the MD5 or SHA1 algorithm.

authPriv

Provides privacy (encryption) based on the DES protocol.

Authentication uses a secret key to generate a MAC (Message Authentication Code) stored in msgAuthenticationParameters, which is part of usmSecurityParameters. Both the sending and receiving entities use the same secret key to produce the MAC. The message is therefore authenticated if both the sending and receiving MACs match.

Authentication Protocol Algorithms

In USM as implemented by the System Management Agent, two authentication protocols are supported. These authentication protocols are described in the following list.

HMAC-MD5–96

In the System Management Agent, the Message Digest implementation is HMAC-MD5–96. Based on MD5, this one-way encryption uses a 96–bit hash a 16 octet key length. Computationally, no two messages can have the same message digest. Also you cannot produce a message from a given prespecified target message digest. The MD5 algorithm is designed for digital signature applications. In these applications, large files must be securely compressed before being encrypted with a private key under a public-key cryptosystem. The HMAC-MD5–96 algorithm can be used with 32-bit machines. No large substitution tables are required. The algorithm can be coded quite compactly. For more information on MD5, see RFC 1321 at http://www.ietf.org/rfc/rfc1321.txt.

HMAC-SHA–96

In the System Management Agent, the Secure Hash Algorithm (SHA) implementation is HMAC-SHA–96. This one-way encryption uses a 96–bit hash and a 20–octet key length. The algorithm takes as input a message of less than 2⁶⁴ bits in length. The input message is processed in 512–bit blocks. The algorithm produces a 160-bit message digest output. This message digest can then, for example, be used as an input to a signature algorithm, which generates or verifies the signature for the message. The message digest is signed, instead of the message itself, which improves efficiency because the message digest is smaller than the original message. If the creator of a digital signature uses SHA, then the verifier of the digital signature clearly must also use SHA. If the message is changed during transit, this change almost always changes the message digest, so the digital signature fails to verify. SHA is secure because computationally no two messages can have the same message digest. You also cannot produce a message from a given prespecified target message digest. The design of SHA is similar to the MD5 family of hash functions. For more information on SHA, see RFC 3174 at http://www.ietf.org/rfc/rfc3174.txt.

For the System Management Agent, the default authentication protocol is HMAC-MD5–96. Setting is auth proto = MD5.

Message Privacy

USM supports privacy of messages. USM uses the CBC-DES Symmetric Encryption Protocol for encrypting and decrypting SNMPv3 packets. In the same way as with authentication, the same secret privacy key is used to encrypt and decrypt messages on both sides. Only the data portion is encrypted. The auth flag must be enabled and the security level must have privacy enabled to use encryption. Only the scopedPDU is encrypted. For more information, see Where USM Security Information Is Contained.

Currently, DES encryption is supported on the Solaris OS. DES encryption uses 56–bit key encryption. This level is the highest encryption level currently supported for DES, in this release of the Solaris software.

Public Keys

The System Management Agent supports Public Key Cryptography Standard (PKCS) #11. This token interface standard defines the interface that is used for communication between SSL and PKCS #11 modules. The version of PKCS on which the PKCS library compiled with the System Management Agent is based is the PKCS#11 v2.11 standard.

As described in Authentication Protocol Algorithms, the SHA1 algorithm is supported in addition to MD5. If the PKCS library is not found on your system, then the SMA attempts to use the standard Net-SNMP internal MD5, without DES support.

Where USM Security Information Is Contained

In an SNMPv3 packet string, USM information is contained in the following flags:

msgFlags

A single octet to indicate how the message is to be processed. For example, two bits of the msgFlags octet specify whether the packet has been encrypted and whether the packet has been authenticated. This flag is used to determine the security level of the message. Security levels, which are indicated in the main snmpd.conf file, are as follows:

noAuthNoPriv

Represented by an integer: 1.

Least access.

authNoPriv

Represented by an integer: 2.

More access than noAuthNoPriv but lower than authPriv.

authPriv

Represented by an integer: 3.

Most access, most secure.

msgSecurityModel

Specifies the security model used to generate the message, enabling the receiving entity to employ the appropriate model for security processing. In the System Management Agent, USM is the only supported security model.

msgSecurityParameters

An octet string containing data about the security model. This data is defined by the security model or models you are using. This data is used only by the security model or models you are using. The security model or models are specified in msgSecurityModel. USM uses this field to authenticate, encrypt, and decrypt SNMPv3 messages.

scopedPDU

Contains the normal Protocol Data Unit (PDU) and information for identifying the administratively unique context for processing the PDU. SNMPv2 and SNMPv3 messages both use the same PDU format. This scopedPDU format is encrypted if privacy was enabled for the transaction.

The MIB definitions for USM can be found at /etc/sma/snmp/mibs/SNMP-USER-BASED-SM-MIB.txt.

For more information about USM, see RFC 3414 at http://www.ietf.org/rfc/rfc3414.txt.

Using VACM for Access Control

You can use the View-based Access Control Model (VACM) to find out whether access to a specified managed object is authorized. Access control is done at the following points:

• When processing retrieval request messages from the manager

• When processing modification request messages from the manager

• When notification messages must be sent to the manager

The VACM builds on the community string concept mentioned in Community String, by providing access control that you can easily administer in SMA.

Access control is defined by tokens in the main snmpd.conf configuration file. The SMA daemon snmpd recognizes the following tokens for VACM access security that you can use in the main snmpd.conf configuration file:

• group

• access

• view

• com2sec

The first three of these tokens are described in Understanding VACM Tables. The com2sec token takes NAME SOURCE and COMMUNITY options. You can use this token to give SNMPv3 security privileges to SNMPv1 and SNMPv2 users and communities. The com2sec token indicates the mapping from a source and community pair to a security name.

Faster and more usable wrappers are provided with the snmpd.conf file and are recognized by the SMA snmpd agent. These wrappers are defined using read write (rw) and read only (ro) syntax for users and communities, as follows:

• rwuser

• rouser

• rwcommunity

• rocommunity

The rwuser token entries specify the minimum allowed access that the user must specify:

rwuser1 priv

User must specify the privacy password.

rwuser2 auth

User can specify the privacy password if the user was created with a privacy password. Otherwise, the user must specify an authentication password.

rwuser3 none

User can specify either no password or an authentication password. Otherwise, the user can specify the privacy password if the user was created with a privacy password.

Where VACM Security Information Is Contained

VACM information is contained in several parameters in the SNMPv3 packet string. These parameters are passed to the isAccessAllowed mechanism. The isAccessAllowed mechanism is the single entry point in VACM for checking whether access should be granted.

VACM parameters are as follows:

msgFlags

A single octet that indicates how to process the message. For more information, see Where USM Security Information Is Contained.

msgSecurityModel

Indicates which security model was used at message generation, enabling the receiving entity to employ the appropriate model for security processing. You have a choice in SNMPv3 of using one security model or multiple security models.

msgSecurityParameters

An octet string containing data about the security model. The security model or models are determined in msgSecurityModel.

scopedPDU

Contains the PDU. Shows the administratively unique selector of management information for processing the PDU. In other words, the scopedPDU contains the context and managed object OIDs. The scopedPDU contains the following fields:

contextEngineID

Uniquely identifies an SNMP entity that can access an instance of a managed object within a context.

contextName

The name of the context to which the PDU data belongs. The contextName is unique.

PDU

The Protocol Data Unit (PDU) for SNMPv3 contains an operation for the data in the contextName. Identified by the combination of contextEngineID and the contextName.

For an explanation of the other fields of the SNMPv3 packet string, see SNMP Versions.

Figure 4–1 SNMPv3 Packet Format Showing Scopes of Authentication and Encryption

Understanding VACM Tables

In determining whether access should be granted to a message, VACM uses four tables:

• Context Table.

• Security to Group Table.

• Access Table.

• View Tree Family Table.

Each of these VACM tables handles a particular part of the access mechanism. Each table can be remotely configured using the VACM MIB. The VACM MIB is defined in RFC 3415 at http://www.ietf.org/rfc/rfc3415.txt.

The VACM determines whether a request that has been authenticated by the SMA's USM is authorized to access the MIB object that is contained in the request. The snmpvacm utility is an SNMP application for basic maintenance of an SNMP agent's VACM tables. You need to have write access to the snmpvacm MIB table to use the snmpvacm utility. For more information, see the snmpvacm(1M) man page.

This section describes each of the VACM tables, including how the tables are indexed and what each row contains.

Context Table

The vacmContextTable table stores the contexts that are available locally. A context is the selector of management information. A single managed object can be in several different contexts. For example, consider a single module designed to monitor the status of a printer. For a network with several printers, multiple instances of this module can be implemented, with each instance containing a unique printer name. The printer name in this case is the context.

A single SNMP entity can have access to several contexts.

The vacmContextTable table is indexed by a contextName. Each of its rows gives the context name in the form of a unique, readable string, vacmcontextName.

The System Management Agent looks in the vacmContextTable for the contextName found in the scopedPDU. For information on the scopedPDU, see SNMP Versions. If the System Management Agent does not find the contextName of a particular message in the vacmContextTable, access is denied. In this case, a return value of noSuchContext is returned.

If the contextName exists, access checking continues, as shown in Figure 4–2. An example of typical entries in a vacmContextTable is shown in Example 4–1.

Example 4–1 Creating Typical Context Table Entries

Some typical vacmContextTable entries, created by a module, are:

SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileX" = STRING: fileX
SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileY" = STRING: fileY

The contextNames in this example are fileX and fileY.

Contexts are further explained in the Solaris System Management Agent Developer’s Guide. To illustrate the concept of contexts, a demo module is supplied with the System Management Agent. This demo module shows the importance of contexts for implementing multiple instances of a module. For more information, see Implementing Multiple Instances of a Module in Solaris System Management Agent Developer’s Guide.

Security to Group Table

The vacmsecurityToGroupTable table stores group information. A group name is given to a group of users and is used when managing their access rights. A group contains SecurityModel and a SecurityName value pairs. The resulting pair can only map to at most one group. The vacmSecurityToGroupTable table is indexed by the following:

• securityModel

• securityName

Each of the rows in the vacmSecurityToGroupTable table contains the following:

vacmSecurityModel

An SNMPv3 security model, in this case USM. For further information on USM, see Using USM for Authentication and Message Privacy. By using the com2sec token, SNMPv1 and SNMPv2c security models can be used. For more information about the com2sec token, see the snmpd.conf(4) man page.

vacmSecurityName

With USM, the vacmSecurityName is identical to userName. Represents a user in a format that is independent of the security model. By using the com2sec token, SNMPv1 and SNMPv2c security names can be used. For more information on the com2sec token, see the snmpd.conf(4) man page.

vacmGroupName

A readable string. Indicates the group that is associated with this entry.

The SecurityName is obtained by the msgSecurityModel specifier when a message is successfully authenticated and decrypted. The System Management Agent searches for this msgSecurityModel specifier and associated SecurityName in the vacmSecurityToGroupTable table. If the msgSecurityModel specifier and associated SecurityName are not found in the vacmSecurityToGroupTable, then access is denied. In this case, a return value of noSuchGroupName is returned.

If an entry is found, then the corresponding groupName is returned. Access checking continues, as shown in Figure 4–2.

Typical entries in a vacmsecurityToGroupTable are shown in Example 4–2.

Example 4–2 Creating Typical Security to Group Table Entries

Create a group for two previously created users that are named user2 and user5. In this example, the users are placed in a newly created group that is named grpnam1. Choose from one of two methods:

• Add the following lines to the main /etc/sma/snmp/snmpd.conf configuration file:

  group grpnam1 usm user2 group grpnam1 usm user5

  If the group is created by adding to the main /etc/sma/snmp/snmpd.conf configuration file, then the entries that are created in the vacmsecurityToGroupTable table are as follows:

  SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."user2" = STRING: grpnam1 SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."user5" = STRING: grpnam1 SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStorageType.3."user2" =INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStorageType.3."user5" = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStatus.3."user2" = INTEGER:active(1) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStatus.3."user5" = INTEGER:active(1)

  Rebooting does not delete entries. To delete entries in this VACM table, use the snmpvacm deleteGroup command. This method works if the storage type is nonVolatile. For VACM table entries with other storage types, you must manually remove from the table entries from the main /etc/sma/snmp/snmpd.conf configuration file. If the group is created by editing the main /etc/sma/snmp/snmpd.conf configuration file, the vacmsecurityToGroupTable table entries can be deleted only by editing the main /etc/sma/snmp/snmpd.conf configuration file.

• Use the snmpvacm command. For user2, a group can be created using the snmpvacm command as follows:

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createSec2Group 3 user2 grpnam1

  For user5, a group can be created using the snmpvacm command as follows:

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createSec2Group 3 user5 grpnam1

  The user myuser has rwuser level access. Therefore, group entries are created in this example as the myuser user where appropriate for the context. The users user2 and user5 do not have rights to update VACM tables.

View Tree Family Table

The vacmViewTreeFamilyTable table stores all collections of view subtree families. These collections are called MIB views. A MIB view is an OID subtree value, which is the family name, together with a bitstring value, which is the family mask. The family mask identifies which sub-identifiers of the family name are in the MIB view. A mask is a list of hex octets, which separated by either “.” or “:” The default is “ff”.

In a MIB view, each view subtree family has a type. The type determines if the view subtree family is included in the MIB view. A managed object instance is contained within a MIB view only if both of these statements are true:

• The managed object's OID contains the same number of sub-identifiers as the OID subtree, or more.

• If the corresponding bit of the mask is not zero, each of the managed object's OID sub-identifiers match corresponding sub-identifiers in the OID subtree.

If the configured value of the mask is too short to check these statements, the value is implicitly extended by a series of ones. A view family subtree with a mask of zero bits therefore corresponds to a mask of all ones, which in turn corresponds to one MIB subtree.

The vacmViewTreeFamilyTable table is indexed by:

viewName

Specified by the access right selected in the vacmAccessTable table. Used for access checking.

An OID of a MIB subtree

The OID of the PDU is compared to the MIB view.

Each of the rows in the vacmViewTreeFamilyTable table contains:

vacmViewTreeFamilyViewName

The name of the MIB view.

vacmViewTreeFamilySubtree

OID subtree. The OID subtree couples with a mask to make MIB view subtrees.

vacmViewTreeFamilyMask

Bitstring mask. The bitstring mask couples with an OID subtree to make MIB view subtrees.

vacmViewTreeFamilyType

The type determines whether the view subtree family is included in the MIB view.

If the MIB view does not contain the OID searched for, access is denied. In this case, a return value of notInView is returned. Otherwise, where the MIB view does contain the correct OID, access is granted. In this case a value of accessAllowed is returned.

The overall flow chart for this VACM algorithm is illustrated by Figure 4–2. In this diagram, the guideline terms suggested by the RFC are given for clarity:

securityName and securityModel

Indicate who requires access.

contextName

Determines where access is granted.

securityLevel and securityModel

Determines how access is granted.

viewType

Can be read, write or notify. Determines why a particular level of access is required by a group or user.

Object type, or OID of the managed object

Indicates what type of management data is checked.

Instance of the managed object

Combines with the object type to deliver which particular instance is checked to be in the MIB view. This decision is yes/no.

Figure 4–2 Overall Flow Chart for VACM

Example 4–3 shows typical entries in a vacmViewTreeFamilyTable.

Example 4–3 Creating Typical View Tree Family Table Entries

You can create a view in two ways:

• You can create a view by adding the view to the main /etc/sma/snmp/ configuration file.

  view all included .1 FF view none excluded .1 FF view vwnam1 included .1.3.6.1 FF

  The “FF” here is the mask.

  If the view is created by adding the group to the main /etc/sma/snmp/snmpd.conf configuration file, then the entries that are created in the vacmViewTreeFamilyTable table are as follows:

  SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."all".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."none".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."vwnam1".4.1.3.6.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."all".1.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."none".1.1 = INTEGER: excluded(2) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."vwnam1".4.1.3.6.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."all".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."none".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."vwnam1".4.1.3.6.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."all".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."none".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."vwnam1".4.1.3.6.1 = INTEGER: active(1)

• You can create a view by using the snmpvacm command.

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv -Ce localhost createView all .1 FF

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView none .1 FF

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView vwnam1 .1.3.6.1 FF

  Here, the user myuser has rwuser level access. Therefore, view entries are created in this example for myuser, where appropriate for the context.

  If the view is created by using the snmpvacm command, the storage type would be nonVolatile.

Access Table

The vacmAccessTable table stores each group's access rights. Each group can have multiple access rights. The most secure access right is chosen. The vacmAccessTable table is indexed by:

groupName

Returned from the lookup into the vacmSecurityToGroupTable table.

contextPrefix

The valid contextName matched within the vacmContextTable table.

securityModel

Specified in the message's msgSecurityModel parameter.

securityLevel

Specified in the message's msgFlags parameter.

Each of the rows in the vacmAccessTable table contains:

vacmGroupName

The group's name. This group has one or multiple access rights.

vacmAccessContextPrefix

The contextName must match the value of vacmAccessContextPrefix. See vacmAccessContextMatch.

vacmAccessSecurityModel

Indicates the security model that must be used to get access rights.

vacmAccessContextMatch

If vacmAccessContextMatch is set to exact, then the contextName must exactly match the value of the vacmAccessContextPrefix object.

If vacmAccessContextMatch is set to prefix, the contextName can match the first several characters of the vacmAccessContextPrefix object. This contextName is the name already matched within the vacmContextTable table.

vacmAccessSecurityLevel

Indicates the lowest security level necessary for having access to this access right. For information about security levels, see Where VACM Security Information Is Contained.

vacmAccessReadViewName

Authorized MIB viewName for read access. If vacmAccessReadViewName is empty, no active view exists for read access.

vacmAccessWriteViewName

Authorized MIB viewName for write access. If vacmAccessWriteViewName is empty, no active view exists for write access.

vacmAccessNotifyViewName

Authorized MIB viewName for notify access. If vacmAccessWriteViewName is empty, no active view exists for notify access.

If an access right is not found, access is denied. In this case, a return value of noAccessEntry is returned.

When an access right is selected, then the viewName indicated by that access right is selected. This viewName is determined by the PDU. If the SNMP operation in the PDU is a GETNEXT or GET operation, the vacmAccessReadViewName string is used. If the SNMP operation in the PDU is a TRAP operation, the vacmAccessNotifyViewName string is used. If the viewName is not configured, access is denied. In this case, a return value of noSuchView is returned.

If the access right is selected with a correctly configured viewName, access checking continues, as shown in Figure 4–2. Example 4–4 shows typical access table entries.

An additional example, Example 4–5, shows how to check that the users set up in this example and previous examples exist and are registered in VACM tables.

Example 4–4 Creating Typical Access Table Entries

You can create access table entries in two ways:

• You can create an access table entry by adding the entry to the main /etc/sma/snmp/snmpd.conf configuration file:

  access grpnam1 fileX usm priv exact all none none access grpnam1 "" usm auth exact all vwnam1 none

  If the group is created by adding to the main /etc/sma/snmp/snmpd.conf configuration file, then the entries that are created in the vacmAccessTable table are as follows:

  SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."".3.authNoPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."fileX".3.authPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."".3.authNoPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."fileX".3.authPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."".3.authNoPriv = STRING: vwnam1 SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."".3.authNoPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."".3.authNoPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."fileX".3.authPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."".3.authNoPriv = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."fileX".3.authPriv = INTEGER: active(1)

  If the group was created by directly editing the main /etc/sma/snmp/snmpd.conf configuration file, the group's storage type would be permanent.

• Alternatively, you can create an access table entry by using the snmpvacm command:

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "fileX" 3 3 1 all none none

  Here, the user myuser has rwuser level access. Therefore, access entries are created in this example as this myuser user where appropriate for the context.

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "" 3 2 1 all vwnam1 none

  If the group is created by use of the snmpvacm command, then the storage type would be nonvolatile. Objects created by use of either the snmpvacm or snmpusm commands have storage type of nonvolatile.

Example 4–5 Checking That Users Exist in the VACM Tables

Using the information in Example 4–3 and Example 4–4, check that the SNMPv3 user, user2, created in Example 4–2, exists. Validate the access entries already created for user2, by checking and setting values for the user. Use the snmpget and snmpset commands, once with encryption and once with no encryption. This method illustrates that the access entry for user2 is the minimum security level required, defined as auth= 2. The method also illustrates that priv can be used as well, since that level is more secure.

Use the snmpget command to check that the new user exists, with the DES option set for encryption. A context, -n fileX, is specified:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password
-n fileX localhost 1.3.6.1.4.1.42.2.2.4.4.6.1.1.0

This command validates one of the access entries that you set up for user2. The options that are associated with use of the snmpget command are described in the snmpcmd(1M) man page.

The snmpget command retrieves the following information:

SNMPv2-SMI::enterprises.42.2.2.4.4.6.1.1.0 = INTEGER: 111

In this returned output, 111 is an integer that is stored in the specified OID.

Similarly, snmpget command can be used to check that the new user exists, without the DES option set. If you do not set the DES option, no encryption is requested. This example shows that the user, user2, can execute an operation not in a context:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.3.0

The snmpget command retrieves the following information about system uptime:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5375) 0:00:53.75

Try to set a new value for sysLocation:

# snmpset -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password 
localhost 1.3.6.1.2.1.1.6.0 s "new val"

In this command, the s indicates “string”. The OID is sysLocation. The value being added to the sysLocation is new val.

Note that user2 has full access rights to the context (authPriv) for DES. The password is my_password. The following is returned:

SNMPv2-MIB::sysLocation.0 = STRING: new val

Confirm these settings with the snmpget command:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password localhost 1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: new val

Try the same command without the DES encryption set:

# snmpset -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0 s "new val2"

The same result is successfully returned:

SNMPv2-MIB::sysLocation.0 = STRING: new val2

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: new val2

This output shows that the user has write access to MIB-II.

If user2 has been defined in the snmptrapd.conf file, then start the SNMP trap daemon using the snmptrapd command:

# /usr/sfw/sbin/snmptrapd

Also, use the snmpinform command to send an INFORM-PDU trap. The snmpinform command validates that the user, user2 or user2, can generate notifications. Notifications can be generated if you perform a cold start. A cold start generates a notification, or a “trap.” The user can see this trap in the /var/log/snmpd.log file.

# /usr/sfw/sbin/snmpinform  -v3 -u user2 -a MD5
 -A my_password -l authNoPriv localhost 42 coldStart.0

For more information, see the snmptrapd.conf(4) and snmpinform(1M) man pages.

Troubleshooting Problems With VACM Tables

When creating VACM table entries, ensure that you configure access rights correctly for your users and user groups. Incorrectly configured access rights can lead to access being denied to key users.

Avoid creating large numbers of groups of users. Large numbers of groups can be difficult to administrate. Troubleshooting problems when you have created very large numbers of different user groups can become unmanageable.

When working with VACM tables, return values can include the following messages:

noSuchContext

This value is returned if the System Management Agent does not find the contextName of a particular message in the vacmContextTable. Access is denied. Check the context table entries. Ensure that these entries are correctly configured. Has each user got a context? For more information, see Context Table.

noSuchGroupName

Thisvalue is returned if the msgSecurityModel specifier and associated SecurityName are not found in the vacmSecurityToGroupTable. Access is denied. Check the security to group table entries. Ensure that these entries are correctly configured. Has each user got a group name? Have users been entered into the table correctly? For more information, see Security to Group Table.

notInView

This value is returned if the MIB view does not contain the OID searched for. Access is denied. For more information, see View Tree Family Table.

noAccessEntry

This value is returned if an access right is not found. Access is denied. Have you correctly set up the mask? Although each group can have multiple access rights, only the most secure access right is selected.

Is the vacmAccessContextMatch parameter set to exact? If the vacmAccessContextMatch parameter is set to exact, the contextName must be an exact match. Try setting the vacmAccessContextMatch value to prefix if appropriate. For more information, see Access Table.

Badly configured VACM tables can subject the network to unauthorized, possibly malicious access. Ensure that you check your VACM table configurations in a test environment before implementing these configurations on your network devices.

For more information on VACM, see RFC 3415 at http://www.ietf.org/rfc/rfc3415.txt.

The MIB definitions for VACM can be found at /etc/sma/snmp/mibs/SNMP-VIEW-BASED-ACM-MIB.txt.

Creating and Managing Users

This section provides procedures that explain how to create users with security. Several methods are available to create users in the System Management Agent. After you first install the System Management Agent, the default configuration is for new users to be SNMPv1 and SNMPv2c users.

The agent is not configured to create SNMPv3 users by default. To create SNMPv3 users in the System Management Agent, first you need to edit the main /etc/sma/snmp/snmpd.conf file. For more information, see the snmpd.conf(4) man page.

The first procedure in this section, To Create a New SNMPv3 User, shows you how to create the first, initial new user. Additional users are cloned from this initial user, so that the initial user's authentication and security types can be inherited. These types can be changed later. In cloning, secret key data for the user is set. You must know the passwords for the initial user and later users that you set up. You can only clone one user at a time from the initial user that you set up.

To Create a New SNMPv3 User

The net-snmp-config command used in this procedure adds a line to the /etc/sma/snmp/snmpd.conf file, giving the initial user read and write access to the agent.

1. Stop the System Management Agent.

   # svcadm disable -t svc:/application/management/sma:default

2. To create the new user, use the net-snmp-config command.

   # /usr/sfw/bin/net-snmp-config --create-snmpv3-user -a "my_password" newuser

   This command causes a new user to be created, named newuser, with a password equal to my_password. The new user creation uses both MD5 and DES, which are described in Authentication Protocol Algorithms.

   By default, when creating a user using the net-snmp-config command, these settings are created unless otherwise specified:

   auth protocol = MD5security level = rwuser auth

3. Start the System Management Agent.

   # svcadm enable svc:/application/management/sma:default

4. Check whether the new user exists.

   # snmpget -v 3 -u newuser -l authNoPriv -a MD5 -A my_password localhost sysUpTime.0

   ---

   Note –

   Passwords must contain at least eight characters.

   ---

   Giving the new user read and write access is not always useful. If you want to reduce or change the access rights of the new user, edit the /etc/sma/snmp/snmpd.conf file. For more information, see the snmpd.conf(4) man page.

To Create a New User Using System Prompts

1. Stop the System Management Agent.

   # svcadm disable -t svc:/application/management/sma:default

2. To create the new user, named newuser, with a password equal to my_password, use the net-snmp-config command interactively.

   # /usr/sfw/bin/net-snmp-config --create-snmpv3-user

   Enter a SNMPv3 user name to create:

3. Provide the appropriate user name, in this case:

   newuser

   Enter authentication pass-phrase:

4. Type the appropriate pass-phrase, in this case:

   my_password

   Enter encryption pass-phrase:

5. To reuse the authentication pass-phrase, press Return.

   adding the following line to /var/sma_snmp/snmpd.conf: createUser newuser MD5 "newuser_pass" DES adding the following line to /etc/sma/snmp/snmpd.conf: rwuser newuser

   By default, when creating a user using the net-snmp-config command, these settings are created unless otherwise specified:

   auth protocol = MD5

   security level = rwuser auth

6. Start the System Management Agent.

   # svcadm enable svc:/application/management/sma:default

7. Check whether the new user exists.

   # snmpget -v 3 -u newuser -l authNoPriv -a MD5 -A my_password localhost sysUpTime.0

   ---

   Note –

   Passwords must contain at least eight characters.

   ---

   Giving the new user read and write access is not always useful. If you want to reduce or change the access rights of the new user, edit the /etc/sma/snmp/snmpd.conf file. For more information, see the snmpd.conf(4) man page.

To Create Additional SNMPv3 Users With Security

The preferred method of creating a new user in secure SNMP is to clone the initial user that you originally set up. This procedure copies the user you set up in To Create a New SNMPv3 User. This procedure uses the snmpusm command described in Using USM for Authentication and Message Privacy. For more information, see the snmpusm(1M) man page.

1. Check whether the System Management Agent is running.

   # svcs svc:/application/management/sma:default

   If the agent is not running, start it.

   # svcadm enable svc:/application/management/sma:default

2. Create a new user using the snmpusm command.

   # snmpusm -v 3 -u newuser -a MD5 -A my_password -l authNoPriv localhost create lee newuser

   This command creates a user named “lee”. This new user has the same password my_password, as the source user, named “newuser”, that you created in To Create a New SNMPv3 User.

3. Change the new user's password.

   # snmpusm -v 3 -u lee -a MD5 -A my_password -l authNoPriv localhost passwd my_password lee_password

   This command gives the user lee a new password, lee_password. The default auth type is MD5.

4. Create associated VACM entries either by directly editing the /etc/sma/snmp/snmpd.conf file or by using the snmpvacm command.

   If you are directly editing the snmpd.conf file you must first temporarily stop the agent.

   # svcadm disable -t svc:/application/management/sma:default

5. Assign access to lee.

   • To give lee read and write access, add a new rwuser line to the snmpd.conf file.

     rwuser lee

   • To give lee read-only access, add a new rouser line to the snmpd.conf file.

     rouser lee

   If you do not specify a security level, the System Management Agent defaults to authNoPriv. For more information, see the snmpd.conf(4) or snmpvacm(1M) man pages.

6. Start the System Management Agent.

   # svcadm enable svc:/application/management/sma:default

7. Check whether this procedure has been successful.

   Check whether your new user exists.

   # snmget -v 3 -u lee -a MD5 -A lee_password -l authNoPriv localhost sysUpTime.0

Managing SNMPv1 and SNMPv2c Users With SNMPv3 Security

For SNMPv1 and SNMPv2c users, community string is used for security. The standard Net-SNMP token, com2sec, is provided with the SMA. The com2sec token enables you to map a host name and community string pair, for SNMPv1 or SNMPv2c, to a security name. In this case, the security level is noAuthNoPriv. For information on the noAuthNoPriv security level and on other security levels, see Where USM Security Information Is Contained.

Proxy Statements and Security

In the System Management Agent, proxying is supported for SNMPv1 and SNMPv2c users only. For more information, see Proxy Handling for Solstice Enterprise Agents Requests.

Creating and Managing Groups

Creating a large number of groups in SNMP causes management and administration of these groups to become very complex. If you create a large number of groups, troubleshooting these groups very difficult.

When groups or views are created by editing the snmpd.conf file, the storage type is permanent. If you edit the snmpd.conf file instead of using the snmpvacm command, entries for groups are permanent. You can delete the entries only by removing them from the snmpd.conf file.

Follow the examples provided in Using VACM for Access Control for creating and managing groups.