Wondering what an SNMP community string is and whether yours is safe? It is a shared password that lets a manager read or change a device’s data, and the default values are risky.
This guide is part of our coverage of SNMP, the protocol that monitoring tools use to talk to routers, switches and printers.
| Item | Value |
|---|---|
| Default read-only string | public |
| Default read/write string | private |
| Community names most agents support | 3 (read-only, read-write, trap) |
| Agent port for requests | 161/UDP |
| Versions that use community strings | SNMPv1 and SNMPv2c |
Figures come from NCSC Ireland’s SNMP guidance and Wikipedia’s SNMP article. They can change, so check the sources before you rely on them.
What an SNMP community string actually is
SNMP works by asking devices questions. A monitoring system, called the manager, sends a request to a small program on the device, called the agent, and the agent replies with a value such as interface traffic or CPU load.
Before the agent answers, it needs some way to decide whether the request is allowed. In the older protocol versions, that check is the community string: a text value that travels inside every request. If the string matches one the agent knows, the request is processed.
NCSC Ireland puts it plainly: “SNMP supports trivial authentication by using a community name, which serves as a password for either retrieving or modifying management data.” The word “trivial” is accurate. There is no username, no challenge and no second factor.
How the agent uses the string
Every SNMPv1 or SNMPv2c message carries a few header fields, and the community value sits right next to the version number. Wikipedia describes the layout as “version community PDU-type request-id error-status error-index variable bindings”.
When a request arrives, the agent decodes it and then checks the community. Wikipedia explains: “A successfully decoded SNMP request is then authenticated using the community string.” If the check fails, the message is dropped and the agent can send a trap saying that authentication failed.
That trap is useful for you. A burst of authentication-failure traps often means someone, or a misconfigured monitoring tool, is guessing strings.
Read-only, read-write and trap strings
A single string is not always enough. Wikipedia notes that “Most agents support three community names, one each for read-only, read-write and trap.” Each one controls a different kind of activity.
- Read-only: lets a manager fetch values. Wikipedia states that “The read-only community applies to get requests.”
- Read-write: lets a manager also change settings on the device, which is far more dangerous if it leaks.
- Trap: the community used when the agent sends unsolicited alerts to a manager.
The vendor defaults are well known. NCSC Ireland writes: “The default community string for read-only access is ‘public’, while the default community string for read/write access is ‘private’.”
Because those two words are what every scanner tries first, leaving them in place is the same as leaving no password at all.
Why community strings are a security weak point
The main problem is that the string is not protected in transit. Wikipedia says that in SNMPv1 and SNMPv2c the string “is transmitted in clear text to other devices” and adds that “Clear-text passwords are a significant security risk.”
Anyone who can capture traffic between the manager and the agent can read it. Some organisations accept that on a trusted internal network. Wikipedia observes that the name is then treated as a de facto password, “in spite of the original specification.”
Guessing is the other route. NCSC Ireland describes how an attacker who finds a device listening on 161/UDP will “initiate a brute force and dictionary attack to identify the community string”.
A device that answers to public on the open internet can also be abused for reflection attacks. In NCSC Ireland’s words, it “can be abused for a Distributed Denial of Service (DDoS) Reflection attack against a third party.”
Choosing and handling strings safely
If a device only supports the older versions, you can still reduce the risk. These steps are ordinary hardening practice, and they cost nothing.
- Replace public and private on every device before it goes into production.
- Use long, random strings, and a different one for each site or device group rather than one shared everywhere.
- Disable the read-write string unless you truly need to change settings over SNMP.
- Restrict which manager addresses the agent accepts requests from, using the device’s access list feature.
- Block SNMP from the internet at your firewall, so that only management hosts can reach the agent.
- Watch for authentication-failure traps and investigate repeats.
Treat a community string like any other credential. Keep it in your password manager or the monitoring tool’s credential store, not in a shared spreadsheet or a chat message.
If you rotate strings, update the monitoring system at the same time. Otherwise the tool will start reporting devices as down when the real cause is a mismatch.
Community strings versus newer SNMP versions
SNMPv1 and SNMPv2c both rely on community strings, and neither encrypts them. Wikipedia sums it up: “SNMPv1 and SNMPv2c use communities to establish trust between managers and agents.”
SNMPv3 replaces that model with per-user security. Each message contains security parameters, and the protocol can authenticate users and encrypt data. To compare the three releases in more detail, read our guide to SNMP versions.
If your devices support SNMPv3, it is the better choice for anything that crosses a network you do not fully control. If they do not, keep SNMPv1 and v2c on an isolated, trusted management network or behind an authenticated encrypted tunnel, because the hardening list above does not protect the string in transit.
The community’s configured access policy can also limit what may be read or written. The objects themselves are defined in MIB files, which our explanation of the SNMP MIB covers.
Testing that your strings work
When a monitoring tool cannot see a device, the community string is the first thing to check. A typo, a trailing space or a wrong case will produce silence, because the agent simply drops the request.
Query the device with a command-line tool or a MIB browser using the exact string, and confirm the version matches what the agent is configured for. Then check any access list that limits the source address.
Do not test with the default strings on production gear. If a default works, that is your finding: change it.
Frequently asked questions
Is an SNMP community string the same as a password?
Show answer
Functionally yes, but a weak one. It acts as a shared secret, and Wikipedia notes it is sent in clear text in SNMPv1 and SNMPv2c, so it offers much less protection than a normal login.
What is the default SNMP community string?
Show answer
NCSC Ireland lists “public” as the default for read-only access and “private” as the default for read/write access. Change both before deployment.
Does SNMPv3 use community strings?
Show answer
No. SNMPv3 uses user-based security parameters in each message instead of a shared community string.
Can I use the same string on all my devices?
Show answer
You can, but one leak then exposes everything. Using separate strings per group of devices limits the damage.
