M04-09 · SNMP enumeration

October 26 morning: one core concept at a time

1. What is SNMP?

SNMP (Simple Network Management Protocol) lets management systems monitor information such as names, interface status, and traffic on switches, routers, and servers.

Think of a management desk beside a device: you can ask for information, but the desk decides how much to disclose based on your identity and permissions. SNMP enumeration systematically organizes these responses for authorized device inventory and information-disclosure checks. An available service does not authorize arbitrary operations.

2. Four essential roles

• Manager: the management tool that sends queries.
• Agent: the program on a device that receives and processes management requests.
• MIB (Management Information Base): definitions of managed objects' names, types, and meanings, like a field reference. It is not an entire device dataset that can simply be downloaded.
• OID (Object Identifier): identifies a managed object in a hierarchical tree. For example, 1.3.6.1.2.1.1.5.0 corresponds to sysName.0, an instance of the scalar system-name object.

In plain terms, the manager queries the agent using an OID, the agent returns a value according to access permissions, and the MIB explains what that value means.

3. How do GET, WALK, and SET differ?

GET: retrieves the value of a specified object instance.

GETNEXT: retrieves the next accessible instance in OID order, rather than adding one to the last number.

WALK: a tool repeatedly queries to traverse a specified subtree. Net-SNMP snmpwalk uses GETNEXT; WALK is not a separate protocol message.

SET: attempts to change an object's value. The object must support the operation and the requester needs appropriate write access. This lesson discusses read-only queries and does not modify devices.

Being able to list information does not establish permission to configure a device. Net-SNMP query tutorial; RFC 3416

4. Ports and security versions

Commonly, an agent receives queries on UDP 161, while notifications such as Trap and Inform messages go to a receiver on UDP 162. These are common configurations, not the only possible transports or ports for SNMP.

v1/v2c use a community string, which the traditional protocols do not encrypt. Read-only or writable access depends on device configuration, not the name of the string.

v3 does not necessarily mean encryption. Check the security level:

• noAuthNoPriv: no message authentication and no encryption.
• authNoPriv: authentication and integrity protection, without encryption.
• authPriv: authentication, integrity protection, and encryption.

Encrypted messages do not establish that an identity may read all data or change settings. Authorization scope must be checked separately. RFC 3417; RFC 3411

5. A synthetic example

Suppose an isolated laboratory has a switch, and the administrator authorizes you to read only the system subtree.

You GET sysName.0 and receive lab-switch-01, then WALK the permitted system-description and name objects.

This evidence supports only this conclusion: this identity could read these objects at this time under these settings.

It does not establish SET access or permission to log in to the device's management interface. No response does not establish that the service is absent: firewall, authentication, or configuration issues may be responsible.

6. Defenses and evidence interpretation

Restrict management sources and networks, apply least privilege and a limited MIB view, and disable SNMP when unnecessary. When needed, prefer v3 authPriv with suitable algorithms and key configuration.

Record the time, source, version/security level, queried OIDs, and necessary responses, but omit community strings and keys. A device's version string is an investigative clue, not sufficient evidence of a vulnerability by itself.

Quick check:

You successfully read a switch's name. Does that establish that you may change its settings? What kind of permission still needs checking?

Reply in one or two sentences.