What Is SNMP and Why It Leaks Data

What SNMP Does

Simple Network Management Protocol (SNMP) is the standard protocol for monitoring and managing network devices. Routers, switches, firewalls, servers, printers, UPS systems, and virtually any network-connected device supports SNMP. It allows administrators to query device status, collect performance metrics, receive alerts, and in some cases modify device configuration remotely.

SNMP operates over UDP on ports 161 (queries and responses) and 162 (traps - unsolicited notifications from devices). It was first defined in 1988 (RFC 1067) and has been a fundamental part of network management infrastructure for over three decades.

The protocol is simple by design. That simplicity made it easy to implement on resource-constrained network devices. It also means that security was an afterthought, bolted on in later versions rather than built into the foundation.

Architecture - Managers and Agents

SNMP uses a manager-agent model. The SNMP manager (running on a network management station like Nagios, PRTG, Zabbix, or LibreNMS) sends requests to SNMP agents running on managed devices. The agent responds with the requested data.

graph TD
    subgraph "SNMP Architecture"
        MGR[SNMP Manager - NMS] -->|GET request - UDP 161| R1[Router Agent]
        MGR -->|GET request| SW1[Switch Agent]
        MGR -->|GET request| FW1[Firewall Agent]
        MGR -->|SET request - modify config| R1
        R1 -->|Response with data| MGR
        SW1 -->|Response| MGR
        FW1 -->|Response| MGR
        R1 -->|TRAP - alert on UDP 162| MGR
        SW1 -->|TRAP - interface down| MGR
    end

The SNMP manager polls agents for data and receives asynchronous traps for alerts

There are four main SNMP operations. GET retrieves a specific piece of data. GET-NEXT walks through the data tree sequentially. SET modifies a value on the device. TRAP is an unsolicited message from the agent to the manager, typically triggered by an event (interface going down, high CPU, disk failure).

Community Strings

In SNMPv1 and SNMPv2c, authentication is handled by community strings. A community string is essentially a password sent in cleartext with every SNMP request. The device checks the community string and grants access if it matches.

By convention (and far too often in practice), the default read-only community string is "public" and the default read-write community string is "private." These defaults ship with virtually every SNMP-capable device and are frequently left unchanged.

The security implications are severe. Anyone who can send UDP packets to port 161 on a device and knows (or guesses) the community string can read the device's entire management data. With the read-write community string, they can modify the device's configuration - change routes, alter ACLs, modify VLAN assignments, or even overwrite the firmware.

Community strings are sent in cleartext. Any network observer between the manager and the device can capture them. Once captured, they provide ongoing access to the device.

The MIB Tree

SNMP data is organized in a hierarchical tree structure called the Management Information Base (MIB). Each piece of data has a unique Object Identifier (OID) - a dotted number string like 1.3.6.1.2.1.1.1.0 (which represents the system description).

MIBs are defined in ASN.1 (Abstract Syntax Notation One) and distributed as text files. Standard MIBs (like MIB-2, defined in RFC 1213) provide a common set of data available on all SNMP devices. Vendor-specific MIBs add proprietary data unique to each manufacturer's devices.

The MIB tree is divided into branches. The most commonly queried branch is iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1), which contains standard management data including system information, interface statistics, IP routing tables, TCP connection tables, and more.

What SNMP Data Exposes

An SNMP walk (querying every OID in the tree) reveals a staggering amount of information about a device and the network it belongs to.

graph TD
    subgraph "Data Exposed via SNMP Walk"
        SYS[System Group] --> SYSD[System description - OS and version]
        SYS --> SYSC[Contact info and location]
        SYS --> SYSU[Uptime]
        IF[Interfaces Group] --> IFD[All interface names and types]
        IF --> IFS[Traffic statistics per interface]
        IF --> IFM[MAC addresses]
        IP[IP Group] --> IPR[Routing table - full network map]
        IP --> IPA[ARP cache - IP to MAC mappings]
        IP --> IPADDR[All IP addresses on device]
        TCP[TCP Group] --> TCPC[Active TCP connections]
        TCP --> TCPL[Listening ports]
        PROC[Host Resources] --> PROCL[Running processes]
        PROC --> PROCM[Memory and CPU usage]
        PROC --> PROCD[Installed software]
    end

A single SNMP walk reveals operating system details, network topology, routing tables, and running processes

System description reveals the device's operating system, version, and hardware platform. This tells an attacker exactly what vulnerabilities to look for.

Interface table lists every network interface, its MAC address, IP address, speed, and current status. This maps the device's network connections.

Routing table shows every route the device knows about. This reveals the network topology - subnets, gateways, and how traffic flows between network segments.

ARP cache maps IP addresses to MAC addresses for recently communicating devices. This identifies active hosts on connected subnets.

TCP connection table shows every active TCP connection, including source and destination IP addresses and ports. This reveals what services are running and who is connecting to them.

Running processes (on servers with the Host Resources MIB) lists every process, its parameters, and resource usage. This can reveal application names, versions, and configuration details.

With this data from a single device, an attacker can build a detailed map of the network, identify high-value targets, and plan further attacks with precision.

SNMP Versions and Security

SNMPv1 (1988): Community strings in cleartext. No encryption. No integrity protection. Trivially sniffable.

SNMPv2c (1996): Improved data types and protocol operations, but the same community string authentication in cleartext. The "c" stands for "community" - the security model is identical to v1.

Both v1 and v2c transmit community strings as plaintext ASCII in every packet. A packet capture tool (Wireshark, tcpdump) on any network segment between the manager and agent will display the community string in readable text.

SNMPv3 - The Fix

SNMPv3 (2002, RFC 3414) finally addressed the security problems. It introduced three security levels:

noAuthNoPriv: Username-based authentication without encryption. Better than community strings but still vulnerable to sniffing.

authNoPriv: Authentication using HMAC-MD5 or HMAC-SHA. Verifies the identity of the sender and prevents message tampering. Data is still visible in cleartext.

authPriv: Authentication plus encryption. Data is encrypted using DES (deprecated) or AES (recommended). This is the only mode that provides both authentication and confidentiality.

SNMPv3 with authPriv using HMAC-SHA and AES encryption provides genuine security. The username, authentication key, and encryption key are never transmitted in cleartext. Messages are authenticated and encrypted, preventing sniffing, spoofing, and tampering.

SNMP on Shodan

Shodan finds millions of devices responding to SNMP on the public internet. Many respond to the default "public" community string. These devices freely share their system descriptions, interface tables, routing information, and more with anyone who asks.

The exposed devices include home routers, enterprise routers, managed switches, printers, UPS systems, and industrial control systems. Many are running SNMPv1 or v2c with default community strings, providing unauthenticated access to sensitive network management data from anywhere on the internet.

Some devices even respond to the "private" community string, granting read-write access. An attacker with read-write SNMP access to a router can modify routes (redirecting traffic through their own systems), change ACLs (opening access to previously restricted services), or upload new firmware.

Defense and Recommendations

Use SNMPv3 with authPriv. If your devices support SNMPv3 (most modern equipment does), configure it with authentication (HMAC-SHA-256 or higher) and encryption (AES-256). Disable SNMPv1 and v2c entirely.

Change default community strings. If you must use SNMPv2c (for legacy devices that do not support v3), change the community strings from "public" and "private" to long, random values. This is not real security - the strings are still sent in cleartext - but it stops automated scanning with default credentials.

Restrict SNMP access by IP. Configure device ACLs to only accept SNMP queries from your management stations' IP addresses. Block SNMP from all other sources, especially the internet.

Disable SNMP where unnecessary. If a device does not need to be monitored via SNMP, disable SNMP entirely. Many devices ship with SNMP enabled by default even when no management system is configured to query them.

Never expose SNMP to the internet. SNMP is a LAN management protocol. There is no legitimate reason for SNMP to be reachable from the public internet. Block UDP 161 and 162 at your network boundary.

Understanding what protocols and services your network devices expose is critical for maintaining security. The BLEShark Nano helps you discover wireless devices on your network, giving you the starting point to audit what services those devices are running and whether they need to be locked down.