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 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.

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.

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 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.
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:

# /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   <password>

#       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 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.

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.