Community Strings
A community string is the access-control mechanism used by SNMPv1 and SNMPv2c - a plain-text string that has to be included with every request, functioning something like a shared password. If the string an agent receives doesn't match one it's configured to accept, the request is silently dropped or rejected, depending on configuration.
By long-standing convention (not any technical requirement), public is typically used for read-only access and private for read-write - but these are just defaults everyone recognizes, not something built into the protocol. Leaving them unchanged on a production device is a well-known, still-common security mistake, since public/private are the very first thing anyone would try.
Read-only vs. read-write communities
An agent can be configured with separate community strings for different access levels:
- Read-only (RO) - permits GET, GETNEXT, and GETBULK. Can't change anything on the device.
- Read-write (RW) - permits all of the above, plus SET, meaning it can actually reconfigure the device.
Read-write community strings deserve real caution - anyone with the string can potentially modify configuration on the device, not just observe it. Many environments deliberately avoid configuring a read-write community at all, and use a dedicated configuration management system instead of SNMP SET for actual changes.
Why community strings aren't real security
The core problem: community strings are sent unencrypted, in every single request, as literal plain text. Anything with visibility into that traffic - a packet capture, a compromised device on the same segment, a misconfigured span port - can read the community string directly off the wire and reuse it. There's also no per-user accountability: everyone using the same community string looks identical to the agent, so there's no way to distinguish who actually made a given request.
This is precisely the gap SNMPv3 was designed to close, with per-user authentication and optional encryption rather than a single shared string everyone uses.
Practical guidance
- Never leave a device on the default
public/privatecommunity strings in production. - Use a community string that's actually hard to guess - not a word related to the company, device, or its function.
- Restrict which source IP addresses are permitted to use a given community string, if the platform supports it (most enterprise network gear does).
- Where possible, prefer SNMPv3 over community-string-based access entirely, especially for anything with write access.
If requests are failing and you suspect the community string might be the issue, see community string / access issues for how to narrow that down from other possible causes like a plain network timeout.