30

Port 30/tcp carries no IANA service assignment. In the IANA Service Name and Transport Protocol Port Number Registry it is recorded as "Unassigned" on both TCP and UDP (rows ,30,tcp,Unassigned,... and ,30,udp,Unassigned,...), with no service name, no assignee, no dates, and a blank Reference column — meaning no RFC governs it. It was already listed without an assignment in RFC 1700 (the October 1994 "Assigned Numbers" snapshot), so the slot has sat empty for the whole modern era of the registry. Wikipedia's list of TCP and UDP port numbers skips it entirely, jumping from port 29 to port 31. Because there is no standard service here, port 30 is mostly interesting by its absence: an analyst who finds a host listening on 30/tcp is looking at something non-standard rather than a recognized protocol. No malware or trojan association is confirmed for this port: there is no CVE, SANS advisory, or 2025–2026 mass-scan exposure study (Shodan/Censys-class) that calls out port 30 as a notable attack surface, and it does not appear on Gary Kessler's bad-ports list (which begins at 31 in that range). For an analyst the practical read is simple: a responsive port 30/tcp is anomalous, has no legitimate well-known service behind it, and is worth investigating as a custom service, a decoy, or a possible backdoor rather than treated as expected traffic.

IANA assignment

Unassigned — no service name, no assignee, blank Reference (no RFC cited); dual-status 30/tcp + 30/udp both "Unassigned" [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry; the IANA Service Name and Transport Protocol Port Number Registry lines 67–68

Range class

well-known (0–1023)

Prevalence

not flagged as a high-exposure or high-risk port in 2025–2026 internet-exposure research; absent from Wikipedia's port list and Gary Kessler's bad-ports list [Likely] — garykessler.net bad-ports list; EU internet-exposure research 2026

Related ports

contrast the assigned neighbors (port 7 echo, port 9 discard, port 13 daytime); the surrounding 28–31 range is largely unassigned

Primary use

none — no assigned protocol or standard application; already unassigned in RFC 1700 (Oct 1994)

Other/unofficial uses

no legitimate software claims port 30 by convention [Likely]

Security implications

no CVE, SANS advisory, or current threat-intel singling out 30/tcp as an active vector (as of June 2026), and no confirmed malware/trojan association; any open listener should be treated as suspicious given no assigned service

Typically seen on

nothing standard — an open port 30 is an anomaly / possible custom service, decoy, or backdoor

Analyst note

A responsive port 30/tcp has no legitimate well-known service behind it — treat it as anomalous and investigate; do not assume a recognized protocol.

Port 30/udp carries no IANA service assignment: in the IANA Service Name and Transport Protocol Port Number Registry it is listed simply as Unassigned, with no service name, no assignee, no registration or modification date, and a blank reference column. The companion entry 30/tcp is identically Unassigned, so neither transport at port 30 has ever been claimed. The number sits in a small island between two early ARPANET MSG-protocol assignments — 29 is msg-icp (MSG ICP) and 31 is msg-auth (MSG Authentication), both assigned to Robert Thomas — which suggests port 30 was simply skipped when that cluster of message-protocol numbers was handed out rather than reserved for any specific purpose. Because the value falls in the well-known (system) range 0–1023, it occasionally appears in broad UDP port sweeps and firewall audits even though nothing legitimate listens there. No common software, no standardized protocol, and no widely documented malware or trojan is associated with UDP/30. No port-30-specific CVE or campaign was found in publicly available sources during this research pass, and no Shodan data specific to UDP/30 was located. For an analyst, UDP traffic to or from port 30 is therefore anomalous by default: there is no benign service to attribute it to, so it is worth investigating as misconfiguration, a scan artifact, or covert use rather than dismissing as normal. The blank IANA reference is recorded honestly here — no RFC is cited in the registry and none is invented.

IANA assignment

Unassigned — no service name, no assignee, blank reference; 30/udp and 30/tcp both Unassigned [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry line 68; 30/tcp line 67)

Range class

well-known (0–1023) [Confirmed]

Service name

none — registry name column blank [Confirmed] — IANA registry (the IANA Service Name and Transport Protocol Port Number Registry line 68)

Registration/modification date

none recorded (no date in the registry; not invented) [Confirmed] — IANA registry (the IANA Service Name and Transport Protocol Port Number Registry line 68)

IANA reference

blank (no RFC cited in the registry; stays blank) [Confirmed] — IANA registry (the IANA Service Name and Transport Protocol Port Number Registry line 68)

Primary use

none — no standardized protocol or service is assigned to UDP/30

Common software / malware

none specifically documented for UDP/30

Security implications

no legitimate service listens on UDP/30, so traffic is anomalous; the port can surface in broad UDP sweeps and firewall audits because it lies in the well-known range; no port-30-specific exploit or CVE located

Assignee

none recorded [Confirmed] — IANA registry (the IANA Service Name and Transport Protocol Port Number Registry line 68)

Neighboring ports

29 msg-icp (MSG ICP) and 31 msg-auth (MSG Authentication), both early ARPANET MSG-protocol assignments to Robert Thomas; port 30 was skipped in that cluster [Confirmed] — IANA registry (lines 65–66, 69–70)

Analyst note

treat UDP/30 traffic as a signal worth scrutiny — misconfiguration, scan artifact, or covert use — not a known service.