Scanning with SNMP

SNMP is an open standard network protocol for collecting information about devices on a network. runZero scans with all three main versions of the protocol. With the right community strings or SNMP v3 credentials, a scan collects details such as serial numbers, device models, ARP caches, and switch port tables. If an asset is missing SNMP data, skip ahead to Checking SNMP v3 credentials and SNMP v1/v2 authentication.

SNMP versions 1 and 2

SNMP v1 and SNMP v2 both send community strings across the network in plain text. Neither version encrypts its data packets, and because SNMP runs over UDP, there’s no way to add TLS for a secure connection.

SNMP version 1 was designed in the 1980s as an interim protocol, meant to be replaced by ISO CMIP. It was built to run on any network common at the time, not only TCP/IP, so security was left to the host network. The protocol defined a community string for grouping assets in any way you liked, but didn’t specify how access should be granted.

SNMP version 2 tried to introduce a security model based on “parties,” but it wasn’t widely adopted, so a revised standard was issued as SNMP v2c. SNMP v2c dropped party-based security and went back to plain community strings. The original SNMP v2 specification is considered obsolete.

SNMP version 3

SNMP v3 fixes the security problems of SNMP v2 by building password-based authentication and encryption (called privacy protection) into the standard. The catch is that the standard allows several algorithms for both authentication and encryption, and you have to know which ones your network devices use. Unlike SSH, for example, the protocol has no negotiation of encryption methods.

SNMP v3 devices operate in one of three modes:

• noAuthNoPriv: no authentication and no privacy protection (no encryption).
• authNoPriv: authentication is required, but there’s still no privacy protection.
• authPriv: both authentication and privacy protection are required.

runZero’s SNMP support

runZero scans with SNMP v1, SNMP v2 (the common v2c variant), and SNMP v3. A scan can use only v1/v2, only v3, or both.

SNMP scanning is on by default. You can turn it off or customize it on the SNMP tab when you set up a scan or a scan template.

SNMP v1 & v2 scanning

You can set up community strings for SNMP v1/v2 scanning in two ways. The first is to enter them as a comma-separated list on the SNMP tab. By default, runZero supplies the community strings public and private, which are common defaults on network-enabled hardware such as printers and NAS servers. If you remove those defaults, runZero does not probe with them.

The second is to store them in the credentials feature as the credential type SNMP v2 Communities. Communities technically shouldn’t be used as credentials, because they cross the network in plain text, but in practice many networks use them that way. Storing your community strings as credentials lets you use the CIDR allow list feature to control which parts of the network receive them, which reduces the risk of a rogue device capturing them.

If you remove all community strings from the SNMP tab and store no SNMP v2 Communities as credentials, runZero performs no SNMP v1/v2 scanning.

SNMP v3 scanning

Most devices only give up potentially sensitive information, such as serial numbers and software versions, in response to an authenticated SNMP v3 query. To perform authenticated SNMP v3 scanning, set up an SNMP v3 Credential record in runZero’s credentials feature.

The authentication protocol sets the hashing algorithm that processes the authentication passphrase: in other words, how the runZero Explorer logs in to the remote device.

The most common default authentication algorithm on devices is sha (HMAC-SHA-96), which the SNMP v3 standards require. Newer devices may support more secure variants such as SHA-256, and runZero supports up to SHA-512. runZero also supports HMAC-MD5-96, as the standards require, but avoid it on your network because the MD5 algorithm is known to be insecure.

The privacy protocol determines how data to and from the remote device is encrypted against eavesdropping. The privacy passphrase seeds the encryption.

The most common privacy algorithm, required by the original SNMP v3 standards, is CBC-DES-128, selected as des in the runZero user interface. Later RFCs added AES-128, represented as aes. runZero also supports more secure variants that newer devices may use, such as AES256.

As described above, devices may require only authentication, both authentication and privacy, or neither. Some device configurations have room for only a single passphrase. This usually means the device uses the same passphrase for both privacy and authentication when it runs in authPriv mode.

As with SNMP v2 community strings, you can set a CIDR allow list to control which IP addresses receive SNMP v3 credentials. This is especially recommended if your network doesn’t require privacy passphrases.

Beyond credentialed scanning, runZero also gathers information from the SNMP v3 pre-authentication handshake.

To perform SNMP v3 scanning across Cisco switches, modify the ACLs to include the following rule:

• Newer IOS versions: snmp-server group YourGroupName v3 auth context vlan- match prefix
• Older IOS versions: snmp-server group YourGroupName v3 auth context vlan-1 (repeated for every VLAN)

Choosing which versions of SNMP are scanned

To scan with SNMP v3 only, remove the community strings from the SNMP tab when you set up a scan or template, and disable any SNMP v2 community strings stored as credentials on the Credentials tab.

To turn off authenticated SNMP v3 scanning and scan with SNMP v1/v2 only, disable any SNMP v3 credentials on the Credentials tab and specify community strings, either on the SNMP tab or in a credential.

To turn off all SNMP scanning, including uncredentialed SNMP v3, switch off the toggle on the SNMP tab labeled Use the SNMP protocol for discovery.

How scans are performed

runZero probes each device with every configured SNMP version and every community string, because devices often return different levels of data for SNMP v3 than for SNMP v2, and may return different information for different community strings.

SNMP runs over UDP, which doesn’t guarantee packet order, so there’s no way to control the order in which a remote device receives the community strings.

SNMP v3 authentication errors don’t count as scan failures, because networks commonly use different sets of SNMP v3 credentials on different segments, and misconfigured devices with incorrect passphrases are common too.

Checking SNMP v3 credentials and SNMP v1/v2 authentication

If an asset you expected to have SNMP data has none, a common cause is a network firewall, which often blocks SNMP traffic entirely. If you can, deploy an Explorer on the far side of the firewall, on the network segment you want to scan with SNMP.

The second most common cause is incorrect SNMP v3 credentials. The asset’s attributes tell you what happened:

• If runZero attempted SNMP v3 authentication, the asset records an SNMP engine ID as snmp.engineID.raw. The engine ID is usually a long string of hex digits and is used to calculate access keys.
• If SNMP v3 authentication failed, the attribute snmp.failedAuth reports the error. A request timeout likely means authentication succeeded but the encrypted data channel could not be set up, so you may have the wrong privacy password or privacy algorithm.
• If SNMP authentication succeeded (v1/v2 or v3), the snmp.credentials attribute holds the UUID of each credentials record that succeeded.
• If SNMP v1/v2 authentication with a community string succeeded, the asset has snmp.secretCommunities or snmp.defaultCommunities attributes, depending on the type of community string.
• If SNMP v1/v2 authentication succeeded with community strings entered directly into the task request rather than stored as credentials, the snmp.secretCommunities and/or snmp.defaultCommunities attributes are still present, but snmp.credentials is a zero UUID.

Debugging credential issues

Trying to debug SNMP v3 credential problems by trial and error, one scan at a time, is frustrating. Use the snmpwalk utility instead. It’s part of the net-snmp open source project, packaged for most Linux distributions and available for macOS through Homebrew. Windows has unofficial builds, or you can install it in the Windows Subsystem for Linux (WSL).

snmpwalk connects to an IP address and dumps all the information it can retrieve. This example connects in authPriv mode with both authentication and privacy passphrases:

snmpwalk -v3 -l authPriv -a SHA -A "authentication passphrase"
  -x AES -X "privacy passphrase" -u username 10.0.1.25

(The text above is wrapped onto two lines, but it’s one command.) The parameters are:

• -v3: switch to SNMP v3 mode.
• -l authPriv: run in authPriv mode, with both authentication and privacy required.
• -a SHA: authentication algorithm is SHA (SHA-128).
• -A: specify the authentication passphrase as the next argument.
• -x AES: privacy (encryption) algorithm is AES (AES-128).
• -X: specify the privacy passphrase as the next argument.
• -u username: specify the login username.
• 10.0.1.25: the IP address to probe.

With the right passphrases and algorithms, you get data back, probably a lot of it. Otherwise you get an error message that may point to the cause.

To check SNMP v2 community strings, use a command like this:

snmpwalk -v2c -c commstring 10.0.1.25

The -v2c argument selects SNMP v2 (SNMP v2c) mode, and -c specifies the community string. With the wrong community string, snmpwalk runs for a while and then prints a timeout error.

Reviewing discovered SNMP services

When a scan finds SNMP services, runZero tracks their protocol versions at the asset level: you see snmp along with snmp1, snmp2, and snmp3, depending on which versions responded. That keeps asset inventory queries such as protocol:snmp2 fast.

SNMP services also record how they authenticated and which protocols they used. If a common SNMP v2 community value worked (such as public, private, some vendor defaults, and common values like password, cisco, and community), the service details list the communities that responded in cleartext under snmp.defaultCommunities, and the asset details list them under snmp.v2DefaultCommunities. If the SNMP v2 community is not a common value, the service details report snmp.secretCommunities with a value of true, and the asset details carry an attribute called snmp.v2SecretCommunities with a value of true. If SNMP v3 was used, runZero populates snmp.v3Usernames at the asset level. Finally, an asset attribute called snmp.auth records whether v2DefaultCommunity, v2SecretCommunity, or v3Username authenticated to the asset.

Improving OS fingerprinting using Net-SNMP’s extend feature

On some Linux distributions, the data Net-SNMP provides isn’t enough to fingerprint the OS correctly. Distributions based on Red Hat Enterprise Linux, such as AlmaLinux OS, CentOS, Oracle Linux, and Rocky Linux, all return exactly the same values for a given point release. Net-SNMP’s extend mechanism, which runs a defined command and returns its output over SNMP, can improve the result. Each target asset must run Net-SNMP as its SNMP software, and you must modify its SNMP configuration:

1. Modify /etc/snmp/snmpd.conf and

   1. Add the line:

      extend os-release /bin/cat /etc/os-release

   2. Grant the SNMP community string or user that runZero uses the right to collect the data by adding a line like:

      view systemonly included .1.3.6.1.4.1.8072.1.3.2

2. Restart the SNMP service:

   sudo systemctl restart snmpd
   

3. Verify that the community string or account the runZero task will use can access the OID.

   snmpwalk -v2c -c commstring 10.0.1.25 .1.3.6.1.4.1.8072.1.3.2.3.1.2.10.111.115.45.114.101.108.101.97.115.101
   

Object identifiers (OIDs)

This is the complete list of OIDs runZero may query on an asset. Some apply only to specific vendors.

System attributes

• 1.3.6.1.2.1.1.*.0

IP addresses

• .1.3.6.1.2.1.4.20.1.3.*

MAC addresses

• .1.3.6.1.2.1.2.2.1.6.*

ARP caches

• .1.3.6.1.2.1.4.35.1.4.*
• .1.3.6.1.2.1.3.1.1.2.*
• .1.3.6.1.2.1.4.22.1.2.*

Routes

• .1.3.6.1.2.1.4.24.7.1.7.*

Port (CAM) tables

• .1.3.6.1.2.1.17.7.1.2.2.1.2.*
• .1.3.6.1.2.1.17.4.3.1.2.*

VLANs

• .1.3.6.1.2.1.17.7.1.4.3.1.1.*
• .1.3.6.1.4.1.9.9.46.1.3.1.1.4.1.*

Interface names

• .1.3.6.1.2.1.17.1.4.1.2.*
• .1.3.6.1.2.1.31.1.1.1.1.*

Serial numbers

• .1.3.6.1.2.1.47.1.1.1.1.11.*

Device models

• .1.3.6.1.2.1.47.1.1.1.1.13.*

Hostnames

• .1.3.6.1.4.1.9.2.1.3.*

Model names from Juniper switches

• .1.3.6.1.4.1.2636.3.1.2.0.*

Serial numbers from A10 devices

• .1.3.6.1.4.1.22610.2.4.1.6.2

OS release information from Net-SNMP’s extend functionality (see above)

• .1.3.6.1.4.1.8072.1.3.2.3.1.2.10.111.115.45.114.101.108.101.97.115.101

runZero gathers information from SNMP v3 systems even when no credentials are available. This information includes the engineID and the values of the following OIDs:

• .1.3.6.1.6.3.15.1.1.1.0: usmStatsUnsupportedSecLevels
• .1.3.6.1.6.3.15.1.1.2.0: usmStatsNotInTimeWindows
• .1.3.6.1.6.3.15.1.1.3.0: usmStatsUnknownUserNames
• .1.3.6.1.6.3.15.1.1.4.0: usmStatsUnknownEngineIDs
• .1.3.6.1.6.3.15.1.1.5.0: usmStatsWrongDigests
• .1.3.6.1.6.3.15.1.1.6.0: usmStatsDecryptionErrors