Network administrators and Information Security Officers (ISOs) have a tough job monitoring and marshaling the resources of corporate infrastructure – especially at a time when enterprises are expanding their operations beyond localized data centers and campuses to dispersed networks having the potential to span the globe.
Fortunately, there’s a standardized set of mechanisms that can streamline and rationalize network management – in the form of a protocol known as SNMP.
What is SNMP?
The set of commands and mechanisms governing the management of computer networks and the monitoring of network devices and their functions is known as the Simple Network Management Protocol or SNMP. It’s a standard protocol of the TCP/IP (Transmission Control Protocol/Internet Protocol) family, and is used by network administrators in mapping and monitoring network activities, network performance, and error rates.
The first iteration of SNMP (SNMPv1) was developed some years ago, with its initial specification formulated in accordance with RFC 1065, 1066, and 1067 in 1988. It was formally defined in RFCs 1155 and 1157. Having been in circulation for so long, this version is widely supported. But it has several security vulnerabilities (including the fact that it performs authentications in plain text), and is not advised for use on unsecured networks.
Work began on version two in 1993. SNMPv2c builds on the foundations of SNMPv1, with enhancements in the handling of protocol packet types, transport mapping, and other areas. It retains the “community based” administrative structure of the earlier version – hence the “c” at the end of its name.
Defined in RFC 1901, RFC 1905, RFC 1906, and RFC 2578, SNMPv2c was the most popular flavor of this second attempt, which had several variants. Notably, SNMPv2u offered user-based security, with authentication settings that could be configured per user. However SNMPv2u (and version two pretty much as a whole) was difficult to understand and operate, so never generated much enthusiasm among its users.
Defined by RFC 1905, RFC 1906, RFC 3411, RFC 3412, RFC 3414, RFC 3415 and first proposed in 1998, SNMPv3 adopts a fully user-based security system, allowing operators to set authentication requirements according to any of three models:
- NoAuthNoPriv: Users at this level have no authentication procedure, and no assured privacy in the messages they send or receive.
- AuthNoPriv: Connections here must be authenticated, but messages are sent without encryption.
- AuthPriv: Here, authentication is required and all messages are encrypted.
SNMPv3 is the currently accepted, recommended, and secure model of the protocol. It includes an access control mechanism to more closely govern which branches of a network that users can access. This version is also able to make use of secure data transport protocols like SSH or TLS.
The Transmission Control Protocol/Internet Protocol (TCP/IP) forms the backbone of SNMP – and the first version of the protocol only supported TCP/IP networks. SNMP is itself an application-layer protocol which allows for the exchange of management information between network devices.
User Datagram Protocol (UDP)
Though considered part of the TCP/IP suite of information exchange mechanisms for networks, the current version of SNMP isn’t limited to TCP/IP. There’s also support for the User Datagram Protocol (UDP), which is frequently offered to internet users as an alternative to establishing connections via TCP/IP. In many circles however, UDP is considered the less secure option.
A deployment of SNMP typically consists of four components. First among these is a management system usually referred to as SNMP Manager. It most often takes the form of a computer system or server which is used to run one or more network management arrays, and is tasked with communicating with any network devices that carry an SNMP agent (described below).
It’s the SNMP Manager’s role to:
- Query SNMP agents
- Get responses from the agents
- Set variables used in configuring the agents
- Acknowledge asynchronous or unanticipated events from the agents
An SNMP agent is a software program packaged within a network element. Agents are responsible for gathering information about the components to which they’re attached, and storing this data in a form that can be queried in communications with the SNMP Manager.
Agents may be standardized or vendor-specific, and are tasked with:
- Collecting management information about their local environment
- Storing and retrieving management information when called upon to do so
- Signaling specific events to the SNMP Manager
- Acting as a proxy or go-between for certain network nodes that aren’t within the SNMP umbrella
These are all the elements of a network that require some degree of management or monitoring. Managed devices would include file servers, workstations, routers, switches, printers, UPS (Uninterruptible Power Supply) units, and other network hardware.
Nothing to do with the Men In Black. The Management Information Base (MIB, also known as the Management Information database) is the data repository held by each SNMP agent, detailing the design parameters of the managed device. This database is drawn upon by the SNMP Manager to query agents for specific information, and to translate the results as needed for the Network Management System (NMS).
An MIB will usually contain a standard set of controls and statistical values for the hardware nodes on a network. Files on the MIB hold the set of questions that the SNMP Manager can ask of an agent.
The exchange of information under SNMP is governed by a concise and relatively simple set of commands – which account for the popularity of the protocol.
- GetRequest: Sent by SNMP Manager to request the value of a device’s unique Object Identifier (Object ID or OID).
- GetNextRequest: Requests the value of the OID on the next branch of the MIB database hierarchy.
- GetBulkRequest: A request for multiple values, equivalent to several GetNext requests.
- SetRequest: Used by SNMP Manager to modify or assign values to a managed device.
- Response: Sent by an agent to return any information requested by the SNMP Manager.
- Trap: An asynchronous notification sent by an agent to SNMP Manager, informing of noteworthy events occurring unexpectedly on a managed device.
- InformRequest: A confirmation from SNMP Manager that a Trap notification has been received.
In the busy and often extremely large environment of an enterprise network, it may not make sense for an SNMP Manager to poll or request information from every agent on every device. To reduce the workload, it’s possible to configure agents or managed devices to send notifications to the manager for specific events or conditions, without their having to be asked for them.
It’s in this application that the SNMP Trap command comes into its own. Trap alerts may be defined with generic or specific triggers, and provide the address of each agent that generates them, together with time stamps and other markers.
Share this Post