TCP Port 162 – SNMP Trap (Asynchronous Notifications)
Port 162 is the standard receiver port for SNMP traps, the asynchronous notification messages that managed network devices send to a designated SNMP manager. SNMP itself, the Simple Network Management Protocol used to query device status, runs on UDP/161. Port 162 carries the reverse traffic: when a device has something unsolicited to report, such as a fan failure on a switch, a power event on a UPS, or a link-down on a router, it sends a trap message to a manager listening on UDP/162.
SNMP was first specified in RFC 1157 in 1988, with version 2 (RFC 1901, 1996) and version 3 (RFC 3411, 2002) following. SNMPv3 added authentication and encryption; earlier versions sent the protocol’s “community string” credential in plaintext on the wire. Despite the security improvements in v3, SNMPv1 and SNMPv2c remain widely deployed in environments where backwards compatibility with older devices matters more than confidentiality.
The architectural pattern is that managed devices (switches, routers, servers, environmental sensors, UPS units) send trap messages to an SNMP manager. The manager is typically a centralized network monitoring system: a dedicated appliance, a cloud service, or a software platform like Nagios, Zabbix, SolarWinds, or PRTG. Inbound UDP/162 to such a manager is normal and continuous. Inbound UDP/162 to any other host is unusual.
TCP/162 is also defined in the IANA registry and sees limited use in environments that prefer reliable trap delivery, but UDP/162 is the dominant transport. SNMP traps are designed as fire-and-forget notifications: the device sends the trap and does not wait for acknowledgment, which fits UDP’s connectionless model and avoids tying up resources on the sending device during fault conditions.
About TCP Port 162
Port 162 is registered with the Internet Assigned Numbers Authority (IANA) for snmptrap. The IANA description reads: ‘SNMPTRAP’.
Security Considerations
Our data shows 6 IDS rules referencing port 162, split across UDP (5 rules) and TCP (1 rule). The rules cover two related threat categories, both rooted in the SNMP protocol parser history of the late 1990s and early 2000s.
The first category is buffer overflow attacks against SNMP implementations. Sample rules detect community-string buffer overflow attempts and an evasion-aware variant of the same attack. These rules trace back to the era when SNMP parsers in many vendor products had exploitable bugs in their handling of malformed community strings or oversized fields in trap messages.
The second category is the PROTOS test suite, a set of crafted SNMP messages developed by the Oulu University Secure Programming Group and released in February 2002. PROTOS systematically exercised edge cases in vendor SNMP implementations and uncovered serious vulnerabilities across products from Cisco, Microsoft, HP, 3Com, and many others. The disclosure prompted a coordinated vendor-advisory cycle and remains one of the larger single-day security events in network management software history. Sample rule sid=1427 in our dataset detects PROTOS test-suite trap traffic.
The reconnaissance-classified rules (broadcast trap detection, trap protocol identification on UDP and TCP) reflect the older practice of using SNMP traps to map a network: an attacker sending broadcast traps could identify SNMP-listening hosts by their responses or follow-up behavior.
The defining ongoing concern with SNMP, including traps, is the credential model in pre-v3 versions. SNMPv1 and SNMPv2c send the community string in cleartext; anyone who can observe network traffic can read it. SNMPv3 introduced proper authentication and encryption (the auth+priv security level), but adoption is uneven, and mixed v1/v2c/v3 environments are common.
Defensive practice for SNMP is well established. SNMPv3 with auth+priv should be preferred for any new deployment. SNMP traffic, both queries (port 161) and traps (port 162), should be restricted to dedicated management VLANs and explicitly firewalled away from user and guest networks. Inbound UDP/162 to any host that is not a designated SNMP manager is unusual and worth investigating.
IDS Rule References
1 IDS / security rule reference TCP port 162. Presence in IDS rules does not mean traffic on this port is malicious. These are patterns security tools monitor.
Rule categories (top 1): attempted-recon (1).
Sample rule descriptions for TCP port 162:
- PROTOCOL-SNMP trap tcp
Data Sources
This information is compiled from: IANA Service Name and Transport Protocol Port Number Registry and Snort Community Rules (GPLv2).