Scanning SNMP

SNMP is an open standard network protocol for collecting information about devices on a network. There are three main versions of the protocol.

SNMP versions 1 and 2

SNMP version 1 was designed in the 1980s as an interim protocol, intended to be replaced by ISO CMIP. It was built to be used across any network common at the time, not just TCP/IP networks, so security was left up to the host network. The protocol defined a community string for arbitrary organization of groups of assets, but didn’t specify how access should be granted.

SNMP version 2 attempted to introduce a security model based on “parties,” but it wasn’t widely adopted so a revised standard was issued as SNMPv2c. SNMPv2c removed party-based security and went back to just using community strings. The previous SNMPv2 specification is considered obsolete.

Unfortunately, both SNMPv1 and SNMPv2 send community strings in plain text across the network. There’s no encryption of SNMPv1 or v2 data packets, and because the protocol is based on UDP there’s no way to simply add TLS to make a secure connection.

SNMP version 3

SNMPv3 fixes the security problems of SNMPv2 by supporting both password-based authentication and encryption (referred to as privacy protection) as part of the standard. Unfortunately there are multiple algorithms supported for both the encryption and the password authentication, and you have to know which ones your network devices use. Unlike SSH for example, the protocol doesn’t include any kind of negotiation of encryption methods.

SNMPv3 devices can operate in three different modes:

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

runZero’s SNMP support

runZero supports SNMPv1, SNMPv2 (the SNMPv2c variant), and SNMPv3. Scans can be performed using only v1/v2, only v3, or both.

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

SNMPv1/v2 scanning

There are two ways to set up community strings for SNMPv1/v2 scanning. 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, as these are common defaults on network-enabled hardware such as printers and NAS servers. If you remove those defaults, runZero will not probe with them.

The second way to set up community strings is to enter them using the credentials feature as the credential type SNMP v2 Communities. While communities technically shouldn’t be used as credentials because they’re sent in plain text across the network, in practice many networks use them that way. By entering your community strings as credentials, you can use the CIDR allow list feature to control which parts of the network the community strings will be sent to, reducing the risk of their being captured by rogue devices.

If you remove all community strings from the SNMP tab and do not set up any SNMP v2 Communities as credentials, no SNMPv1/v2 scanning will be performed.

SNMPv3 scanning

Most devices which provide potentially sensitive information such as serial numbers and software versions will only do so in response to an authenticated SNMPv3 query. To perform authenticated SNMPv3 scanning, you will need to set up an SNMP v3 Credential record in runZero’s credentials feature.

The authentication protocol determines the hashing algorithm used to process the authentication passphrase – that is, how the runZero Explorer logs in to the remote device.

The most common default algorithm that devices use for authentication is sha (HMAC-SHA-96), which is required to be supported by the SNMPv3 standards. Newer devices may support more secure variants such as SHA-256, and runZero supports up to SHA-512. HMAC-MD5-96 is also supported, as per the standards, but is best not used on your network because the MD5 algorithm is known to be insecure.

The privacy protocol determines how the data sent to and from the remote device is encrypted to prevent eavesdropping. The privacy passphrase is used as seed data to initialize the encryption.

The most common privacy algorithm, required by the original SNMPv3 standards, is CBC-DES-128. It’s selected as des in the runZero user interface. Later RFCs added AES-128, represented as aes. Again, runZero supports more secure variants that may be used by newer devices, such as AES256.

As mentioned above, devices may require only authentication, both authentication and privacy, or neither. For some devices there is only space for a single passphrase in the device configuration. This usually means that the same passphrase is used for both the privacy passphrase and the authentication passphrase, if the device is running in authPriv mode.

As with SNMPv2 community strings, you can set a CIDR allow list to determine which IP addresses SNMPv3 credentials will be sent to. This is particularly recommended if your network is not set up to require privacy passphrases.

In addition to credentialed scanning, runZero will send uncredentialed SNMPv3 probes. Some devices respond to SNMPv3 with useful information without needing any credentials.

To perform SNMPv3 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 disable SNMPv1/v2 and only scan with SNMPv3, remove the community strings from the SNMP tab when setting up a scan or template and ensure that any SNMPv2 community strings stored as credentials are disabled on the Credentials tab.

To disable authenticated SNMPv3 scanning and only scan with SNMPv1/v2, ensure that any SNMPv3 credentials are disabled on the Credentials tab and make sure you have community strings specified, either on the SNMP tab or a credential.

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

How scans are performed

runZero will probe devices using all configured SNMP versions and all community strings. This is because devices often respond with different levels of data for SNMPv3 versus SNMPv2, and may respond with different information depending on community string.

SNMP is based on UDP, and UDP doesn’t guarantee the order of data packets, so it’s impossible to guarantee in what order community strings will be received by remote devices.

SNMPv3 authentication errors are not treated as scan failures. This is because it’s common to have multiple sets of SNMPv3 credentials used on different parts of a network, as well as misconfigured devices with incorrect passphrases.

Checking SNMPv3 credentials and SNMPv1/v2 authentication

If you are not getting SNMP data in your assets and think that you should be, a common cause is network firewalls, which often block SNMP traffic entirely. If possible, deploy an Explorer on the other side of the firewall, on the network segment you want to scan with SNMP.

The second most common reason for not getting the expected SNMP data in assets is incorrect SNMPv3 credentials.

  • If SNMPv3 authentication was attempted, you will see an SNMP engine ID recorded in the asset as snmp.engineID.raw. The engine ID is usually a long string of hex digits and is used to calculate access keys.
  • If SNMPv3 authentication failed, you will see an error reported in the attribute snmp.failedAuth. If the error is a request timeout, that likely indicates that authentication succeeded but the encrypted data channel could not be set up, which means you may have the wrong privacy password or privacy algorithm.
  • If SNMP authentication was attempted successfully (v1/v2 or v3), you will see an snmp.credentials attribute with the UUID of any credentials record that succeeded.
  • If SNMPv1/v2 authentication via community string succeeded, you will see snmp.secretCommunities or snmp.defaultCommunities attributes, depending on the type of community string.
  • If SNMPv1/v2 authentication succeeded using community strings entered directly into the task request rather than credentials records, the snmp.secretCommunities and/or snmp.defaultCommunities attributes will still be present, but snmp.credentials will be a zero UUID.

Debugging credential issues

It can be frustrating to debug SNMPv3 credential problems by trial and error using multiple scan attempts. Instead, you can use the snmpwalk utility. It’s part of the net-snmp open source project, packaged for most Linux distributions and available for macOS via Homebrew. There are unofficial builds for Windows, or you can install it in the Windows Subsystem for Linux (WSL).

The snmpwalk utility will connect to an IP address and dump all of the information it can retrieve. Here’s an example of how to use it to connect 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

(Text above has been line-wrapped, but it’s one long command.) The parameters are:

  • -v3: switch to SNMPv3 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.

If you have the right passphrases and algorithms, you’ll get data back, probably a lot of it. If not, you’ll get an error message which may help identify the cause.

To check SNMPv2 community strings, you can use a command like this:

snmpwalk -v2c -c commstring 10.0.1.25

The -v2c argument chooses SNMPv2 (SNMPv2c) mode, and the -c argument specifies the community string. If you have the wrong community string, snmpwalk will run for a while and then print a timeout error.

Reviewing discovered SNMP services

When SNMP services are found during a scan, their protocol versions are tracked at the asset level where you will see snmp in addition to snmp1, snmp2, and snmp3 depending on which version responded. This makes for performant queries via the asset inventory, such as when querying for protocol:snmp2.

Addtionally, SNMP services track how they authenticated and which protocols they used. If a commonly used value for a SNMPv2 community was used (such as public, private, some vendor defaults, and common values like password, cisco, and community), these will be listed in cleartext in the service details under snmp.defaultCommunities and asset details under snmp.v2DefaultCommunities with the list of communities that responded. If the SNMPv2 community is not a common value, this will be reported as snmp.secretCommunities with a value of true in the service details and in an attribute called snmp.v2SecretCommunities with a value of true in the asset details. If SNMPv3 is used, then snmp.v3Usernames will be populated at the asset level. Lastly, an asset attribute called snmp.auth is populated indicating whether v2DefaultCommunity, v2SecretCommunity, or v3Username was successful to authenticate to the asset.

Object Identifiers (OIDs)

While some of these OIDs are used only for specific vendors, this is a complete list of all OIDs potentially used on a given asset.

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

Please note that Cisco Catalyst & Nexus switches require per-VLAN enumeration using either community indexing (v2) or contexts (v3). runZero automatically enumerates all ARP caches and port tables for each discovered VLAN.

runZero gathers information from SNMP v3 systems even when credentials are not available. This information includes the engineID as well as values from 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
Updated
Previous: Running initial scans Next: Passive sampling