Getting Started with Port 23
Port 23 is one of the most common and important TCP/UDP ports used on the Internet and in computer networking. It is the standard port for the Telnet protocol, which provides bidirectional interactive text-oriented communication between two devices.
In this comprehensive guide, we will cover everything you need to know about port 23, including its history, purpose, applications, security implications, and best practices for configuration and management.
Key Takeaways
- Port 23 is the IANA-assigned port number for the Telnet protocol, which allows remote login over a TCP/IP network.
- It was widely used in the early days of the Internet Internet for command-line connectivity to remote systems. Still, due to security vulnerabilities, it has largely been replaced by SSH.
- While still used in some network devices and applications, port 23 is often blocked by firewalls due to its associated risks. Proper security measures should be taken if you enable it.
- Common applications using port 23 include network device administration, legacy systems management, and mainframe connectivity. Alternatives like SSH provide better encryption and authentication.
- Exposing Telnet/port 23 poses risks of traffic sniffing, brute force attacks, and unauthorized access. It should only be enabled where necessary, with proper access controls, logging, and monitoring applied.
- Best practices include using SSH instead of Telnet where possible, limiting access to specific source IPs, implementing two-factor authentication, and keeping software up-to-date to mitigate vulnerabilities.
What is Port 23?
Port 23 is a TCP and UDP port number reserved by the Internet Assigned Numbers Authority (IANA) for the Telnet protocol. The Telnet protocol establishes a text-based connection between two systems or devices, allowing command-line interface (CLI) communication remotely over a network.
When a system connects to another device’s port 23, it provides bidirectional interactive text-oriented communication with a remote host. This allows system administrators and users to remotely log in to other devices via the CLI, execute commands, and access resources as if they were physically present on the machine.
Telnet uses a client-server model to establish remote connectivity on port 23. The system initiating the connection runs Telnet client software and connects to the Telnet port on a remote server. This allows the client to interface with the server as if connected directly to the remote device’s console.
While no longer widely used due to security issues, Telnet played an important role in the early days of computer networking. It was one of the primary means of connecting to and administering remote systems and devices before more secure protocols like SSH became available.
A Brief History of Port 23 and Telnet
To understand the role and risks associated with port 23 today, it helps to look at the history of Telnet and how it has evolved:
- 1969: RFC 15, the first Telnet specification, is published describing the protocol for remote login over the early ARPANET (a precursor to the Internet).
- 1972: Telnet is integrated into the newly created TCP/IP protocol stack, becoming one of the first and core internet protocols.
- Late 1970s: As the Internet expanded, Telnet gained widespread adoption for connecting to and administering the growing number of networked systems and devices.
- Early 1980s: Security concerns over sending Telnet traffic in plaintext start to emerge. Alternative protocols like Rlogin and SSH are developed.
- 1990s: As internet use grows, Telnet begins to be replaced by more secure remote access protocols. However, it remains common for managing network devices.
- 2000s: SSH v2 is released, providing better encryption and authentication. Telnet use has started to decline due to security and reliability concerns.
- Today: Telnet still sees some limited use for legacy systems but has largely been supplanted by SSH. Port 23 is often blocked at network perimeters.
Why is Port 23 Insecure and Risky?
Several key factors make Telnet communication over port 23 particularly insecure and risky compared to alternatives like SSH:
- Plaintext Transmission: Telnet does not encrypt any data exchanged between client and server. This means usernames, passwords, and all commands and output are sent in plaintext, allowing easy sniffing and interception.
- No Authentication: The Telnet protocol itself does not provide any means to authenticate users. Connections rely on usernames and passwords being sent unencrypted and accepted at face value.
- Privileged Access: Telnet often allows elevated command-line control equivalent to logging in at the physical console. A compromise gives full access.
- Scripting Abilities: Automating Telnet through scripts can allow attackers to scan for vulnerable systems and spread malware or attacks easily.
- Vulnerable Software: Like all software, Telnet implementations have had their share of exploitable vulnerabilities over the years, which provides an additional attack surface.
What is Telnet Used for Today?
While Telnet has largely fallen out of favor as a remote access technology, it still retains some limited uses today in specific applications and environments:
- Network Devices: Telnet remains common as a configuration protocol for routers, switches, firewalls, and other networking gear. This allows device administration from anywhere.
- Mainframes and Supercomputers: Telnet protocols provide connectivity to high-performance computing systems with limited native SSH support.
- Legacy Systems: Older OSes or applications may lack SSH clients. Telnet provides basic management functions.
- Debugging and Testing: Telnet can be used to establish a basic TCP connection for protocol testing and debugging.
- Automation: Scripting systems may leverage Telnet for simple automated interactions with text-based interfaces.
Key Telnet Alternatives and Replacements
For most general computing and networking needs today, Telnet has been superseded by more secure protocols and technologies:
- SSH: Provides encrypted command line connectivity and strong authentication. The de facto standard for secure remote CLI access on Linux/Unix systems.
- Remote Desktop: Windows Remote Desktop and VNC allow remote GUI access with encryption over TCP port 3389 and 5900+, respectively.
- HTTP/HTTPS: Web-based configuration interfaces for many networking devices and servers instead of CLI.
- NETCONF: An emerging network management protocol with capabilities similar to Telnet but focused on automation.
- Console Servers: Hardware devices that allow proxy access to serial consoles over SSH or HTTPS.
Organizations looking to improve security are encouraged to phase out raw Telnet/port 23 usage in favor of these alternatives wherever feasible. However, some Telnet requirements may remain for certain legacy systems or specialty equipment.
Why Might You Need to Open or Allow Port 23?
Given the inherent risks, most organizations block Telnet access at the network perimeter by default and disable the port 23 service on endpoints. However, there are some situations where enabling port 23 may still be required:
- To administer older network devices that still rely on Telnet for management.
- To connect to legacy systems that have limited native SSH support or lack newer remote access clients.
- For debugging connectivity issues to rule out general TCP/IP problems versus application layer problems.
- To allow an external automation service to access a legacy system that requires scripted Telnet interactions.
- During temporary access windows where SSH or other alternatives are not feasible.
- For network scanning that requires raw TCP connectivity checks on different ports.
If Telnet or port 23 access is unavoidable, proper precautions need to be taken to avoid exposure, which we will cover next.
Telnet Security Best Practices
If retaining Telnet for legacy requirements, administrators should adhere to security best practices to avoid leaving port 23 open to exploitation:
- Implement IP-based access controls, only allowing Telnet from dedicated management IPs.
- Use firewall rules to restrict Telnet sources and destinations to specific internal hosts.
- Enable 2-factor authentication or multifactor authentication for Telnet sessions via TACACS+ or Radius if supported.
- Monitor logs and alert on Telnet failures that may indicate compromise attempts.
- Utilize IDS systems to detect abnormal Telnet traffic patterns and payloads.
- Enforce the least privilege on Telnet accessible accounts and limit knowledge of credentials.
- Consider implementing an application-layer firewall or proxy that can monitor Telnet sessions.
- Set inactive session timeouts and utilize access hours to limit exposure periods.
With proper precautions, the risks of retaining legacy Telnet access can be reduced. But phasing it out completely in favor of more secure alternatives is always preferable when possible.
Telnet Port Scanning Detection
One common concern surrounding any open port is that it provides an attack surface for port scans to detect vulnerable systems. Telnet scanners are quite common, so detection controls are recommended:
- Review Firewall and IDS Logs: Look for access attempts or traffic spikes focused on port 23, which may indicate scanning.
- Alert on Failed Login Thresholds: Monitor authentication failures on Telnet services to detect brute force attacks.
- Analyze NetFlow Data: Unusual spikes in inbound or outbound traffic on port 23 can indicate scanning activity or a compromise.
- Inspect Packet Payloads: Malformed Telnet handshakes or nonsense commands may signify port scanning rather than legitimate use.
- Use Traffic and Behavior Analysis. Compare overall patterns to the baseline to identify anomalies indicative of scans versus normal usage.
Port 23 Telnet Server Examples
A few examples of common programs that may provide Telnet access on port 23 include:
- Cisco IOS & Nexus: The CLI interface on Cisco routers and switches is accessible by default via Telnet and SSH.
- Windows: Versions of Windows Server up through 2008 R2 included a native Telnet Server function that provided remote CLI access.
- Linux & Unix: Most distributions have a Telnet daemon such as inetd or xinetd that can be enabled if desired.
- Mainframes: Platforms like IBM z/OS provide Telnet access to TSO, ISPF, and other subsystems to allow terminal emulation.
- Printers/Scanners: Networked multi-function printers and scanners often have a Telnet or raw TCP interface for configuration.
- Serial Devices: Console servers and terminal emulators enable Telnet access by proxying serial console connections.
Port 23 Telnet Client Examples
On the client side, a number of operating systems, utilities, and programs exist that allow initiating Telnet sessions to port 23:
- The Windows command line includes a built-in telnet.exe client that can connect to text-based TCP services.
- Linux and Unix distributions include command line Telnet clients like telnet or telnetd that function similarly.
- PuTTY, Kitty, and other terminal emulators typically include integrated Telnet client functionality alongside SSH.
- Programming languages like C, Python, Java, etc., have libraries that enable Telnet capabilities within custom applications.
- Some remote access tools like Radmin provide Telnet access by proxying and encapsulating the sessions over their protocols.
- Browser-based Telnet clients exist utilizing Javascript, Java applets, and other methods to provide direct connectivity.
Port 23 Telnet Client Alternatives
Instead of using raw Telnet clients, there are several alternatives worth considering:
- SSH Clients: Many support port forwarding that allows tunneling Telnet over an encrypted SSH session for security.
- Console Servers: Provide proxy access to Telnet systems while enabling logging, monitoring, and access control.
- Web Clients: Some equipment vendors provide web-based Telnet consoles accessed via HTTPS for better security.
- Protocol Converters: Specialty hardware and software can transparently proxy, convert, and encapsulate Telnet into more secure protocols.
- Automation/Scripting: Languages with Telnet libraries allow programmatically interacting with Telnet devices instead of manual connections.
- Emulation: Solutions exist that emulate Telnet devices, providing local Telnet access that proxies to remote systems with security enforced.
Port 23 Telnet Traffic Sniffing Concerns
One of the core security concerns surrounding Telnet is that all session traffic is sent in plaintext, which makes it prone to interception and sniffing of sensitive data. Some techniques to mitigate this include:
- Use SSH Port Forwarding: Tunnel Telnet through an encrypted SSH connection to prevent sniffing.
- Utilize VPN Access: Connect to Telnet systems through a virtual private network tunnel.
- Limit Access to Trusted Internal Networks: Avoid external Internet access to mitigate sniffing risks.
- Proxy Through a Console Server: Specialty hardware can provide access control, logging, and encryption.
- Consider Multichannel Security: Additional layers like IPsec can add encryption to otherwise plaintext Telnet.
- Mask Passwords: Send dummy characters along with passwords to obstruct sniffing on untrusted networks.
- Use One-time Passwords: Tokens or OTPs prevent password reuse even if sniffed.
While still not optimal, combinations of these controls can reduce Telnet’s inherent sniffing risks in situations where its use is unavoidable.
Port 23 Telnet MitM & Hijacking Concerns
Beyond sniffing, the lack of authentication and encryption with Telnet also makes it vulnerable to more active attacks like man-in-the-middle (MitM) hijacking:
- Enable Port Security: Binding Telnet access to specific MAC addresses can prevent address spoofing and MitM.
- Require Multifactor Authentication: Adding one-time password tokens prevents MitM login even if main credentials are intercepted.
- Consider IPsec: Adding encryption at the IP layer can prevent MitM attacks against Telnet sessions.
- Monitor for Connection Anomalies: Detect and alert on unexpected connection losses during Telnet sessions, which can indicate MitM.
- Proxy Through a Trusted Device: Manage Telnet through a console server or other MitM-resistant appliance.
- Shorten Sessions: Limiting Telnet use to quick transactions helps minimize MitM exposure windows.
- Disable if Unused: Shutting down Telnet/port 23 when not actively needed reduces attack surface.
Port 23 Telnet Routing and Segmentation
Network routing and segmentation best practices can also help reduce risks associated with open Telnet/Port 23 services:
- Place Telnet systems on a separate management VLAN with restricted access.
- Utilize firewall rules and ACLs to limit which source IPs can access Telnet servers.
- Disable routing and switch port access to the Telnet VLAN from untrusted zones.
- Consider using a different non-standard port other than 23 if feasible.
- Deploy application layer firewalls that can monitor and control Telnet sessions.
- Filter port 23 only to specific IP addresses that require Telnet for management.
- Block and alert any internet-routable IP addresses attempting to connect inbound to port 23.
With a well-planned network design, the potential attack surface of open Telnet ports can be significantly reduced. However, the ultimate goal should be to remove such insecure protocols.
What are the Risks of Exposing Telnet/Port 23 to the Internet
Exposing Telnet directly to the public Internet comes with considerable risks and is generally inadvisable:
- Accessible Telnet servers are prone to brute-force password-cracking attacks from anywhere.
- Internet-facing Telnet allows easy scanning for vulnerabilities across network boundaries.
- Unrestricted Telnet enables wide-open lateral movement across internal network segments.
- No encryption or authentication makes Telnet easy to intercept or subvert once accessible externally.
- Public Telnet poses regulatory and compliance risks for industries like healthcare and finance.
- Availability concerns as unrestricted Telnet could allow DoS attacks or resource overloading.
Secure Alternatives to Telnet Port 23
Here are some of the leading secure alternatives to consider replacing raw Telnet:
- SSH: Defacto standard for securely encrypting remote CLI sessions with strong authentication.
- HTTPS: Web-based configuration through browsers can replace CLI, secured with SSL/TLS.
- IPsec VPN: Encrypts layer 3 traffic between endpoints or networks, protecting Telnet and other protocols.
- OpenVPN: Provides encrypted virtual point-to-point or site-to-site tunnels for secure remote access.
- WireGuard: Emerging high-speed VPN protocol with cryptographic authentication between peers.
- Stunnel: Proxies and tunnels insecure protocols like Telnet securely via SSL encryption.
- RADIUS/TACACS+: Adds centralized authentication, authorization, and accounting to protocols like Telnet.
- Serial Console Servers: Hardware devices that provide secure consolidated access to serial console ports.
Final Thoughts
In summary, Telnet and port 23 served an important role in the early days of networking, providing remote access capabilities predating the Internet. However, given inherent plaintext transmission risks, its use has waned in favor of more secure protocols like SSH.
While still retained in some legacy systems, Telnet should be phased out when possible or accessed only via secure tunnels and proxies. When unavoidable, it requires tight access controls, robust logging, and network segmentation to manage risks.
With proper precautions, the legacy requirements of Telnet can be supported safely, but organizations should aim to utilize modern secure protocols by default for remote access.
FAQs About Telnet and Port 23
Is Telnet still used today?
Telnet continues to see limited use in some legacy applications and network devices, but due to its lack of encryption and authentication, it has largely been replaced by SSH for most remote access needs.
Is Telnet secure?
No, Telnet is considered highly insecure because it transmits all data, including passwords, in plaintext without encryption or authentication.
What are the alternatives to Telnet?
Common secure alternatives include SSH for encrypted command line access, HTTPS/TLS for web-based configuration, and protocols like RADIUS/TACACS+ for authentication control.
What is port 23 used for?
Port 23 is specifically designated for use by the Telnet protocol to provide bi-directional text-based terminal communications.
Is port 23 TCP or UDP?
Port 23 is defined for use with both TCP and UDP, but TCP is the most common transport protocol used for Telnet sessions.
Why is port 23 blocked?
Many organizations block port 23 at network boundaries by default due to the inherent insecurities with the Telnet protocol and the risks of leaving it exposed.
Is port 23 required for SSH?
No, SSH uses TCP port 22 by default, not port 23. SSH does not depend on Telnet or require port 23 to be open.
Can you VPN port 23?
Yes, running Telnet within a VPN or tunneling it within SSH can add a layer of encryption to otherwise insecure Telnet communications.
How do I enable Telnet in Windows?
Modern versions of Windows have Telnet disabled by default, but it can be enabled by installing the Telnet client feature and starting the Telnet service.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
![What is Certificate Revocation List [CRL]?](https://sslinsights.com/wp-content/uploads/2024/01/certificate-revocation-list-crl.png)
