Skip to content

Secure SNMP with SNMPv3

Replace clear-text community strings with signed, encrypted SNMPv3 for sensors, discovery, device details, the map, port monitoring and interface names.

5 min read · For admins

SNMP v1 and v2c send the community string in clear text, so anyone on the path can read it and then read your devices. SNMPv3 replaces it with a user name and passphrases: every message is signed, and with privacy on it is encrypted too, so a listener can neither read nor replay it. Monitaria can use SNMPv3 for SNMP sensors, CPU, memory and disk sensors, discovery, device details, the map's neighbor tables, WAN link sensors, port monitoring and the interface names in Traffic, and reads each device with its own credential.

Before you start

Set up an SNMPv3 user on each device and note its user name, security level, protocols and passphrases (at least 8 characters each). Monitaria supports SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and MD5 for authentication, and AES-128, AES-192, AES-256 and DES for privacy; keep MD5 and DES for old gear that has nothing better. Make sure the device allows SNMP from the collector's address. A typical user looks like this, with your own passphrases:

! Cisco IOS
snmp-server group MONITOR v3 priv
snmp-server user monitaria MONITOR v3 auth sha <auth passphrase> priv aes 128 <privacy passphrase>

# Net-SNMP
createUser monitaria SHA "<auth passphrase>" AES "<privacy passphrase>"
rouser monitaria priv

1. Add an SNMPv3 credential

  1. Open Settings › Credentials. Under Add a credential, set Kind to SNMPv3 and enter a Name, such as Core switches.
  2. Enter the User name and choose the Security level: Authentication and privacy (recommended), Authentication only, or None (user name only). The form shows only the fields that level needs.
  3. Choose the Authentication protocol and enter the Authentication passphrase, then the Privacy (encryption) protocol and the Privacy passphrase. Use exactly what is set on the device.
  4. Leave Context name (optional) empty unless the device needs one, and choose Save.

2. Use it

  • An SNMP sensor: in Devices › Sensors, choose Edit on the sensor, set SNMP version to v3 (user and passphrases), pick the SNMPv3 credential and save.
  • CPU, memory and disks: open the device and, under Add computer sensors, pick SNMPv3: Core switches next to Add over SNMP, then choose Add over SNMP. This device's SNMP settings uses whatever its SNMP sensors already use, an SNMPv3 credential included.
  • Discovery: open Devices › Discovery. Under Automatic discovery, tick the SNMPv3 credentials to try and order them with the arrows. Set Try SNMPv3 to after the communities, or to instead of the communities (SNMPv3 only) so no community string leaves the collector, and choose Save SNMPv3 settings.
  • Discovery remembers which credential answered each device, shows it in the results, such as SNMPv3 (Core switches), tries that one first next time and gives the sensors it proposes the same credential. Forget clears what it remembered for a device.
  • Device details, the map's neighbor tables, Add WAN sensors on the map, port monitoring (Devices › Ports) and the interface names in Traffic need nothing more: they read each device with the access its SNMP sensors have.

3. Check it works

Settings › SNMPv3 lists every device read over SNMP with its access, SNMP engine ID and last answer; the numbers at the top filter it (read over SNMPv3, answering, failing, no answer yet, still on v1/v2c). Under Test a device, enter an Address such as 192.0.2.20, choose the Credential and choose Test: it reads the device's name and description and saves nothing. A device's own dialog shows the same under SNMP access, where admins also get Test SNMPv3 now.

If a sensor goes Down

  • unknown user name: the user doesn't exist on the device, or is spelled differently.
  • wrong authentication passphrase: check the passphrase and the authentication protocol.
  • cannot decrypt: the privacy passphrase or protocol is wrong. With AES-192 or AES-256, try the other key extension: the plain option or the one marked Cisco key extension.
  • unsupported security level: the user on the device has a different level. Make authentication and privacy match.
  • answered SNMPv3 discovery but not the request: many devices silently drop what they can't decrypt, so this usually means a wrong privacy passphrase or protocol, or a security level that doesn't match.
  • no SNMP response: the device doesn't answer at all. Check the address, that SNMPv3 is turned on and that the device allows SNMP from the collector.

Good to know

  • Passphrases are write-only: never shown again, never returned by the API and never sent to the hub. Leave them empty when you change a credential to keep the stored ones.
  • A replaced or factory-reset device at the same address is picked up by itself: Monitaria rediscovers its SNMP engine and tries again. Settings › Webhooks can send an SNMPv3 event when that happens, or when a device starts rejecting its credential.
  • SNMP traps arrive as v1 and v2c only: SNMPv3 traps are counted but not read (see the syslog guide).
  • Only GET and GETNEXT are used: no GETBULK, SET, traps or informs over SNMPv3. There's no 3DES, and keys always come from passphrases.
  • SHA-1 and MD5 with AES-128 and DES have been tested with Net-SNMP. SHA-2 and AES-192/256 have so far been tested against Monitaria's own simulator only, so use Test a device before rolling them out.
  • A credential that discovery tries can't be deleted until you untick it there.
  • The discovery command line still takes communities only. Scans started from Devices › Discovery use the SNMPv3 settings.