83
Summary
- // if you see it open
- Low inherent risk from the IANA-assigned MIT ML Device service — it has no known live implementations to exploit. Moderate risk if a host actually runs an HTTP-like service on 83/tcp, since scanners actively probe it (SANS ISC documented a scanning uptick first written up June 2017; honeypot captures showed PSH/ACK probes, UDP HTTP-GET-like packets, UPnP discovery, and TeamSpeak UDP). Recommended posture: block inbound at the firewall unless a specific internal service requires it. Port is in the well-known/system range (0–1023), so binding needs elevated privileges on POSIX.
- // analyst note
- a responsive 83/tcp is almost always an alternate HTTP service, not the IANA-named MIT ML Device; inspect what is answering and treat it as a non-standard web port.
About port 83/tcp.
Port 83/tcp is registered with IANA as mit-ml-dev with the description "MIT ML Device," assignee David Reed, and a blank reference field; it is dual-registered, the identical assignment appearing on 83/udp. The name preserves a piece of early-internet history: the "MIT ML Device" referred to network access to a specific DEC KA10 machine at MIT named ML, which ran the Incompatible Timesharing System (ITS) and hosted the Macsyma computer-algebra system, operational roughly 1971–1984. The port was reserved for reaching that one machine and was never reclaimed after it was decommissioned, so for an analyst the IANA assignment is effectively a dead-letter — no modern protocol or service legitimately uses 83/tcp under that name. In practice, the port is occasionally bound by non-standard HTTP server configurations (Apache or PHP-based stacks using ports 81–83 as alternates to 80), which accounts for some observed traffic, but this is a local convention rather than a documented standard. The IANA Reference column is blank, and no RFC defines the registration. The reason 83/tcp matters operationally today is scanning noise: SANS ISC documented a gradual uptick in port-83 probing (first written up publicly in June 2017), with honeypot captures showing TCP PSH/ACK probes and teardown, UDP packets resembling HTTP GET requests, UPnP discovery traffic, and TeamSpeak-related UDP — the consensus read is opportunistic scanner sweeps looking for non-standard HTTP services, not exploitation of the long-dead MIT ML Device service. Because 83 falls in the well-known/system range (0–1023), binding a listener requires elevated privileges on POSIX systems. For an analyst, a responsive 83/tcp almost always means a host running an alternate HTTP service rather than anything tied to the IANA name; treat it as you would any non-standard web port and inspect what is actually answering.
- IANA assignment
mit-ml-dev— "MIT ML Device"; reference (blank — no RFC cited in IANA registry); assignee David Reed; dual-registered 83/tcp + 83/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry, rows 234–235)- Range class
- well-known / system (0–1023) — binding requires elevated privileges on POSIX [Confirmed] — IANA port ranges
- Registration date / modification date
- Unknown — blank in the IANA CSV; not recorded (null) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry
- Related ports
- alternate-HTTP cluster (81, 82, 8080, 8000); contrast standard HTTP on 80
Other/unofficial uses
occasional non-standard HTTP servers (Apache/PHP) binding 81–83 as alternates to port 80
Common software
no standard modern software claims 83/tcp; only ad-hoc alternate-HTTP configs
Exposure / scanning
SANS ISC documented a port-83 scanning uptick (first public writeup June 2017); honeypot captures showed TCP PSH/ACK probes + teardown, UDP HTTP-GET-like packets, UPnP discovery, and TeamSpeak UDP; live feed shows ongoing automated probing — consensus is opportunistic scanner sweeps, not exploitation of the IANA service
Security implications
low inherent risk from the dead IANA service (no known live implementations); moderate risk if a host actually runs an HTTP-like service on 83 since scanners actively probe it — block inbound unless a specific internal service needs it
- Primary historical use
- network access to the MIT ML machine, a DEC KA10 running ITS hosting Macsyma, ~1971–1984; never reclaimed after decommission [Likely] — https://www.connected.app/ports/83 (cites IANA registry)
- Analyst note
- a responsive 83/tcp is almost always an alternate HTTP service, not the IANA-named MIT ML Device; inspect what is answering and treat it as a non-standard web port.
About port 83/udp.
Port 83/udp is registered with IANA as mit-ml-dev with the description "MIT ML Device," contact David Reed, and a blank reference field — and it is dual-registered, with the identical service name and description appearing on both 83/tcp and 83/udp. The assignment is one of the oldest stubs in the registry: it was made to allow network communication with the MIT "ML" machine, a DEC KA10 running the Incompatible Timesharing System (ITS) that hosted Macsyma, one of the first computer algebra systems. The contact, David Reed, is the MIT computer scientist associated with the design of UDP itself, which fits the period (the ML machine operated from roughly 1971 to 1984 before being decommissioned). The port was never reclaimed, so the registration survives as a name without a living protocol specification — there is no RFC reference for it, and the IANA Reference column is blank. The neighboring port 85 carries the same "MIT ML Device" label under the same contact. For an analyst, port 83 matters mostly as a historical curiosity: no mainstream software claims it as a standard port by design. SANS ISC packet captures from 2017 surfaced heterogeneous, unrelated traffic on port 83 (HTTP-over-UDP fragments, UPnP-style searches, TeamSpeak-related packets) with no single authoritative application, and occasional Apache/PHP setups bound to the 81–83 range appear as misconfiguration rather than a defined use. As of June 2026 the SANS ISC threat level for port 83 is green, with scanning activity at routine internet-background levels and no CVEs or known trojans specifically tied to 83/udp. Because the port carries no active service by design, any open 83/udp listener is anomalous and worth investigating as a misconfiguration, a non-standard binding, or opportunistic activity rather than a normal service.
- IANA assignment
mit-ml-dev— "MIT ML Device"; reference (blank — no RFC cited in IANA registry); contact David Reed; dual-registered 83/tcp + 83/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry; the IANA Service Name and Transport Protocol Port Number Registry line 235 (udp), line 234 (tcp)- Range class
- well-known (0–1023) [Confirmed]
- Prevalence
- nmap-services observed open-frequency 83/udp ≈ 0.001203 — very low (roughly 1 in 1,000 sampled hosts), 304th of 5,615 UDP entries; the TCP sibling 83/tcp is ≈ 0.000539. Consistent with the mixed, unattributable traffic SANS ISC captured in 2017 rather than with any single service[Likely] — nmap-services dataset
- Related ports
- 83/tcp (same registration); 85/udp + 85/tcp (same "MIT ML Device" label, same contact)
Primary use
legacy stub for the MIT ML machine (a DEC KA10 running ITS hosting Macsyma); no living protocol specification [Likely] — https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=83 , https://isc.sans.edu/forums/diary/What+is+going+on+with+Port+83/22524/
Other/unofficial uses
no mainstream software claims 83/udp by design; occasional Apache/PHP on the 81–83 range is misconfiguration; 2017 SANS captures showed mixed unrelated traffic
Security implications
low baseline risk — the original service is long defunct; SANS ISC threat level green as of June 2026; scanning at routine background levels; no CVEs or trojans specifically tied to 83/udp; any open listener is anomalous
Typically seen on
anomalies / misconfigured services / opportunistic bindings; no legitimate modern host class
- Analyst note
- An open 83/udp listener is anomalous — the IANA name is a defunct legacy stub with no modern software using it by design; investigate as misconfiguration, non-standard binding, or opportunistic activity.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| mit-ml-dev | UDP | MIT ML Device | 0.12% |
| mit-ml-dev | TCP | MIT ML Device | 0.05% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.