1
Summary
- // if you see it open
- Near-unique SGI IRIX fingerprint — IRIX shipped tcpmux enabled by default, and a 'HELP' request returns the host's service listing (reconnaissance). The same SGI default-on-inetd posture produced the fam (File Alteration Monitor) exposure, CVE-1999-0059 (remote enumeration of all files without an account; SGI advisory 20000301-01-I, March 2000; fixed in IRIX 6.5.8) — fam is technically a distinct RPC service. tcpmux is essentially never legitimately open today.
- // analyst note
- An open port 1 is statistically rare and historically an IRIX signature — treat as a fingerprinting signal and investigate; legitimate use is unlikely.
About port 1/tcp.
Port 1/tcp is registered with IANA as tcpmux with the description "TCP Port Service Multiplexer," assignee Mark Lottor, and a blank reference field (dual-registered on TCP and UDP). The protocol is defined in RFC 1078 (M. Lottor, SRI-NIC, November 1988; later obsoleted by RFC 7805): a client connects to TCP port 1, sends a service name followed by CRLF, and the server replies with "+" (positive) or "-" (negative) before handing the connection off to the named service; the reserved name "HELP" returns a list of supported service names. The idea was to let services be reached by name on a single port rather than each needing its own well-known number, but it was rarely deployed — it exists in the BSD inetd lineage (FreeBSD/NetBSD/DragonFlyBSD) and is absent from OpenBSD. The IANA reference field is blank. The reason port 1 matters for an analyst is almost entirely as a fingerprint: SGI's IRIX was essentially the only mainstream OS that shipped tcpmux enabled and populated by default, so a responsive port 1 (especially one answering a "HELP" request with a service listing) was a near-unique IRIX signature and a reconnaissance aid. The same SGI default-on-inetd posture produced the better-known fam (File Alteration Monitor) exposure, CVE-1999-0059, where the IRIX fam service let a remote attacker enumerate every file on the server without an account (SGI Security Advisory 20000301-01-I, March 2000; fixed in IRIX 6.5.8) — fam is technically an RPC service distinct from the literal port-1 listener, but both stem from the same insecure defaults. tcpmux is essentially never legitimately open today, so for an analyst a responsive port 1 is statistically rare and worth investigating as an IRIX signature, a decoy, or a possible backdoor rather than a normal service.
- IANA assignment
tcpmux— "TCP Port Service Multiplexer"; reference (blank — no RFC cited in IANA registry); assignee Mark Lottor; dual-registered 1/tcp + 1/udp [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- nmap-services open-frequency 1/tcp ≈ 0.001995 (~0.2%); 1/udp ≈ 0.001236 (de-facto) [Well-established] — nmap-services file
- Related ports
- the small-services cluster (7, 9, 11, 13, 17, 19, 37); contrast modern service discovery
Primary use
name-based TCP service multiplexer (RFC 1078; rarely deployed)
Other/unofficial uses
historical SGI IRIX default service; reference implementations in BSD inetd [Well-established]
Security implications
near-unique IRIX fingerprint (HELP returns a service listing → recon); SGI default-on-inetd era also produced the fam exposure CVE-1999-0059 (remote file enumeration; fam is a distinct RPC service); essentially never legitimately open today
Typically seen on
legacy SGI IRIX hosts; otherwise an anomaly / possible backdoor or decoy
- Analyst note
- An open port 1 is statistically rare and historically an IRIX signature — treat as a fingerprinting signal and investigate; legitimate use is unlikely.
About port 1/udp.
Port 1/udp is registered with IANA as tcpmux with the description "TCP Port Service Multiplexer," assignee Mark Lottor, and a blank reference field. The assignment is dual-registered: port 1 carries the same service name, description, assignee, and contact on both TCP and UDP, and both rows leave the IANA Reference column blank. The important caveat for an analyst is that the UDP half of this assignment is effectively a paper reservation with no protocol behind it. tcpmux is defined only in RFC 1078 (M. Lottor, SRI-NIC, November 1988), and that specification is TCP-only: a client opens a TCP connection to port 1, sends a service name followed by CRLF, and the server replies with "+" (accepted) or "-" (rejected) before handing the connection off to the named service, with the reserved name "HELP" returning a list of supported services. RFC 1078 makes no provision for UDP operation, so there is no handshake, no datagram format, and no defined response for 1/udp — the listing exists to keep the number reserved alongside its TCP twin rather than to describe a working datagram service. RFC 1078 itself was reclassified to Historic by RFC 7805 (April 2016) "for technical reasons and lack of use in the Internet," and there is no successor protocol for port 1 on either transport. For reconnaissance purposes the UDP entry is low-value: with no defined response, a probe to 1/udp on a closed host typically draws an ICMP port-unreachable and on a filtered or non-listening host is simply dropped, so it yields little fingerprinting signal of its own. No mainstream software is known to use port 1/udp in production, and reviewed public sources surfaced no notable CVEs or documented internet-scanning campaigns aimed specifically at 1/udp; the service-enumeration concern associated with tcpmux (the unauthenticated HELP command) applies to the TCP variant only. The same SGI IRIX default-on-inetd lineage that made TCP port 1 a near-unique IRIX fingerprint is a TCP-side story; the UDP registration carries none of that behaviour. For an analyst, a response on 1/udp is therefore best treated as an anomaly worth investigating rather than a recognised service.
- IANA assignment
tcpmux— "TCP Port Service Multiplexer"; reference (blank — no RFC cited in IANA registry); assignee Mark Lottor; dual-registered 1/tcp + 1/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry)- Range class
- well-known (0–1023) [Confirmed]
- Prevalence
- 1/udp de-facto open-frequency ≈ 0.001236 in the nmap-services dataset (carried alongside the 1/tcp entry); negligible real traffic [Likely] — nmap-services file
- Related ports
- 1/tcp (the active half of the dual registration); the small-services cluster (7, 9, 11, 13, 17, 19, 37)
Primary use
name reservation only — the tcpmux protocol (RFC 1078) is TCP-only and defines no UDP behaviour; 1/udp is a parallel reservation with no datagram format or defined response
Other/unofficial uses
none known on UDP; no mainstream software uses port 1/udp in production
Security implications
low-value reconnaissance target on UDP — no defined handshake or response means probes draw ICMP port-unreachable on closed hosts or are silently dropped; the unauthenticated service-enumeration concern (HELP command) and the SGI IRIX fingerprint apply to 1/tcp, not 1/udp; no notable CVEs or active scanning campaigns targeting 1/udp were found in reviewed sources
Typically seen on
nothing in routine production; an open/responsive 1/udp is an anomaly or possible decoy/backdoor
- Deprecation status
- RFC 1078, the sole normative spec for tcpmux, was moved to Historic by RFC 7805 (April 2016) for technical reasons and lack of use; no successor protocol exists for port 1; the UDP assignment has no corresponding RFC [Confirmed] — RFC 7805, RFC 1078
- Analyst note
- 1/udp is a name reservation, not a working service — treat any response as anomalous and investigate; legitimate use is unlikely. Registration/modification dates and an IANA RFC reference are blank in the registry and are recorded as Unknown rather than guessed.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| tcpmux | TCP | TCP Port Service Multiplexer | 0.20% |
| tcpmux | UDP | TCP Port Service Multiplexer | 0.12% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.