The major security weakness of TELNET is that all communications between the Telnet client and server are passed in plaintext (that is, unencrypted) across the network. That means usernames, passwords, sensitive system data, and other possibly confidential information is visible to anyone running a network sniffer located between the client and server. Worst of all, because of the way a routed IP network functions, machines on other parts of the network might also gain visibility of the data.

This makes TELNET unsuitable for use in environments where the security of the underlying network or every host en route cannot be completely trusted. To put it another way, as a UNIX administrator, you probably have no control over security outside of your system—your options are confined to host-based network controls only.

Other attacks include insertion or replay attacks in which a Man In The Middle (MITM) changes the data on-the-fly or plays back an earlier data capture. Imagine finding yourself adding a user to the system with no hands!

Vendors can ship systems with default user ids and passwords. Unless you change default passwords or lock the accounts, a remote attacker can gain access by using Telnet.

Information Leakage

By default, vendors tend to ship the Telnet daemon with a default login prompt that greets users with the name of the operating system, the version, and sometimes the system architecture. This kind of information helps attackers. With it, they can whip out their nastiest exploits geared specifically to your platform. Why give this information away so easily to an attacker? The reality is that removing this information won't stop your operating system from being identified remotely. (To find out why, read on.) However, I would argue that announcing your system details to anyone who makes a connection to your machine is making things a little too easy! Remove product / version info from your login banner. Some sites replace the vendor greeting with a legal "No unauthorized access" message. Check with your legal department for specific wording.

The TELNET daemon leaks information about your operating system in a less obvious way, too. The TELNET protocol defines a number of Telnet options. When a Telnet client connects to a Telnet server, either end can transmit Telnet options. These enable one side to express its capabilities and requested functionality to the other—for example, its terminal type. A remote attacker, able to connect to the TELNET daemon, can use this to her advantage.

There is no standard TELNET daemon implementation. Different vendors implemented different Telnet options. By examining the Telnet options and the sequence in which they are received, an attacker can fingerprint your operating system.

I Spy with My Little Eye

Before launching an attack on a site, an attacker will perform remote reconnaissance. They will want to find out the type and version of operating system and the services you are running. Network daemons commonly announce their software version upon a client connection. This can help when you are remote troubleshooting because network administrators can easily identify software version incompatibilities. In the same way though, it assists the attacker. Armed with this information, she can search vulnerability databases for known weaknesses or, in preparation for an attack, re-create an identical system in her lab for penetration testing.

A common reaction to this problem is to remove product / version information from system banners. This might mean

· Recompiling open source network daemons with this information stripped

· Overwriting the banner strings in closed source binaries

· Modifying configuration files (for example, / etc / issue on Solaris)

This will thwart banner grabbing.

However, even if you did this to all your network daemons, the version of your operating system and all its network software can still be identified remotely through the process of behavioral analysis.

Remote Determination of Network Service Versions

Software versions change because of bug fixes, additional software features, performance hacks, and so on. The attacker can probe for feature or bug differences between versions, thereby determining the specific version in use. This is not the long and complicated task it might sound. The attacker can make the reasonable assumption that a site is running a relatively recent version and work back. In fact, this kind of functionality is built in to some commercial vulnerability scanners.

Remote Operating System Identification

Vendors' TCP / IP stacks respond differently to a given set of packets. By remotely fingerprinting the TCP / IP stack, it is often possible to identify the operating system in use and its version. The attacker sends a sequence of packets with specific attributes. The response packets sent by the victim server contain unique elements that, when considered together, uniquely identify a vendor's TCP / IP implementation. The queso tool originally used this approach. This strategy was then adopted and expanded by Fyodor in his nmap tool available from http: / / www.insecure.org / nmap .

Vendors TCP / IP stacks also exhibit distinguishing timing characteristics in their handling of packets. When a system receives a packet, the network interface hardware generates an interrupt. The kernel processes the packet based on information contained in the packet header. The time taken for a given platform to process the packet will vary depending on the code path taken (that is, if it's x, then do y; if it's x and z, do j). By sending multiple packets of varying complexity, it is theoretically possible to measure response times and compare them to known baselines to identify systems. This has been discussed in public forums, although no tool has been published as of yet.

Modifying network kernel parameters can defeat TCP / IP stack fingerprinting. These change the way that the TCP / IP stack behaves and will thwart known fingerprinting techniques.

This might leave you wondering whether it is worth removing system details from banners at all. There's certainly room for debate, but my personal view is that, for Internet-exposed hosts, it is worth the effort, as long as you understand it doesn't buy you any real security. What you're actually getting is security by obscurity. But, it might just be a reprieve from the less advanced attacker who relies on banner-grabbing-style scanning to identify potential victims. When the next remotely exploitable vulnerability gets announced, your banner-less system is unlikely to appear on the script kiddies'radar. Sure, you'll need to apply patches—but at least you might avoid the embarrassment of being nailed by an amateur!

Securing Telnet

One option is to use router- or VPN-based encryption. This is a partial solution; it does not result in end-to-end encryption. This can still leave the TELNET data stream open to MITM attacks near either end of the connection.

The superior solution and stock replacement for TELNET is Secure Shell (SSH). SSH is deployed at thousands of sites worldwide and has become the standard way of remotely accessing a UNIX server across potentially hostile networks.

SSH is a TCP-based service that, by default, listens on port 22.