Telnet - The Old-School Tool of Networking
Once upon a time, in the early days of networking, there was a mighty tool called Telnet. It allowed people to connect to computers remotely, type commands, and feel like wizards controlling machines from afar. It was simple, fast, and magical… but also dangerously naive.
In this tutorial, we’ll cover the practical use of Telnet, including connecting to servers, testing open ports, and troubleshooting.
Telnet is a protocol that works on the client-server model. The client sends commands to a remote server or device, which executes them and sends back the response. It operates over TCP and usually uses port 23 by default.
Key points:
Insecure: Data, including passwords, is sent in plaintext.
Useful for network testing and debugging.
Can connect to services like HTTP, SMTP, FTP, and custom TCP servers.
Connect to a server
The basic Telnet syntax is:
telnet <hostname or IP> <port>
Example: Connect to example.com on port 80 (HTTP)
If the connection is successful, you’ll see a blank screen. Now you can send raw HTTP requests, like:
telnet example.com 80
GET / HTTP/1.1
Host: example.com
Press Enter twice to send the request. The server’s response will appear in the terminal.
3.2 Test if a port is open
Telnet is commonly used to check whether a specific port is open on a server.
Example: Check if SMTP port 25 is open
telnet smtp.example.com 25
If connected: The server will respond with something like 220 smtp.example.com ESMTP Postfix.
If failed: You’ll see a connection error, meaning the port might be closed or blocked by a firewall.
3.3 Telnet for Network Troubleshooting
Check connectivity: If ping works but Telnet fails, the service may be down.
Verify service behavior: Connect to HTTP, FTP, or SMTP servers to manually test responses.
Debugging: Telnet helps see raw data sent by servers for debugging purposes.
- Telnet Commands
Once connected, you can use a few basic Telnet commands:
Command Description
open
Chapter 1: The Plaintext Curse
Telnet’s first flaw was obvious to anyone who looked closely: everything was sent in plaintext.
Imagine Alice, an admin, connecting to her server using Telnet. She types her password: superSecret123. Across the wires, this password isn’t hidden. It travels in plain letters, readable by anyone who’s listening.
Enter Trudy, the mischievous hacker. She sets up a packet sniffer on the network. Within moments, Trudy sees Alice’s password and can log in as her.
Lesson: Telnet never encrypted your secrets, making it trivial for eavesdroppers to steal credentials.
Chapter 2: The Man-in-the-Middle Trap
Telnet’s second vulnerability made it a perfect playground for Man-in-the-Middle (MITM) attacks.
Bob, a network admin, connects to his company’s server from a coffee shop. Unknown to him, Trudy is sitting on the same Wi-Fi, pretending to be the server. When Bob logs in, all his commands and passwords pass through Trudy first. She can change, read, or even block messages—without Bob ever knowing.
Telnet had no way to verify who you were talking to, making it incredibly easy to intercept sessions.
Chapter 3: Command Injection Chaos
Telnet was so flexible that you could literally type anything, anywhere. This became a double-edged sword. Some services that accepted Telnet connections didn’t properly validate input.
Malicious users discovered that sending special sequences could make the server crash, behave unexpectedly, or even give full control. Simple human error on the server side meant Telnet could become a doorway for attackers to run arbitrary commands.
Chapter 4: Weak Authentication Woes
Some early Telnet servers allowed blank passwords or default credentials.
It was like leaving your house keys under the welcome mat. Hackers could scan networks, try common usernames like admin or root, and log in without breaking a sweat.
Even worse, Telnet didn’t lock accounts after failed attempts, so attackers could brute-force passwords endlessly.
Chapter 5: Legacy Devices and Forgotten Servers
As time passed, Telnet stayed on legacy devices—routers, switches, industrial machines—that no one updated.
Attackers loved these forgotten Telnet servers because they often used default credentials or vulnerable software versions. A single Telnet port exposed to the internet could give a hacker full control of a network device.
