#compsci 

SNMP, or the **Simple Network Management Protocol**, is an Internet-standard protocol for managing devices on IP Networks.

SNMP is supported by:
- routers
- switches
- servers
- workstations
- printers
- etc

It's fairly simple to use SNMP to monitor the health of your network hardware.

The core of SNMP is a simple set of operations (and the information these operations gather) that gives administrators the ability to change the state of some SNMP-based device, e.g. you can use SNMP to shut down an interface on your router.
## History
Introduced in 1988 to meet the growing need for a standard for managing [[Internet Protocol]] devices.

The IETF (Internet Engineering Task Force) is responsible for defining the standard protocols that govern Internet traffic.
The IETF published [[Requests for Comments]] (RFCs), which are specifications for many protocols that exist in the IP realm. 
Documents enter the standards track first as *proposed* standards, then move to *draft* status, then, if approved, given the *standard* status.
Standard RFCs are either historical or experimental

![[Pasted image 20250707094426.png]]

## Managers and agents
In the world of SNMP, there are 2 kinds of entities: **managers** and **agents**.
**Manager** = server runnign some kind of software system that can handle management tasks for a network. Managers are often referred to as **Network Management Stations (NMSs).**

An NMS is responsible for polling and receiving traps from agents in the network. 
A **[[SNMP polling|poll]]**, in the context of network management, is the act of querying an agent for some piece of information.
A **trap** is a way for the agent to tell the NMS that something has happened. They are sent **asynchronously**, not in response to queries from the NMS.

The **[[SNMP Agent configuration|agent]]** is a piece of software that runs on the network devices you are managing. It provides management information to the NMS by keeping track of various operational aspects of the device.
![[Pasted image 20250707105238.png]]

It's important to keep mind that polls and traps can happen **at the same time**. There are no restrictions on when the NMS can query the agent or when the agent can send a trap.

## SMIs and MIBs
The **Structure of Management Information** (SMI) provides a way to define managed objects and their behaviour. An agent has in its possession a list of the objects it tracks, e.g. the operational status of a router interface.

The **Management Information Base** (MIB) can be thought of as a database of managed objects that the agent tracks. Any sort of status or statistical information that can be accessed by the NMS is defined in a MIB.
The SMI provides a way to define managed objects, while the MIB is the definition (using the SMI syntax) of the objects themselves.

An agent may implement many MIBs, but all agents implement a particular MIB called **MIB-II** (RFC 1213), whose main goal is to provide general TCP/IP management information.
There are also many other MIBs, both defined by a given RFC or created by the vendor of a particular piece of equipment

![[Pasted image 20250707105806.png]]

The Host Resources MIB (RFC 2790) defines a set of objects to help manage critical aspects of Unix and Windows systems.

### RMON
Remote Monitoring Version 1 (RMONv1), or the enhanced version RMONv2, provides the NMS with packet-level statistics about an entire LAN or WAN.

## SNMPv1 and SNMPv2
### UDP
SNMP uses the **UDP** ([[User Datagram Protocol]]) as the transport protocol for passing data between managers and agents. UDP was chosen over TCP because it is connectionless: no end-to-end connection is made between the agent and the NMS when datagrams are sent back and forth.
This aspect of UDP makes it unreliable (no acknowledgment of lost datagrams), so it's up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. Usually accomplished with a simple timeout (a request is sent to an agent, if the response time exceeds the timeout length, the request is retransmitted)

![[Pasted image 20250709080523.png]]
Good thing about UDP is that it requires low overhead

Though SNMP over TCP has been implemented, it's for special cases of proprietary agents, though in a heavily congested network, SNMP over TCP is a bad idea.

SNMP uses UDP port **161** for sending and receiving requests and port 162 **for** receiving traps from managed devices.

![[Pasted image 20250709080736.png]]
Represented by the [[Protocol stack]], this is how a typical SNMP request goes:
![[Pasted image 20250709080841.png]]

### SNMPv1/v2 communities
SNMPv1/v2 use the notion of communities to establish trust between managers and agents.
An agent is configured with 3 community names: read-only, read-write, and trap.
The community names are essentially passwords:
- the RO community string allows you to read data
- the RW community string allows you to read/write data
- the trap community string allows you to receive traps from the agent


### SMIv1
SMIv1 (defined by RFC-1155) defines precisely how managed objects (management information) are named and specifies their associated datatypes, giving them 3 attributes:
- name (Object Identifier, OID)
- Type and syntax (defined using a subset of [[Abstract Syntax Notation One]], ASN.1)
- Encoding (using the [[Basic Encoding Rules]], BER)

OIDs are named using a tree-like hierarchy:
![[Pasted image 20250709081842.png]]
for example, the internet(1) element could referred to as either 1.3.6.1, or as iso.org.dod.internet

![[Pasted image 20250709082311.png]]

IANA currently manages all the private enterprise number (PEN) assignments for individuals, institutions, companies, etc
![[Pasted image 20250709082347.png]]



SMIv1 currently supports the following datatypes
![[Pasted image 20250709082500.png]]
![[Pasted image 20250709082511.png]]

Goal of these object types = define managed objects.

>[!Typical MIB]-
>![[Pasted image 20250709083052.png]]
>![[Pasted image 20250709083100.png]]
>![[Pasted image 20250709083113.png]]
>![[Pasted image 20250709083119.png]]
>![[Pasted image 20250709083128.png]]


The `IMPORTS` section of the MIB is sometimes referred to as the *linkage* section.
![[Pasted image 20250709083441.png]]

![[Pasted image 20250709083446.png]]

The first managed object is the *ifTable*, which represents a table of network interfaces on a managed device.

### SMIv2
SMIv2 extends the SMI object tree by adding the snmpV2 branch to the internet subtree, adding several new datatypes and making a number of other changes.

![[Pasted image 20250709132349.png]]

The new datatypes are:
![[Pasted image 20250709132423.png]]
![[Pasted image 20250709132437.png]]

Object definition in SMIv2 has changed slightly from SMIv1
![[Pasted image 20250709140812.png]]
![[Pasted image 20250709140827.png]]

SMIv2 also introduces new textual conventiosn that allow managed objects to be created in more abstract ways.
RFC 2579 defines the textual conventions used by SNMPv2, which are:
![[Pasted image 20250709140959.png]]
![[Pasted image 20250709141010.png]]

#### MIB-II
![[Pasted image 20250709141104.png]]
![[Pasted image 20250709141113.png]]

## [[SNMP operations]]

## Host management
![[Pasted image 20250709150751.png]]

## RMON
![[Pasted image 20250709150858.png]]
![[Pasted image 20250709150911.png]]
![[Pasted image 20250709150923.png]]

## SNMPv3
SNMPv3 addresses the security problems that have plagued SNMPv1/v2. For all practical purposes, that's all it does

![[Pasted image 20250716103111.png]]

### Engine
The SNMPv3 Engine is composed of 4 pieces:
- the Dispatcher
- the Message Processing Subsystem
- the Security Subsystem
- the Access Control Subsystem

The Dispatcher's job is to send and receive messages.
It tries to determine the version of each received message (i.e. v1,v2, or v3) and, if the version is supported, hands the message off to the Message Processing Subsystem

The Message Processing Subsystem prepares messages to be sent and extracts data from received messages.

The Security Subsystem provides authentication and privacy services. 
Authentication either via community strings, or SNMPv3 user-based authentication, which uses salted [[MD5]] or [[SHA]] algorithms.
The privacy service uses the [[DES algorithm]] to encrypt and decrypt SNMP messages. as well as the [[AES]] protocol.

The Access Control Subsystem is responsible for controlling access to MIB objects.

### Applications

![[Pasted image 20250716102911.png]]

### Extra textual conventions
SNMPv3 defines a number of extra textual conventions:
![[Pasted image 20250716103150.png]]

### USM
USM = User-based Security Model

Some basic terminology:
![[Pasted image 20250716104307.png]]

An SNMPv3 message (packet) format has the following fields:
- msgVersion (SNMP version of the message, set to 3)
- msgID (used between a manager and agent to coordinate request/response messages)
- msgMaxSize (maximum message size)
- msgFlags (8bit value that specifies whether a report PDU is to be generated, whether privacy is used, and whether authentication is used)
- msgSecurityModel (specifies which security model was used by the sender of the message (1,2,3))
- msgSecurityParameters (contains security-specific information)
	- msgAuthoritativeEngineID (snmpEngineID of the authroitative engine)
	- msgAuthoritativeEngineBoots
	- msgAuthoritativeEngineTime
	- msgUserName (the user who may be authenticating and encrypting the message)
	- msgAuthenticationParameters (null if no authentication, otherwise, contains MD5 and SHA message digests for the message)
- contextEngineID (unique id of an SNMP entity)
- contextName (defines a particular context within an SNMP engine)
- scopedPDU (block of data made up of a contextEngineID, contextName, and SNMP PDU)


![[Pasted image 20250716105040.png]]

![[Pasted image 20250716105751.png]]
![[Pasted image 20250716105805.png]]

![[Pasted image 20250716110754.png]]
Encryption accomplished by the CBC-DES or the CFB-AES-128.
A USM User Table is used to store the passphrase and other details in msgPrivacyParameters
![[Pasted image 20250716111110.png]]

### VACM
VACM = View Access Control Model
Used to control access to managed objects in a MIB

![[Pasted image 20250716112527.png]]

The vacmContextTable is a collection of managed objects that have access constraints which are associated with a context name.
Stores all available contexts. The table is indexed by a contextName, and each row in this table contains vacmContextName (textual name for the context)

![[Pasted image 20250716112800.png]]

The vacmAccessTable is used to store the access rights defined for groups.
This table is indexed by a groupName, contextPrefix, securityModel, and securityLevel.

Each row in the table contains:
![[Pasted image 20250716112953.png]]
![[Pasted image 20250716113003.png]]



![[Pasted image 20250716114949.png]]

## MIB-II
![[Pasted image 20250729033331.png]]![[Pasted image 20250729033615.png]]