Change the SNMP Port

You can change the SNMP port in a single line, and on any internet-facing agent you probably should. By default the SNMP agent listens on UDP 161 — a number every port scanner on earth checks first. Moving the service to a non-default SNMP port won't make a weak configuration strong, but it does make your agent invisible to the automated sweeps that trawl 161 all day looking for open communities. It's cheap, it's fast, and it pairs neatly with the other hardening steps. This guide covers the one-line change in snmpd.conf, the firewall rule that has to follow it, and how to query the moved agent so your monitoring doesn't break in the process.

Prerequisites

Before you touch the port, get these in order:

• A working SNMP agent on UDP 161 — if it isn't running yet, start at Install snmpd on Ubuntu/Debian.
• Root or sudo to edit /etc/snmp/snmpd.conf and manage the firewall.
• A chosen port number. Pick something high and unremarkable in the 1024–65535 range, and check it doesn't clash with another service (ss -lnu shows what's already listening on UDP).
• Firewall access — ufw, firewalld, iptables, or a cloud security group — because moving the listener without moving the firewall rule just breaks polling.
• A test client with snmpwalk to confirm the agent answers on its new home.

Also warn anyone or anything that already polls this host. Every poller, script, and monitoring endpoint pointed at :161 needs updating, or it'll start timing out the moment you restart.

Step-by-step

The move itself is trivial; the follow-through is what people miss. Do all five.

1. Open the config:

   sudo nano /etc/snmp/snmpd.conf
   

2. Edit the agentAddress line to your chosen port — here, 16161:

   agentAddress udp:16161,udp6:[::1]:16161
   

   That single directive is the whole port change. Everything else in the file — community, groups, views — stays exactly as it was.
3. Restart the agent so it rebinds:

   sudo service snmpd restart
   

4. Open the new port in the firewall and, ideally, close the old one. With ufw:

   sudo ufw allow from 10.20.0.0/24 to any port 16161 proto udp
   sudo ufw delete allow 161/udp
   

   Scope the rule to your poller's subnet rather than opening the port to the world — a moved port plus a tight source is far stronger than either alone.
5. Update every client that polls this host to include the new port, and confirm nothing is still hammering 161.

There's one subtlety worth naming. SNMP runs over UDP, so a firewall that silently drops packets to the old port produces a timeout, not a refusal — which looks identical to a dead agent. When you test, a hang almost always means a firewall or client still stuck on 161, not a broken daemon. Keep that in mind and the debugging goes quickly.

Configuration example

The default vs a hardened port choice:

The change lives on one line. Here it is in context with a comment marking the before-and-after:

# /etc/snmp/snmpd.conf  (excerpt)

# Default (scanned constantly):
# agentAddress udp:161,udp6:[::1]:161

# Custom non-default port:
agentAddress udp:16161,udp6:[::1]:16161

And the matching firewall rules, scoped to a monitoring subnet:

# Allow only the poller subnet to reach the new UDP port
sudo ufw allow from 10.20.0.0/24 to any port 16161 proto udp
# Remove the stale rule for the old port
sudo ufw delete allow 161/udp

Notice what didn't change: the com2sec, group, view, and access directives are untouched. Moving the port is purely a listener change — it doesn't alter who may read which OIDs, and it isn't a substitute for a strong community. The default of 161 is registered to SNMP for a reason, so document your custom port somewhere your team will find it; an undocumented port is a support ticket waiting to happen. The full ACL those other directives control is covered on the snmpd.conf page.

Verify it works

Restart, then prove the agent answers on the new port and confirm the old one is closed.

service snmpd status

From your test machine, walk host uptime, appending the new port to the host with a colon:

snmpwalk -v2c -c <community> <host>:16161 1.3.6.1.2.1.25.1.1.0

A returned hrSystemUptime value means the moved agent is reachable and your firewall rule is correct. Then confirm 161 no longer answers:

snmpwalk -v2c -c <community> <host>:161 1.3.6.1.2.1.25.1.1.0

A timeout here is the result you want — it means nothing is listening on the old, heavily scanned port anymore. Remember the colon-port syntax (<host>:16161); leaving it off sends the query to 161 by default and produces a confusing hang that has nothing to do with your config.

Security note

A non-default port is obscurity, not security — useful, but only as one layer. Stack it with the rest:

• Don't rely on the port alone. Keep a strong random community string; a moved port with public is still trivially owned once found.
• Scope the firewall to known pollers, so even a discovered port refuses strangers.
• Prefer high, unremarkable ports over near-161 numbers like 162 (that's the trap port) or 1161.
• Keep access read-only in the config — moving ports changes nothing about write protection.
• Log and review what still probes the old port; it tells you who hadn't got the memo.
• See the broader model on the security overview.

Obscurity buys you quiet. Real protection still comes from the community, the source restriction, and read-only access working together.

Next: connect external monitoring

Changing the port has a practical knock-on effect: any external monitor needs to know the new number too. That's a feature, not a nuisance — it means only endpoints you've explicitly configured can reach the agent. And you'll want an external endpoint, because the alerts that matter are the ones that arrive when the server itself has gone quiet. Polling from outside your network is what makes that possible, the core idea behind double durability: an independent watcher keeps checking straight through the failures that mute on-host tools.

ostr.io Monitoring lets you specify the exact SNMP port when you register a server, so your custom port is just a field in the setup — it then polls from outside your infrastructure and fires real-time email and SMS alerts on any threshold breach. The add-endpoint guide shows where the port goes.