Telnet isn't the problem
I have been receiving a lot of feedback regarding my comments on the Windows telnet client from my article on Server 2012:
As a note for anyone at Microsoft reading this: not including **telnet** in the default installation is an egregious offense.
Between Twitter replies, emails, and comments here and on Hacker News, there are a lot of people who agree with Microsoft’s decision to leave telnet out of the default Windows installation in recent versions. I vigorously disagree with this notion, although I haven’t yet provided any facts to defend that opinion. I plan to rectify that today.
1 - Everyone else does it
Including telnet by default is not that great of a request. In fact, Windows used to include telnet by default, up until the Vista/Server 2008 wave. Other popular operating systems, such as Mac OSX, Ubuntu, BSD, and SUSE all include telnet by default. The only OS I could find that didn’t include telnet in the default distro was CentOS/RedHat. Have you ever heard of anyone uninstalling the telnet client from their Mac OSX installation because it was unsecure? Ubuntu is one of the most widely used server operating systems on the web, and comes with telnet pre-installed on the server distro. Nobody has a problem with these big players coming with telnet by default, why would Windows be any different?
2 - Unencrypted traffic is OK
If you have a problem with a server sending unencrypted traffic, then what about the **ftp **and wget clients that are included in most operating systems? Even CentOS has the unencrypted ftp client available in the default distro. The ftp and wget commands both send usernames and passwords in plain-text, in addition to all of the other packets they send/receive. Many of the protocols we use every day are unencrypted, such as FTP, HTTP, DNS, and DHCP. The key is that an educated user can still use unencrypted services if they understand the limitations and precautions that need to be taken. We are a long way away from a 100% encrypted internet.
3 - Telnet is outbound only
The telnet client does not represent a significant security risk because it does not listen for requests, but rather only initiates outbound requests. There’s no risk of outside entities attacking your telnet client. You choose when and who to initiate traffic to. There are no open ports, there are no always-running daemons.
The default FTP and HTTP tools have access to your hard drive and your file system, which would allow a man-in-the-middle to alter the file that you are downloading in-transit. FTP and HTTP protocols have been widely used to deploy viruses and other malware. These are unsecure protocols that are far more dangerous than telnet, and yet their presence is considered the default state. Telnet is a pure communication channel, and so it is not possible to be served a virus or other bad code through a MITM session.
4 - Telnet is useful
Telnet is a powerful tool for testing a variety of functionality. Telnet is crucial for the validation and troubleshooting of SMTP servers. Telnet allows you to test and confirm open ports and firewall settings. As long as you’re aware of the risks (unencrypted traffic), telnet is a tool that should be in everyone’s repertoire and on every server.
If you blocked all unencrypted traffic, the internet would be in shambles. Most email would stop flowing (SMTP), the majority of sites would go dark (HTTP), and file servers everywhere would disappear (FTP). You shouldn’t be using telnet to connect to your secure network devices, but you also shouldn’t be using HTTP to connect to your secure banking website. Telnet is a useful for plenty of other situations. When FTP or HTTP tools are included on every operating system, why leave out the as-secure and yet often more-useful telnet?
5 - Don’t blame the tool
We’ve all heard the stories of misguided administrators using telnet to connect to their secure network devices or very important data sources. We should be replacing telnet with SSH wherever possible, especially if there is any confidential data or passwords involved. Telnet is not even an acceptable management tool inside a firewalled network, because you never know if your network has been compromised. I am not advocating the use of telnet for purposes that do not suit it.
The fact is that there are use cases for telnet that make sense and that will not be replaced by encrypted protocols in the near future. A completely encrypted worldwide SMTP network is still years away, and until then, telnet is a valuable tool when working with mail. When working with other unencrypted services, telnet is a simple and effective tool for confirming firewall settings and doing basic testing. It’s not for managing your switches or servers, but rather as a basic networking tool like netcat or ping.