162
Summary
- // if you see it open
- SNMPv1/v2c trap messages travel in cleartext, leaking device state, topology, and community strings to passive interception; 'public'/'private' community strings provide no real authentication. SNMP is a known DDoS reflection vector, though amplification typically abuses query port 161 rather than the 162 trap port. SNMPv3 AuthPriv mode resolves the confidentiality and authentication gaps. Related CVEs: CVE-2002-0013 (community-string guessing), CVE-2017-6736/CVE-2017-6742 (Cisco IOS SNMP RCE, actively exploited), CVE-2025-20352 (Cisco IOS/NX-OS, disclosed Oct 2025). Best practice: restrict to trusted NMS hosts via firewall, upgrade to SNMPv3, disable SNMP on edge-facing interfaces.
- // analyst note
- An internet-facing port 162 is unusual in legitimate deployments; restrict to trusted NMS hosts, upgrade to SNMPv3, and treat public exposure as worth investigating.
About port 162/tcp.
Port 162/tcp is registered with IANA as snmptrap with the description "SNMPTRAP," assignee and contact both [Marshall_Rose], and a blank reference field (dual-registered on TCP and UDP). The service is the notification-receiver side of SNMP: managed devices — routers, switches, servers, UPS units, IoT endpoints — send asynchronous, unsolicited Traps (one-way) and Informs (acknowledged, added in SNMPv2c/v3) to a central manager or NMS when significant events occur, such as a link going up or down, a hardware fault, high CPU, or a crossed threshold. In practice UDP overwhelmingly dominates this port; TCP on port 162 is defined only by RFC 3430 (Experimental, December 2002), which maps SNMP onto TCP for large-data or flow-controlled scenarios, and it is rarely deployed. The core SNMP standards (RFC 1157 for v1, RFC 3411–3418 for v3) specify port 162 for traps but name UDP as the primary transport. The IANA registry lists no separate RFC reference for this entry, so none is fabricated here. Security concerns are largely an SNMPv1/v2c problem: trap messages under those versions travel in cleartext and can leak device state, topology, and community strings to passive interception, and the public/private community strings provide no real authentication. SNMP is also a known DDoS reflection vector, though amplification typically abuses the query port 161 rather than the 162 trap port. SNMPv3 in AuthPriv mode resolves the confidentiality and authentication gaps. For an analyst, an internet-facing port 162 listener is unusual in legitimate deployments and warrants investigation; best practice is to restrict it to trusted NMS hosts via firewall, move to SNMPv3, and disable SNMP on edge-facing interfaces.
- IANA assignment
snmptrap— "SNMPTRAP"; reference (blank — no RFC cited in IANA registry); assignee and contact both [Marshall_Rose]; dual-registered 162/tcp + 162/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry lines 401–402)- Range class
- well-known (0–1023) [Confirmed]
- Related ports
- 161 (SNMP query/poll port); 161 is the higher-exposure SNMP surface
Primary use
receiver for SNMP Trap and Inform notifications — asynchronous, unsolicited event alerts sent by managed devices to a central SNMP manager/NMS; UDP is the dominant transport
Common software
net-snmp snmptrapd, Nagios, SolarWinds NPM, PRTG, Zabbix, OpenNMS, WhatsUp Gold, HP OpenView/Micro Focus, CiscoWorks; devices from Cisco, Juniper, HP send traps to these collectors
Security implications
SNMPv1/v2c trap messages are cleartext (leak device state, topology, community strings); public/private community strings give no real authentication; SNMP is a known DDoS reflection vector (amplification abuses 161, not 162); SNMPv3 AuthPriv resolves the confidentiality/auth gaps. Related CVEs: CVE-2002-0013 (community-string guessing), CVE-2017-6736 / CVE-2017-6742 (Cisco IOS SNMP RCE, actively exploited), CVE-2025-20352 (Cisco IOS/NX-OS, disclosed Oct 2025)
Typically seen on
NMS/monitoring collector hosts on internal networks; an internet-facing 162 listener is anomalous
- TCP transport status
- defined only by RFC 3430 (Experimental, December 2002); rarely deployed in practice — UDP is overwhelmingly used for traps [Confirmed] — https://www.rfc-editor.org/rfc/rfc3430.html
- Relevant RFCs
- RFC 3430 (SNMP over TCP, Experimental); core SNMP specs RFC 1157 (v1) and RFC 3411–3418 (v3) specify port 162 for traps over UDP [Confirmed] — https://datatracker.ietf.org/doc/rfc3430/
- Scanning/exposure
- TCP/162 sees far less opportunistic scanning than UDP/161 because SNMP-over-TCP is an Experimental, rarely-implemented extension; Shadowserver's open-SNMP methodology probes 161, not 162. Any internet-facing 162 listener is unusual and worth investigating[Likely] — https://www.shadowserver.org/what-we-do/network-reporting/open-snmp-report/
- Analyst note
- An internet-facing port 162 is unusual in legitimate deployments; restrict to trusted NMS hosts, upgrade to SNMPv3, and treat public exposure as worth investigating.
About port 162/udp.
Port 162/udp is the destination port on which an SNMP manager — a network management station, monitoring collector, or SIEM trap receiver — listens for asynchronous notifications pushed by agents. Where port 161 is about the manager polling agents, port 162 reverses the direction: it carries device-initiated traps (fire-and-forget) and informs (acknowledged) that agents send when events occur, such as link-state changes, threshold breaches, hardware faults, or reboots. The same SNMP version and security model applies as elsewhere — SNMPv1/v2c traps travel with cleartext community strings (the trap community string is typically distinct from the read/read-write strings), while SNMPv3 adds the User-based Security Model for trap integrity and confidentiality. The IANA registry lists snmptrap attributed to Marshall Rose (a key SNMP/MIB author) with a blank Reference field; the SNMP standards lineage (RFC 1157 through the SNMPv3 set, STD 62) is the governing spec but is not the IANA-cited reference. Security-wise, cleartext v1/v2c traps can be sniffed, and because UDP source addresses are trivially spoofable, forged or malicious traps can inject misleading events into monitoring systems — so SNMPv3 authPriv is recommended where trap integrity matters. For an analyst, an open 162/udp typically indicates a network management station or monitoring collector rather than a managed endpoint; confirm the listener is intentional and that v1/v2c trap reception from untrusted sources is restricted.
- IANA assignment
snmptrap— "SNMPTRAP"; reference (blank — no RFC cited in IANA registry); assignee/contact Marshall Rose; governing protocol the SNMP RFC set (RFC 1157 → RFC 3411–3418, not the IANA-cited reference) [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- present on management/monitoring stations rather than endpoints; precise nmap-services open-frequency not published comparably to TCP [Well-established] — nmap-services file
- Related ports
- 161 (SNMP query); 10162 (SNMP trap over TLS/DTLS); 514 syslog as a monitoring/alerting sibling
Primary use
reception of asynchronous SNMP TRAP and INFORM notifications at a manager/NMS
Other/unofficial uses
none notable beyond SNMP notifications [n/a]
Security implications
v1/v2c traps carry cleartext community strings (sniffable); spoofed/malicious traps can inject misleading events (UDP source spoofing); SNMPv3 authPriv recommended for trap integrity/confidentiality
Typically seen on
NMS/monitoring collectors, SIEM trap receivers, network operations platforms
- Analyst note
- Open 162/udp usually indicates a network management station or monitoring collector, not a managed endpoint. Confirm it is intentional and that v1/v2c trap reception from untrusted sources is restricted.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| snmptrap | UDP | snmp-trap | 10.33% |
| snmptrap | TCP | snmp-trap | 0.00% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.