By the SNMP Monitoring team · Reviewed July 2026
A protocol built to monitor your infrastructure can, if left exposed, be turned into a weapon against someone else's. SNMP amplification is one of the classic reflection DDoS techniques: an attacker uses your exposed agents to flood a victim with traffic that appears to come from you. This is a purely defensive explainer — enough of the mechanism to understand why your agent is at risk and how to tell if it's exposed, followed by the concrete steps to shut it down. There are no attack commands here, and none are needed to defend.
Parent: security. Related: hardening, vulnerabilities.
How reflection/amplification works
The attack rests on two facts about SNMP: it runs over UDP, and UDP has no handshake to verify who sent a packet. That lets an attacker spoof the source address on a request — writing the victim's IP where their own should be. Your agent receives what looks like a legitimate query from the victim, and dutifully sends its response to the victim. The attacker never receives it; the victim does. Now scale that: a small forged request produces a larger response, and thousands of exposed agents each reflect traffic at the same target. The victim is buried under replies to questions they never asked.
| Stage | Source shown | Relative size |
|---|---|---|
| Attacker → your agent (request) | Victim's IP (spoofed) | Small |
| Your agent → victim (response) | Your agent's IP | Much larger |
The "amplification" is the size ratio between the small request and the large response; the "reflection" is that your agent, not the attacker, delivers the blow. The attacker's own bandwidth is multiplied several times over, and the traffic arrives at the victim wearing your addresses — which is why the victim's logs point at your infrastructure, not the real source. That misdirection is a feature of the attack, not a side effect: it both amplifies the volume and obscures who's responsible.
Why SNMP amplifies
Two properties make SNMP an attractive amplifier. First, the response can be far larger than the request — a compact query can ask for a lot of data, and the agent packs the answer into a much bigger reply. GetBulk, introduced in v2c to retrieve many objects efficiently, is a double-edged tool here: the same efficiency that makes it good for polling large tables also makes a single small request pull back a large volume of data. Point that at a device with big MIB tables — an interface table on a busy router, for instance — and the amplification factor climbs. Second, UDP's lack of a handshake is what permits the spoofing in the first place; a connection-oriented protocol would require a round-trip the attacker can't complete with a forged address. Together, big responses plus spoofable transport are exactly the recipe reflection attacks exploit.
Am I exposed?
The question that matters for defence: is your agent usable as a reflector? The risk condition is straightforward — an agent is a potential reflector if it's reachable from the internet and answers queries (especially with a known or guessable community). To assess your own posture (on hosts you own and administer only):
- Check whether UDP 161 is reachable from outside your network — it should not be.
- Confirm the agent isn't answering default communities like
public. - Verify a source-IP ACL limits which hosts can query at all.
- Review whether any host runs SNMP that doesn't need it.
If UDP 161 is open to the world, assume the agent is a candidate reflector and close it. Diagnosing reachability and response behaviour is covered on troubleshooting; the point of the check is to confirm exposure, not to probe anyone else.
Mitigations
Shutting down the reflector risk is well-understood. In rough priority:
- Never expose UDP 161 to the internet — this single control removes most of the risk.
- Source-IP ACL / firewall — restrict queries to your manager IPs, so forged requests from elsewhere are dropped (firewall).
- Use SNMPv3 — authenticated requests can't be trivially forged by an anonymous attacker.
- Disable SNMP on hosts that don't need it — every unused agent is a potential reflector.
- Rate-limit SNMP responses so an agent can't be driven to flood at high volume.
- OID allowlist — smaller allowed responses reduce the amplification factor (allowlist).
- Egress filtering (BCP 38) — network-level anti-spoofing, covered next.
The consolidated hardening procedure that these feed into is on hardening. Most agents need only the first two to be safe.
For network operators
There's a defence that helps everyone, not just your own agents: BCP 38 egress filtering. Reflection attacks depend on spoofed source addresses, and spoofing only works if forged packets are allowed to leave a network. If every network operator filtered outbound traffic so that packets can only leave with a source address that legitimately belongs to that network, source spoofing would largely stop working — and with it, the whole class of reflection attacks. Implementing anti-spoofing egress filtering at your edge won't protect your agents from being queried, but it stops your network from being the origin of spoofed attacks, and it's part of being a good internet citizen. Combined with not exposing agents, it attacks the problem from both ends.
Frequently asked questions
What is SNMP amplification DDoS?
It's a reflection attack that abuses exposed SNMP agents. An attacker sends small queries to your agents with the source address spoofed to a victim's IP; each agent replies to the victim with a larger response. Multiplied across many agents, this floods the victim with traffic that appears to come from your infrastructure — turning a monitoring protocol into a DDoS weapon.
Why is SNMP used for DDoS?
Two reasons: it runs over UDP, which has no handshake and so allows source-address spoofing, and its responses can be much larger than the requests — especially with GetBulk against large MIB tables. That combination of spoofable transport and high amplification makes an exposed SNMP agent an efficient reflector for attackers.
Is my SNMP agent a reflector?
If UDP 161 is reachable from the internet and the agent answers queries — particularly with a default or guessable community — then yes, it can be abused as a reflector. Agents restricted to your management network with a source-IP ACL, or running SNMPv3, are not usable this way. Check that 161 isn't publicly reachable on any host you run.
How do I prevent SNMP amplification attacks?
Don't expose UDP 161 to the internet; scope it to your managers with a firewall ACL; prefer SNMPv3; disable SNMP on hosts that don't need it; rate-limit responses; and use an OID allowlist to shrink response size. Network operators should also apply BCP 38 egress filtering so spoofed source addresses can't leave their network.
Key takeaways
- SNMP amplification is a reflection attack: spoofed requests make your agents flood a victim.
- It works because SNMP is UDP (spoofable) and responses are larger than requests (GetBulk amplifies).
- Your agent is a reflector if UDP 161 is internet-reachable and answering.
- Top mitigation: never expose 161 publicly; scope it with a firewall ACL.
- Also: SNMPv3, disable unused agents, rate-limit, and an OID allowlist.
- Operators should deploy BCP 38 egress filtering to stop spoofing at the source; see hardening.