Avoid typical pitfalls when using SNMP family of protocols
Simple Network Management Protocols, SNMP, refers to protocols family used to probe and control various network devices. It includes three protocol versions (v1, v2c, v3), all of those supported by IPHost Network Monitor.
SNMP is a popular means of watching network devices of any kind (nowadays literally every device with an IP address can support SNMP); however, there are typical problems users can encounter when using SNMP-enabled devices in local or global network. Most common ones are listed below.
Using insecure protocols (v1 and v2c)
Network devices commonly support v1 version of SNMP, often v2c and, less frequently, v3.
SNMP v1 is the most insecure one; all the data it transmits are in plain text (including passwords etc). Even if it’s firewalled from devices not supposed to interact with, monitoring traffic (with tcpdump, WireShark or similar tools) reveals all the protocol exchanges to any interested party.
Unless SNMP v1 is used over an encrypted channel (say, via VPN connection), it’s strongly discouraged against real-life use. Make sure v1 can be disabled in device configuration or blocked with SNMP proxy.
v2c can hash passwords and provides read-only/read-write communities to probe and/or control the device, but in all other aspects it has the same disadvantages as v1.
v3 is recommended in all possible cases. It can be relatively hard to configure, yet it doesn’t leak data and has fairly good chances against typical (such as brute force) attacks.
Run commands like
snmpwalk -v1 -c public hostname snmpwalk -v2c -c public hostname
to check whether SNMP v1/v2c are safely switched off.
Using default settings
Community names like “public” are typical for default SNMP services configurations, for both hardware and software-based.
Among first actions, before putting the device in order, should be all default credentials replacement. Please note that default settings also assume device can be, to certain extent, configured via SNMP.
Default settings are wide known; they are first tried in all network scanning attempts.
Unless device is firewalled, it can be easily detected and used by possible perpetrator. SNMP v1 and v2c do not provide efficient security means (apart from “security through obscurity”, by using non-trivial community names).
Leaving write access allowed
Unless SNMP is expected to be used to control the device, all “write” functions should be explicitly disabled.
Default write access can provide enough rights to switch device offline, change its identity and/or otherwise reconfiguring it. Unless there are valid reasons, write access should be allowed to selected users only (by means of proper credentials and/or filtering via firewall).
Depending on device type, entire device can be reconfigured if write access is allowed. Thus, until access rights are set up and tested, device should not enable public SNMP access.
Common security flaws
There can also be typical security flaws not related directly to SNMP protocol implementation: using weak passwords (which can be found via brute forcing); providing too broad access rights (firewall should be applied to only allow access from trusted IP addresses/networks).
The above should be checked for all SNMP monitors, including SNMP traps. The latter should also be set up properly, to avoid too frequent calling (otherwise, that could result in efficient DoS attack against monitoring system).
Default SNMP settings are insecure in the majority of cases. Thus, SNMP devices should be first configured and run in sandbox environment, while all the security precautions are taken and credentials are properly changed.
Do you have any other pieces of advice on setting up SNMP properly? Can you share your insights of SNMP monitoring? If yes, please either contact us, or use the comments below.