Avoid typical pitfalls when using SNMP family of protocols
Simple Network Management Protocol, SNMP, refers to a family of protocols used to query and sometimes control network devices. It includes three protocol versions (v1, v2c, v3), all of them supported by IPNetwork Monitor.
SNMP remains one of the most common ways to monitor network devices, servers, and appliances. However, there are several typical pitfalls when SNMP-enabled devices are used in production networks. The most common ones are listed below.
Using insecure protocols (v1 and v2c)
Network devices commonly support SNMP v1 or v2c, and many also support v3. The important practical difference is security.
SNMP v1 and v2c both rely on community strings and do not provide transport privacy; your current IPNetwork documentation explicitly groups SNMP v1/v2c among protocols that pass data without encryption. In real-life use, they should be avoided wherever possible, especially across shared or untrusted networks.
SNMP v3 is the preferred option wherever supported, because it adds a user-based security model with authentication and privacy settings. Current IPNetwork settings and MCP docs also reflect this by separating v1/v2c community configuration from v3 authentication and privacy parameters.
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 still common in default SNMP examples and factory-style configurations. One of the first actions before putting a device into production should be replacing all default communities and disabling any default write access that is not actually required.
Default settings are widely known and are among the first things tried during automated scans. If a device is reachable and still exposes weak or default SNMP settings, it is much easier to enumerate and misuse. For SNMP v1/v2c in particular, changing only the community string is not a complete security strategy; firewalling and access restriction are still required.
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 tied directly to the SNMP protocol itself: weak credentials, overly broad source access, and unnecessary exposed ports. IPNetwork security guidance explicitly recommends blocking unused service ports and checking the actual configured port values in Settings > System rather than assuming defaults.
The same applies to SNMP traps. Current setup guidance recommends first verifying the actual trap receiver UDP port, then using a temporary test trap monitor that accepts any OID and any community only for debugging, and narrowing it afterward. This reduces both setup mistakes and the risk of leaving an overly broad trap receiver in production.
In distributed environments, Remote Network Agents are also relevant here: they can receive SNMP traps inside the remote network and connect back to the main service over TLS-protected agent links, which can be cleaner than exposing trap collection directly across every network boundary.
Conclusion
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.