Port 161 SNMP – Free, Online, Private

What listens on 161

Port 161 is where an SNMP agent listens for polls. The IANA name is snmp. A manager sends a GET or GETBULK and the agent answers from 161. Traps and informs from the agent to the manager use UDP 162, snmptrap, which is not this page. The protocol on the wire is UDP. Community strings in SNMPv1 and v2c are passwords sent in the clear. SNMPv3 adds users and encryption and still uses 161. IANA lists TCP as well. The deployments that hurt people are UDP.

The IANA service name is snmp: SNMP. The practical transport is UDP. The checks below use UDP. A UDP socket has no listen state in the TCP sense, so lsof will not show -sTCP:LISTEN and nc cannot complete a handshake. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 161

Service notes for port 161: the IANA name is snmp (SNMP), and the program people mean is SNMP. UDP 161 is the IANA snmp port. Agents answer queries there. Traps are a different port, 162, and a TCP probe does not test SNMP. A public SNMP agent with the community 'public' is a configuration dump of the host, and sometimes a way to write configuration. Do not expose 161 to the internet. Restrict the source addresses to the poller. Prefer SNMPv3 with auth and privacy if the traffic crosses a network you do not control. A community string is not a secret if it is in a ticket from 2009. Rotate it. If you do not use SNMP, the daemon should not be installed. Scanning for 161 is continuous. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 161, you are on the wrong page.

Opening UDP 161 and forgetting that the replies are larger, so a stateful firewall drops them, looks like a dead agent. The request leaves and the response never returns. Another trap is testing with TCP and concluding SNMP is down. Another is two agents, a hardware BMC and the host OS, and you are polling the wrong one. Another is a poller that still uses SNMPv2c after you switched the agent to v3 only. The port is open. The versions do not match.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 161 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. Look for UDP 161 owned by snmpd or a BMC process. From the poller, an snmpget that returns a value is the test. nc -vzu does not build an SNMP PDU. TCP 161 refused is not a result.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• Traps are UDP 162, not 161. Opening only 161 does not deliver traps.
• SNMP is UDP. A TCP scan is the wrong measurement.
• The community string 'public' is not a default you should leave in place.
• A listening agent on 0.0.0.0 is reachable on every address of the host.

Linuxsudo ss -lpun 'sport = :161'
sudo lsof -nP -iUDP:161

macOSsudo lsof -nP -iUDP:161
netstat -anv -p udp | grep '\.161[^0-9]'

Windowsnetstat -ano | findstr :161
Get-NetUDPEndpoint -LocalPort 161

Remotenc -vzu host 161