Port 23 carries Telnet traffic. Every time a terminal reaches across a network to become another machine's keyboard, that connection often flows through port 23. This is the original remote access protocol, the first application demonstrated on the ARPANET, the ancestor of SSH, and a ghost that still haunts critical infrastructure around the world.
What Telnet Does
Telnet provides bidirectional, interactive text communication between two computers. When you connect to a Telnet server, your keyboard becomes the keyboard of the remote machine. Every character you type travels across the network; every character the remote machine outputs travels back.
The protocol is elegantly simple: establish a TCP connection to port 23, and you have a virtual terminal. The remote system presents a login prompt. You type your username. You type your password. You're in.
There's just one thing: every character travels in plaintext. Your username. Your password. Every command you type. Every response you receive. All of it, readable by anyone who can see the network traffic between you and the server.
The Network Virtual Terminal
Telnet's key innovation was the Network Virtual Terminal (NVT), an abstraction that solved a fundamental problem: in 1969, there was no standardization.1 A DEC terminal was different from an IBM terminal was different from whatever strange machine you might be connecting from.
The NVT defined a canonical terminal that both ends of a Telnet connection could pretend to be. Your local Telnet client translates your actual terminal into NVT format. The remote Telnet server translates NVT into whatever its local system expects. Neither side needs to know anything about the other's actual hardware.
This was elegant. This was necessary. This is why Telnet worked across the chaotic hardware landscape of the early ARPANET.
The First Message
On October 29, 1969, at 10:30 PM, UCLA student Charley Kline sat at an SDS Sigma 7 computer in Boelter Hall. Four hundred miles away at Stanford Research Institute, Bill Duvall waited at an SDS 940.2
Kline began typing the command "login."
The system crashed after two characters.
The first message ever transmitted across the ARPANET was "lo."3
About an hour later, after Duvall adjusted some parameters, Kline tried again. This time, the full login succeeded. Remote access was born. The idea that you could sit at one computer and use another computer hundreds of miles away became reality.
This was Telnet. Not yet formalized, not yet standardized, but the concept that would become port 23. The first application. The first word.
The Long Road to Standardization
Telnet was developed collaboratively, emerging from the work of graduate students at UCLA and other ARPANET sites. Steve Crocker, who invented the RFC system itself, led teams that designed the early protocols.4 Jon Postel, who would later become the de facto administrator of the Internet's core infrastructure, was among those students.
RFC 97, "First Cut at a Proposed Telnet Protocol," appeared on February 15, 1971.5 But it would take twelve more years of refinement before the protocol was officially standardized.
RFC 854, published in May 1983 by Jon Postel and Joyce Reynolds, became the definitive Telnet specification. It codified the NVT concept, the option negotiation system, and the fundamental architecture that had evolved over fourteen years of use.6
Port 23 was assigned to Telnet as the official well-known port, placing it between FTP (port 21) and the not-yet-invented SSH (port 22).
The Security Problem
Telnet was designed for a different world. The ARPANET was a research network connecting trusted institutions. The idea of hostile actors intercepting traffic wasn't a primary concern.
Then the Internet happened.
Telnet transmits everything in plaintext. When you type your password, each character travels across the network as readable text. Anyone on the same network segment, anyone who can intercept traffic between you and the server, can read your credentials.7
This isn't a vulnerability. It's the design. Telnet predates the widespread understanding that encryption should be the default.
Man-in-the-middle attacks are trivial. Session hijacking is straightforward. Brute force attacks work well because there's no rate limiting, no encryption, and often no logging worth mentioning.
The Helsinki Moment
In 1995, Tatu Ylönen was a researcher at Helsinki University of Technology when he witnessed a password-sniffing attack on his university's network.8 Attackers were capturing plaintext passwords from Telnet and other protocols.
Ylönen's response was to build something better. He designed SSH, the Secure Shell, which provides everything Telnet does but encrypted. He chose port 22, conveniently sitting between FTP on 21 and Telnet on 23.9
On July 12, 1995, SSH 1.0.0 was released. By the end of that year, 20,000 users across fifty countries had adopted it.10
SSH didn't just replace Telnet's functionality. It replaced Telnet's position in the ecosystem. For any security-conscious operation, the transition was obvious. Same capability. Actual security.
The Ghost Protocol
But Telnet never died.
Many industrial and scientific devices only have Telnet available as a communication option.11 Legacy PLCs. Building control systems. That printer no one has updated since 2008. The router someone installed a decade ago and left running.
RF terminals, barcode scanners, and data collection devices still rely on Telnet because it's lightweight, fast, and reliable.12 The type of data being transferred is simple text and small graphics. Why add the overhead of encryption?
Telnet is still used in food and beverage plants, car manufacturing facilities, warehouses, school systems, government offices, airlines, oil companies, universities, medical practices, pharmaceutical operations, and grocery stores.13
If it's old, embedded, or labeled "critical infrastructure," there's a good chance it still allows Telnet.
The Mirai Catastrophe
In August 2016, security researchers discovered Mirai, a botnet that would demonstrate exactly how dangerous Telnet's persistence had become.14
Mirai scanned the Internet for devices with open Telnet ports and attempted to log in using a list of 62 common default usernames and passwords.15 The list was short. It didn't need to be long. Millions of IoT devices, cameras, routers, and DVRs shipped with default credentials and open Telnet ports.
On September 20, 2016, Mirai attacked security journalist Brian Krebs' website with a DDoS exceeding 620 gigabits per second.16
On October 21, 2016, Mirai hit Dyn, a major DNS provider. The attack peaked at 1.2 terabits per second. GitHub, Twitter, Reddit, Netflix, and Airbnb all became unreachable.17 At its peak, Mirai had enslaved over 600,000 IoT devices, most of them compromised through Telnet with default credentials.18
Telnet didn't cause Mirai. But Telnet enabled it. The protocol's lack of encryption, its simplicity, its ubiquity on devices that should never have been exposed to the Internet, made it the perfect vector.
MUDs and the Ghosts of Play
Not everything that flowed through port 23 was industrial. Not everything was serious.
In 1979, Roy Trubshaw at the University of Essex began writing the first MUD, a multi-user dungeon where players could explore, fight, and chat together in a shared text-based world.19 Richard Bartle joined him, and by 1980, MUD1 was running.
These games, accessible via Telnet, became the ancestors of modern MMORPGs. EverQuest, Ultima Online, World of Warcraft can all trace their lineage back to those early Telnet-accessible dungeons.20
Some MUDs are still running. StickMUD has been online since 1991, over thirty years of continuous operation, accessible via Telnet.21 There's something beautiful about that: a protocol from 1969 still carrying adventures written in 1991, still playable today.
How Telnet Works
A Telnet connection begins with a TCP handshake to port 23. Once established, the two sides negotiate options using a simple protocol: DO, DON'T, WILL, WON'T.22
"WILL you echo my characters back to me?" "DON'T echo my characters." "DO send your terminal type." "WON'T send my terminal type."
Through this negotiation, client and server agree on behaviors like local vs. remote echo, terminal type, window size, and other capabilities. Everything after negotiation is transparent data transfer, character by character.
Commands are introduced by the IAC (Interpret As Command) byte, decimal 255. When the remote side sees IAC, it knows the next bytes are control information, not user data.
It's simple. It's stateless. It's completely unencrypted.
Security Recommendations
If you're reading this because you found port 23 open on your network, here's what to do:
-
Disable it if possible. If you don't need Telnet, turn it off. Most systems don't need it.
-
Replace it with SSH. SSH provides the same functionality with actual security. Port 22 is waiting.
-
If you must use Telnet, restrict access through firewalls. Put it behind a VPN. Never expose it to the public Internet.
-
Change default credentials immediately. If a device has Telnet enabled with default username and password, it's already compromised or soon will be.
-
Monitor for attacks. Attackers scan for open Telnet ports constantly. They're looking for easy targets. Don't be one.
Related Ports
Port 23 sits in a neighborhood of related protocols:
- Port 21 (FTP Control): File Transfer Protocol's command channel, another plaintext protocol from the early ARPANET
- Port 22 (SSH): Telnet's secure successor, encrypting everything Telnet leaves exposed
- Port 513 (rlogin): Another remote login protocol, also insecure, also obsolete
- Port 2323: Common alternative Telnet port, often used to bypass firewall rules
Frequently Asked Questions
Was this page helpful?