Telnet Exposure (Port 23): An Unencrypted Protocol That Should Not Exist on Your Network

What is Telnet and why is it still around?

Telnet is a protocol from 1969 that provides remote command-line access to a device over TCP port 23. It was the standard way to remotely manage servers, routers, switches, and other network equipment for decades.

The problem: Telnet transmits everything in plain text. Every keystroke, every password, every command, and every response travels across the network unencrypted. Anyone on the same network segment -- or anywhere along the path -- can capture the entire session with a packet sniffer.

SSH replaced Telnet in the late 1990s with strong encryption. There has been no valid reason to use Telnet for remote management for over 25 years. Yet it persists -- on legacy network equipment, industrial control systems, IoT devices, and forgotten servers.

Why Telnet exposure is critical

Plaintext credential capture

When an administrator logs into a device via Telnet, their username and password are visible to anyone capturing network traffic:

# What a packet capture of a Telnet session looks like:
Username: admin
Password: MyS3cretP@ss!
router> enable
Password: EnableP@ss123
router#

These credentials are often reused across devices. One captured Telnet session can compromise your entire network.

No integrity protection

Telnet provides no way to verify that data has not been modified in transit. A man-in-the-middle attacker can inject commands into the session without either party knowing.

No server authentication

Telnet does not verify the identity of the server. An attacker can redirect traffic to a fake server (via ARP spoofing, DNS hijacking, or routing manipulation) and capture credentials.

Automated exploitation

Botnets like Mirai specifically scan the internet for Telnet on port 23, try default credentials, and automatically compromise vulnerable devices. This is how massive IoT botnets are built -- primarily through exposed Telnet with default passwords.

How to check for Telnet exposure

Using nmap

# Check if Telnet is open on a specific host
nmap -p 23 your-public-ip

# Scan a range for Telnet
nmap -p 23 --open your-ip-range/24

# Get banner information
nmap -p 23 --script telnet-ntlm-info your-public-ip

Using Shodan

Search Shodan for Telnet on your network:

port:23 net:your-ip-range/24

From the device itself

# Linux: check if a Telnet server is running
sudo ss -tlnp | grep :23
sudo systemctl status telnet.socket   # systemd
sudo systemctl status inetd           # older systems

How to eliminate Telnet

Step 1: Identify all Telnet-enabled devices

Scan your entire network (internal and external) for port 23:

nmap -p 23 --open 10.0.0.0/8 -oG telnet-scan.txt
grep "23/open" telnet-scan.txt

Step 2: Replace Telnet with SSH

For every device that supports SSH, disable Telnet and enable SSH:

Linux servers

# Disable Telnet
sudo systemctl stop telnet.socket
sudo systemctl disable telnet.socket

# Remove the Telnet server package entirely
sudo apt remove telnetd    # Debian/Ubuntu
sudo yum remove telnet-server   # RHEL/CentOS

# Ensure SSH is running
sudo systemctl enable sshd
sudo systemctl start sshd

Cisco IOS

! Disable Telnet on VTY lines
line vty 0 15
  transport input ssh
  no transport input telnet

! Ensure SSH is configured
ip ssh version 2
crypto key generate rsa modulus 2048

Juniper Junos

set system services ssh
delete system services telnet

HP/Aruba switches

no telnet-server
ip ssh

Step 3: Handle devices that only support Telnet

Some legacy equipment (older industrial controllers, embedded systems, very old network gear) may not support SSH. Options:

• Replace the device -- if it is old enough to lack SSH support, it likely has other vulnerabilities too
• Use a jump host -- place a hardened SSH bastion host in front of the Telnet device, and only allow Telnet from the bastion to the device on an isolated network segment
• Use a serial console server -- for network equipment, use out-of-band management via serial console instead of Telnet
• Network isolation -- if the device must remain, put it on a completely isolated network segment with strict firewall rules

Step 4: Block Telnet at the firewall

Even after disabling Telnet on individual devices, block port 23 at your network perimeter as a safety net:

# UFW
sudo ufw deny 23/tcp

# iptables
sudo iptables -A INPUT -p tcp --dport 23 -j DROP
sudo iptables -A FORWARD -p tcp --dport 23 -j DROP

In cloud environments, ensure no security group allows inbound TCP 23.

Step 5: Remove the Telnet client

The Telnet client is often installed by default, even when no Telnet server is running. Removing the client prevents accidental use:

# Debian/Ubuntu
sudo apt remove telnet

# RHEL/CentOS
sudo yum remove telnet

# macOS (telnet was removed in recent versions but may be installed via brew)
brew uninstall telnet

Telnet alternatives for debugging

Network engineers sometimes use the Telnet client to test connectivity to a port (e.g., telnet mail-server 25). Safer alternatives:

# Using nc (netcat) -- does not install a Telnet daemon
nc -zv mail-server 25

# Using curl
curl -v telnet://mail-server:25

# Using openssl (for TLS-enabled services)
openssl s_client -connect mail-server:465

These test connectivity without installing or enabling the Telnet protocol.

Verify the fix

After eliminating Telnet:

# External scan -- should show closed or filtered
nmap -p 23 your-public-ip

# Internal scan -- should also show closed
nmap -p 23 --open 10.0.0.0/8

# Check Shodan -- Telnet should not appear
# https://www.shodan.io/search?query=port%3A23+net%3Ayour-ip-range

For comprehensive guidance on securing remote access, see our SSH hardening guide. For a broader view of exposed services, see open ports security.

How SurfaceScan helps

SurfaceScan scans for Telnet on port 23 (and non-standard Telnet ports) across your entire external attack surface. Any Telnet service accessible from the internet is flagged as critical severity because plaintext credential exposure is an immediate and exploitable risk. Findings include the device banner information (which often reveals the device type and firmware version) and remediation guidance for replacing Telnet with SSH or isolating the device.