Section 4.3 Telnet

---

4.3 Telnet

Telnet has two problems. All of a user's data is sent unencrypted so that anyone sniffing the network anywhere between your system and the other system will see all the data. It also is vulnerable to a "Man-in-the-middle attack," discussed in "Man-in-the-Middle Attack" on page 257.

The worse news is that the password used to log in to the server is sent in clear text. Assume that the V.P. of Finance downloaded an archive of jokes. A cracker could have sniffed his password. He now might be in the V.P.'s account, reading his confidential files containing bank account numbers, the planned IPO (Initial Public stock Offering), and details on that great new idea that could make the company millions of dollars.

An additional problem is that a cracker can try guessing each account's telnet password as many times as he wants because telnetd does not track the number of incorrect guesses. These bad guesses will end up in the log files. See "An Example for Automatic Paging" on page 620 for a description of how to arrange to be paged as soon as someone enters a bad telnet password.

Moreover, because telnet uses the user's login password if shadow passwords are not being used and a cracker gets a copy of /etc/passwd, then the cracker first can crack the password on his own system and then use telnet without the delay and risk of discovery of repeatedly sending password guesses to your system.

A proper solution is to require your users to use SSH for data that leaves protected networks and to enforce this by configuring the firewall to block telnet's port in each direction. Requiring your people to use SSH instead of telnet internally will also protect against crackers, including any inside the organization, getting into your internal network and sniffing internal data from there. Removing telnet and telnetd will help here. Another option is using stelnet, an SSL-wrapped telnet solution.

---

Top