--- type: Article title: "SNMP Community Strings" description: "An SNMP community string is a plain-text password carried in every request. Under v1 and v2c it's the whole access story — why 'public' still bites people." resource: "https://snmp-monitoring.com/what-is-snmp/community-strings/" tags: [what-is-snmp, snmp] timestamp: 2026-07-13T00:00:00Z --- # SNMP Community Strings An SNMP community string is the shared secret that a manager presents to an agent before the agent will answer. Think of it as a plain-text password carried in every request. Under SNMPv1 and SNMPv2c it is the *entire* access-control story — get the string right and the agent replies; get it wrong and it stays silent. That is why the community string password matters more than its humble name suggests, and why the public / private community convention still trips people up years into running a network. ## What is Community Strings — definition A community string is a text token that groups a manager and an agent into the same "community" of trust. When you run a query, the string travels inside the SNMP packet; the agent compares it against its own configured value and, on a match, serves the requested data. No match, no answer. There is no username, no handshake, no session — just the string. Two default names show up everywhere. `public` is the conventional read-only community, and `private` is the conventional read-write one. They are conventions, not rules, and leaving them at those defaults is the single most common SNMP misconfiguration on the internet. The community string belongs to SNMPv1 (RFC 1157) and SNMPv2c (RFC 1901); it is essentially a password with none of the protections you would expect a password to have. The word "community" is a relic of SNMP's origins. The designers imagined a *community* of devices and managers that trusted one another because they knew the same string — a lightweight grouping rather than a per-user login. That framing explains a lot of the model's quirks: there is no account, no expiry, no lockout after failed attempts. There is only the string, and either you know it or you don't. ![Diagram showing an SNMP manager sending a community string inside a UDP request to an agent, which checks the public read-only string before returning data](https://snmp-monitoring.com/img/what-is-snmp/community-string-flow.webp) ## How it works Here's the mechanic that surprises newcomers: the community string is sent in clear text. SNMPv2c does no encryption and no cryptographic authentication. Anyone who can capture the UDP packet on the wire reads your string as plainly as you typed it. So the string authenticates you to the agent, but it does nothing to hide itself along the way. A single exchange runs through a fixed sequence, and it repeats for every poll: 1. The manager builds a GET or GETNEXT request and stamps it with the community string. 2. It sends the request to the agent — by default on UDP port 161. 3. The agent compares the string against its configured value. 4. On a match, it checks whether the requested OID falls inside a view that string is allowed to read. 5. It returns the value, or — on any failure — typically stays silent. There's a subtlety worth calling out. The check isn't a single yes/no gate — the agent maps a given community to a specific *group*, and that group to a specific *view* of the MIB tree with a specific access level. So one community might read only the Host Resources subtree while another reads everything, and a write community is often kept entirely separate from the read one. When a request fails the match, the agent's usual behaviour is to stay silent rather than return "wrong password," which is why a bad community looks exactly like a timeout from the client side. That silence is deliberate: it gives a scanner nothing to confirm against. Communities almost always come in two access levels: - **Read-only (RO)** — the manager can GET and walk values but cannot change anything. This is what monitoring needs, and what you should hand out. - **Read-write (RW)** — the manager can also SET values, altering the device's configuration. Powerful, and dangerous if the string leaks. Most monitoring never touches SET, so a read-only community is the right default. On the agent side, a community is bound to a source and a permitted OID subtree, which is how you keep one string from reading the entire device. SNMPv3 abandons this model entirely, swapping the community for real user accounts with authentication and encryption — the reason it exists is precisely the clear-text weakness above. ## Key components / concepts A community string is short, but the pieces around it decide how safe it is. These are the parts worth naming: | Component | Convention / value | What it controls | |---|---|---| | Community name | `public` (RO), `private` (RW) by convention | The secret the agent checks per request | | Access level | Read-only vs read-write | Whether SET is permitted, not just GET | | Source restriction | e.g. `default` or a specific subnet | Which hosts may use the string | | OID view | An included subtree, e.g. `.1.3.6.1.2.1.25` | Which part of the MIB tree the string exposes | | SNMP version | v1 (RFC 1157) / v2c (RFC 1901) | v3 replaces communities with USM users | The `com2sec` and `view` directives in `snmpd.conf` are where these bind together on a Net-SNMP agent. Restricting the source and narrowing the view are what turn a shared password into something you can actually defend — the full mechanics live in the [snmpd.conf guide](/setup/snmpd-conf.md). ## Practical example Say your agent runs SNMPv2c with a read-only community named `public`. Reading the host's uptime OID (`1.3.6.1.2.1.25.1.1.0`, `hrSystemUptime`) is a one-liner: ```bash snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0 ``` ``` HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (184305600) 21 days, 8:10:56.00 ``` The `-c public` flag is the community string. Change it to the wrong value and the request simply times out — the agent won't tell an attacker whether the string was close. On the agent, that community maps to a config block roughly like this: ```bash # sec.name source community com2sec ReadUser default public # group sec.model sec.name group ReadGroup v2c ReadUser ``` To read a whole subtree rather than one value, walk it — the community rides along on every step of the walk: ```bash snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.6 ``` ``` HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 1048576 HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 8912896 ``` Swap `public` for a long random string and you've turned a guessable default into a credible secret. That is exactly what external checkers expect: [ostr.io Monitoring](https://ostr.io/service/monitoring) treats the SNMPv2c community as a password and recommends a random string rather than a dictionary word. Because the string is reused on every single request, a leak isn't a one-time exposure — it hands over standing read access until you rotate it, which is the strongest argument for keeping it random, read-only, and source-restricted. ## Common pitfalls / notes - **Leaving `public`/`private` in place.** Default communities are the first thing scanners try. Rename them to random strings. - **Forgetting it's clear text.** On an untrusted path, capture the packet and you have the string. Keep SNMPv2c on trusted networks, or move to SNMPv3. - **Handing out read-write when read-only would do.** Monitoring rarely needs SET. Give out RO and keep RW off the box entirely. - **Not restricting the source.** A community with `source default` answers anyone. Pin it to your poller's subnet. - **Over-broad views.** A string that can read the whole MIB tree leaks more than it should — narrow the view to the OIDs you actually poll. One practical note: ostr.io's Health Monitoring uses **SNMPv2c** and a public community (a random string as the password), so the community-string model above is exactly what you configure when you point it at your server. It also suggests moving port 161 to a random port for good measure. ![Annotated snmpd.conf snippet highlighting the com2sec community string, the read-only group, and the restricted OID view](https://snmp-monitoring.com/img/what-is-snmp/community-string-config.webp) ## FAQ **Is a community string the same as a password?** Functionally yes — it's a shared secret the agent checks on every request. The catch is that SNMPv1 and SNMPv2c send it in clear text with no encryption, so it protects access to the agent without protecting itself in transit. **What's the difference between the public and private community?** By convention `public` is a read-only community (GET and walk only) and `private` is read-write (it can also SET values). They're naming conventions, not enforced rules, and both should be changed from the defaults. **Does SNMPv3 use community strings?** No. SNMPv3 replaces the community model with the User-based Security Model — named users with authentication and privacy (encryption) keys. If you need credentials that aren't sent in the clear, that's the version to use; see [SNMP versions](/what-is-snmp/snmp-versions.md). **Can I restrict what a community string can read?** Yes. In `snmpd.conf` you bind the community to a group, and the group to a view — an included OID subtree. Anything outside that view is invisible to that string. ## Conclusion The SNMP community string is a small thing with outsized consequences: it's the clear-text password that gates every v1 and v2c request, split by convention into a read-only `public` and a read-write `private` community. Treat it like the credential it is — random value, read-only where possible, source-restricted, narrow view. When you then poll from outside the network, an independent checker still needs that same string, which is why the [double durability](/monitoring/double-durability.md) model and external tooling depend on getting the community right. Next, see how the three [SNMP versions](/what-is-snmp/snmp-versions.md) change the security picture, or configure it all in the [snmpd.conf guide](/setup/snmpd-conf.md).