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. You can configure an SNMP agent on CipherTrust Manager to monitor the health of the appliance.

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. You must first add an SNMP interface before you can configure an SNMP agent.

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 CipherTrust Manager to respond to SNMP v1/v2c requests, see Configuring SNMPv1/v2c. You configure a community on CipherTrust Manager as part of this process.

To configure CipherTrust Manager's agent to send SNMP v1/v2c trap and inform notifications, you add a management station independently from configuring community strings to respond to SNMP v1/v2c GET, GETNEXT, GETBULK, and SET requests.

Both SNMPv1 and SNMPv2c are enabled when either community names or SNMPv1/v2c management stations are configured. Deleting all community names and all SNMPv1/v2 management stations is equivalent to disabling SNMP v1/v2c and stopping all future notifications through 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 two MIBs access groups, Standard and Enterprise. These access groups are applied at the SNMP community or SNMP user level.

CipherTrust Manager implements the following Standard MIBs:

• MIB-2 General network statistics (RFC 1213 and subsequent revisions)

• Host Resources MIB (RFC 1514 and 2790)

• SNMPv3 framework (RFCs 2571-2575, RFCs 3411-3418)

  This framework is internal only, to manage SNMP users on CipherTrust Manager.

CipherTrust Manager implements the following Enterprise MIBs:

• DisMan Events and Schedule MIBS

• private UCDavis/Net-SNMP agent extensions

  This includes specified processes and disks, memory, CPU, and load average.

The README.agent-mibs for Net-SNMP includes details about included OIDs.

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.

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

You must first add an SNMP interface before you can configure an SNMP agent.

To monitor and control the CipherTrust Manager using SNMPv1/v2c, community names must be configured. Once a community is configured, the SNMP agent starts responding to GET, GETNEXT, GETBULK, and SET requests from allowed management stations.

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,enterprise>

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

You must first add an SNMP interface before you can configure an SNMP agent.

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).

Once you add at least one SNMP USM user, the SNMP agent starts responding to GET, GETNEXT, GETBULK, and SET requests from allowed management stations. You can then create an SNMP v3 management station to start sending SNMP trap and inform 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,enterprise" –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

Adding an SNMP Management Station

Add an SNMP management station configuration to start sending SNMP trap or inform notifications to a management station.

To add a SNMP v3 management station, you need at least one SNMP USM user configured. If this user is used only for notification, then it can be configured without any access groups.

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