SNMP

Overview

Simple Network Management Protocol (SNMP) is a request-response protocol used to communicate management information. SNMP enables network and system administrators to remotely monitor devices on the network, such as switches, routers, proxies, and hubs.

This protocol relies on three main concepts: Network Management Station (NMS), agent, and Management Information Base (MIB). The NMS is configured on a network node and runs SNMP management software; agents run on network devices that are being monitored by the NMS; and the MIB defines what kind of information can be exchanged between the agent and the NMS.

Management information is communicated between an Network Management Station (NMS) and an agent. SNMP notifications (traps and informs), sent from agents to managers, might indicate a warning or error condition or otherwise notify the manager about the agent's state.

There are three versions of SNMP: SNMPv1, SNMPv2c and SNMPv3. SNMPv1 and SNMPv2c use community-based security model and SNMPv3 uses User-based Security Model (USM).

SNMP on CipherTrust Manager

CipherTrust Manager supports SNMP versions v1, v2c and v3.

SNMP v1/v2c

SNMPv1/v2c relies on the community name to provide a low level of security for communications between the NMS and agent. A pairing of an SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community. Each SNMP community is named by a string of octets that is called the community name for said community. For an agent, a subset of objects in the MIB that pertain to that element is called a SNMP MIB view. Community names are associated with a certain access level (read-only, read-write) to SNMP MIB view.

When the CipherTrust Manager receives a SNMPv1/v2c request, the agent verifies that the community name in the request and can optionally validate the source IP of the request matches the community name. The request will be processed if a match if found, otherwise it is dropped. To configure the device for SNMP v1/v2c, see Configuring SNMPv1/v2c.

SNMP v3

SNMPv3 incorporated all the capabilities of SNMPv1/v2c, and introduced the concept of a User-based Security Model (USM). This security model supports data integrity, data origin authentication, data confidentiality and message timeliness and limited replay protection. Additionally, SNMPv3 enhanced the existing access control with View-based Access Control Model (VACM). CipherTrust Manager supports MD5, SHA, SHA-224, SHA-256, SHA-384, and SHA-512 for authentication protocols; and DES, AES, AES-192, and AES-256 for privacy protocols. To configure the device for SNMP v3, see configuring SNMPv3.

MIBs

CipherTrust Manager implements the following MIBs:

• Standard MIBs (SNMP v1, v2c, v3)

• Internet Standard MIBs (RFC-1213)

• Host Resources MIB (HOST-RESOURCES-MIB)

• Distributed Management MIBs (RFC-2981, RFC-2982)

Access Control

Structure of Management Information (SMI & SMIv2) defines ACCESS(SMIv1)/MAX-ACCESS(SMIv2) clause to allow which SNMP operations (GET, SET or Notification) are allowed for a MIB object. An ACCESS value of 'read-write' means that the object can be both read with GET or GET-NEXT request and written with a SET request, while an ACCESS value of 'not-accessible' means that the object can neither be read nor written to. In addition, access control in the CipherTrust Manager SNMP implementation makes it possible for agents to provide different levels of MIB group access to different managers. Access levels 'read-only' or 'read-write' can be provided to Standard and Enterprise MIB access groups. You can restrict access by allowing one NMS to read only standard MIBs and another NMS to read and write both standard MIBs and enterprise MIBs.

Enterprise MIBs

The Enterprise MIB objects can be accessed using the community names/users configured with Enterprise MIB access group. The Enterprise MIB access group is able to retrieve UCD-SNMP-MIB objects. UCD-SNMP-MIB defines system monitoring objects; e.g. disk, cpu load, memory, processes.

• Hardware Objects

  • Processes, Memory, Disk, CPU Load Average objects (UCD-SNMP-MIB)

    Note

    Currently, there are no specific enterprise MIB objects defined for the CipherTrust Manager.

Notifications

The CipherTrust Manager can generate and send notifications (traps, informs or both) to configured management stations when an important system events occur such as Authentication failure, Interface link up/down, and DisMan events.

• Trap: Traps are unreliable notification message sent from a device to management station.

• Inform: Informs are reliable notification message sent from a device to management station that also requires an acknowledgment from the management station.

To receive SNMP notifications (traps and informs) from CipherTrust Manager, the management station needs to be configured.

Configuring SNMPv1/v2c

To monitor and control the CipherTrust Manager using SNMPv1/v2c, community names must be configured. Both SNMPv1 and SNMPv2c are enabled.

Configure Communities:

Configure (add, read, update and delete) community names with management station host(s) filtering for SNMP v1 and SNMPv2c.

To add a community configuration:

Add a SNMP community configuration with management station host(s) filtering and mib access control.

$ ksctl snmp communities add –community <community-name> --source <mgmt.-station-ip-or-cidr> --mib-accesses <standard,entperise>

Example 1:

Allow any management station to access standard MIB view using the community name ‘public’

$ ksctl snmp communities add –community public

Example 2:

Allow a management station with IP ’10.10.10.10’ to access standard and enterprise MIB views using the community name ‘private’.

$ ksctl snmp communities add –community private –source 10.10.10.10 –mib-accesses “standard,enterprise”

Example 3:

Allow a group of management stations using CIDR notation to access enterprise MIB view using the community name ‘secret’

$ ksctl snmp communities add –community secret –source 10.10.10.0/24 –mib-accesses enterprise

To read a community configuration:

To read a SNMP community configuration using its ID.

$ ksctl snmp communities get --id <community-id>

To list community configurations:

To list all the SNMP community configurations.

$ ksctl snmp communities list

To delete community configuration:

To delete a SNMP community configuration using its ID.

$ ksctl snmp communities delete --id <community-id>

Configuring SNMPv3

To monitor and control the CipherTrust Manager and to receive notifications using SNMPv3, users must be configured.

Configuring SNMP USM Users:

Configure (add, read, update and delete) SNMP USM users for management and to use with SNMP management station (notifications).

To add a SNMP USM user:

Example 1:

To add a SNMP USM user configuration with no authentication and no privacy, and with read-only access to standard MIB view. No authentication and no privacy configuration is not recommended.

$ ksctl snmp users add --user-name rob --security-level noAuthNoPriv –mib-accesses standard

Example 2:

To add a SNMP USM user configuration with authentication but no privacy. It gives read-write access to standard and enterprise MIBs views.

$ ksctl snmp users add --user-name bob --security-level authNoPriv --auth-protocol SHA --auth-password --mib-accesses "standard,enteprise" –read-write

Example 3:

To add a SNMP USM user configuration for SNMPv3 notification with authentication and privacy. There is no MIB access provided for this user.

$ ksctl snmp users add --user-name trapuser --security-level authPriv --auth-protocol SHA --auth-password authpass --priv-protocol AES  --priv-password privpass

Example 4:

To add a SNMP USM user configuration for inform notification with authentication and privacy. There is no MIB access provided for this user. EngineID of the notification receiver is required.

$ ksctl snmp users add --user-name informuser --engine-id 0x0102030405 --security-level authPriv --auth-protocol SHA --auth-password authpass --priv-protocol AES  --priv-password privpass

To add an SNMP management station:

Add an SNMP management station configuration to send SNMP notifications to it.

Example 1:

To send SNMPv1 trap using community name ‘private’

$ ksctl snmp mgmt-stations add --host 1.1.1.1 --version 1 --security-name private

Example 2:

To send SNMPv2c inform using community name ‘secret’

$ ksctl snmp mgmt-stations add --notification-type inform --host 1.1.1.2 --version 2c --security-name secret

Example 3:

To send SNMPv3 trap using USM user name ‘trapuser’ that is configured through ‘ksctl snmp users’ command.

$ ksctl snmp mgmt-stations add --notification-type trap --host 1.1.1.3 --port 1162 --version 3 --security-name trapuser