--- type: Article title: "SNMP Amplification / DDoS" description: "An exposed SNMP agent on UDP 161 answers a tiny query with a fat reply. Spoof the source and it floods a victim — how the attack works and how to stop it." resource: "https://snmp-monitoring.com/security/amplification-ddos/" tags: [security, snmp] timestamp: 2026-07-13T00:00:00Z --- # SNMP Amplification / DDoS An SNMP amplification attack turns a helpful monitoring agent into a weapon pointed at someone else. It works because SNMP rides on UDP, and UDP is a protocol that answers first and asks questions never. There's no handshake, no proof that the sender is who it claims to be. Send one small query to an exposed agent on UDP 161, and it happily mails back a much larger response — to whatever return address the packet carried. Forge that address, and the reply lands on a stranger. Do this from a botnet, against thousands of open agents at once, and you have a reflection attack big enough to knock a target offline. ## The risk / topic: SNMP Amplification / DDoS Here's the mechanic in plain terms. Two properties combine into the problem. First, SNMP is connectionless: it runs over UDP (see [SNMPv3 vs v2c](/security/v3-vs-v2c.md) for the version details), so the agent never verifies that the source IP asking a question is the machine that will receive the answer. Second, an SNMP reply can be far bigger than the request that triggered it — a compact `GETBULK` can pull back a long list of table rows in one shot. That size difference is the *amplification factor*, and it's what makes the abuse worthwhile. Put the two together. An attacker crafts a query with the victim's IP spoofed into the source field, fires it at an agent that's reachable from the open internet, and the agent's fat reply gets reflected straight at the victim. The attacker spends a trickle of upstream bandwidth; the victim absorbs a flood. This is why the pattern is called both a reflection attack and an amplification attack — the open agent reflects the traffic, and the protocol amplifies it. The agent itself isn't compromised. It's just doing exactly what it was built to do, for the wrong audience. That distinction matters, because it tells you where the fix lives: not in the protocol, but in who's allowed to talk to it. ![Diagram of an SNMP amplification attack: a spoofed-source GETBULK request hits an open UDP 161 agent, which reflects an amplified reply toward the victim IP](https://snmp-monitoring.com/img/security/snmp-amplification-reflection.webp) ## Why it matters The uncomfortable part is that a device you deployed for your own visibility can be conscripted into attacking a third party — with your bandwidth, your IP, and your reputation footing the bill. When an agent is left listening on UDP 161 with a default `public` community and no firewall in front of it, it becomes free infrastructure for whoever scans the internet for such things. And scanning for them is trivial; open UDP 161 responders are cheap to find at scale. Think about who tends to be exposed. It's rarely the carefully managed data-centre core. It's the forgotten stuff: an office printer, a small-branch router, a legacy switch, an IoT gadget that shipped with SNMP enabled and a community string nobody changed. Each one is a small reflector on its own. Aggregate thousands, and the combined outbound firehose is what takes a target down. Your side of the damage is real too — saturated uplinks, angry abuse notices from your provider, and possibly a spot on a blocklist that outlives the incident. There's a quieter cost as well. The same clear-text `GETBULK` that fuels amplification also leaks whatever the agent will divulge — interface lists, software inventories, uptime, hostnames. Reconnaissance and reflection ride the same open door. Rather than lean on any invented incident figures or CVE numbers, the honest framing is simpler: SNMP amplification is a well-documented class of UDP reflection abuse, and the exposure is entirely within your control to remove. For the broader catalog of what goes wrong, see [SNMP vulnerabilities](/security/vulnerabilities.md). ## How to mitigate Mitigation is almost boring, and that's the good news — none of it requires exotic tooling. The through-line: never let an untrusted network reach your agent, and never let it reply to spoofed traffic. Work through these in order. 1. **Take UDP 161 off the public internet.** This single step neutralizes almost the entire attack surface. An agent nobody outside can reach can't be turned into a reflector. Bind it to a management interface or loopback where practical — in `snmpd.conf`, the `agentAddress` line controls exactly what it listens on. 2. **Firewall the port to known collectors.** Allow inbound UDP 161 only from the specific IP addresses of your monitoring systems; drop everything else at the network edge and on the host. If nothing legitimate connects from the wider internet, nothing malicious can either. 3. **Kill the default community.** Replace `public`/`private` with a long, random, read-only string so a scanner can't guess its way in. The [secure community string](/setup/secure-community-string.md) guide covers generating and rotating one. 4. **Move off the default port.** Shifting the agent from 161 to a non-standard port won't stop a determined attacker, but it sidesteps the broad automated scans that only ever probe 161 — see [custom SNMP port](/setup/custom-port.md). 5. **Constrain the view.** Publish only the OIDs you actually poll via an allowlisted `view`, so even an accepted query returns a small, defined slice instead of a giant walk. That shrinks any reply's amplification potential. 6. **Prefer authenticated SNMPv3.** Where the device supports it, SNMPv3's User-based Security Model (RFC 3411–3418) means a request has to be authenticated before it's answered — spoofed, unauthenticated packets get dropped rather than reflected. A hardened `snmpd.conf` pulls most of this together — restricted listen address, random community, a tight read-only view: ```bash # /etc/snmp/snmpd.conf — v2c read-only, allowlisted OIDs agentAddress udp:161,udp6:[::1]:161 # change 161 to a random port for security # sec.name source community com2sec ReadUser default # group sec.model sec.name group ReadGroup v2c ReadUser # view incl/excl subtree view ReadData included .1.3.6.1.2.1.25.1.1.0 # group context model level prefix read write notify access ReadGroup "" any noauth exact ReadData none none ``` Full walkthrough on the [SNMP hardening](/security/hardening.md) page. ## Best practices The habits below keep an agent useful for monitoring while starving the reflection attack of everything it needs. - **Default-deny the port.** Only named collector IPs reach UDP 161; the internet reaches nothing. - **Read-only, always.** No write access, no `SETs` — polling never needs them. - **Random community, rotated.** Treat it like a password, because that's what it is in v2c. - **Minimal view.** Expose the handful of OIDs you poll, nothing more. - **Non-default port** to dodge blanket scans. - **Egress sanity checks.** Watch for unexpected outbound spikes from monitored gear — a reflector betrays itself by sending traffic it was never asked to send. | Control | Blocks reflection? | Effort | Notes | |---|---|---|---| | Firewall 161 to collectors | Yes — primary defense | Low | Removes public reachability | | Random read-only community | Partial | Low | Stops guess-and-walk | | OID allowlist view | Partial | Low | Caps reply size, limits leakage | | Non-default port | Weak, useful | Low | Evades automated 161 scans | | SNMPv3 authentication | Yes | Medium | Drops spoofed, unauthenticated queries | The two rows that carry the load are the firewall and, where available, SNMPv3. The rest is defense in depth — each layer smaller than the last, all of them cheap. ![Illustration comparing an exposed SNMP agent open to the internet versus a firewalled agent reachable only by named collector IP addresses](https://snmp-monitoring.com/img/security/snmp-firewall-vs-open.webp) ## FAQ **What exactly makes SNMP usable for a DDoS?** Two things at once. SNMP runs over UDP, which is connectionless, so an agent never confirms that the source address on a request is genuine — it just replies there. And a small query can trigger a much larger response, so the reply amplifies the attacker's effort. Spoof the victim's IP as the source and the amplified reply is reflected onto them. **Does changing the SNMP port stop an amplification attack?** Not on its own. A non-default port dodges the broad automated scans that only probe UDP 161, which genuinely reduces opportunistic abuse, but a targeted attacker can still find the service. Treat the port change as one layer and put a firewall in front of it as the real control. **Is SNMPv3 immune to reflection?** It's far more resistant. Because SNMPv3 authenticates requests before answering, spoofed and unauthenticated packets are dropped instead of reflected. It's not a licence to expose the agent publicly, though — keep the port restricted regardless of version. **How do I know if my agent is being abused as a reflector?** Look for outbound SNMP traffic the device was never asked to produce — replies leaving toward addresses that aren't your collectors, or unexplained upstream bandwidth spikes. External monitoring that watches from off the box is the reliable way to catch it, since a saturated device is poor at reporting on itself. ## Conclusion An SNMP amplification attack isn't a flaw in SNMP — it's the predictable result of leaving a UDP agent reachable by strangers. Because the protocol is connectionless, source IPs can be spoofed, and a small `GETBULK` reflects an amplified reply at a forged victim. The whole class of abuse evaporates once you enforce access control: get UDP 161 off the public internet, firewall it to your collectors, swap the default community for a random read-only string, trim the view, shift off the default port, and reach for SNMPv3 where you can. Because a device under attack is exactly the device least able to raise the alarm, watch it from outside too. That's the case for [double durability](/monitoring/double-durability.md), and it's what [ostr.io Monitoring](https://ostr.io/service/monitoring) delivers — independent, zero-setup checks from beyond your network, with real-time email and SMS alerts when something starts sending traffic it shouldn't.