Answer: YES. But telnet and rlogin are not the only two programs that increase the risk to a site. Any other program that allows incoming connections and does not have the ability to encrypt it's data is a risk. Some examples are ftp, pop and older versions of sendmail. Sniffers can easily pick off passwords transmitted in plain-text from any of these programs. And the problems with anonymous ftp could easily take up a few paragraphs. In addition, there are still vendors that ship their software with non-passworded accounts by default, which is yet another risk. However, this question was explicitly aimed at telnet and rlogin so let's just stick to those for now.
telnet is used to make connections between machines on a network. By default, telnet tries to connect to the remote host using Port 23. But telnet has the ability to connect to any port that has a valid listener. telnet can be used to spoof or exploit valid protocols. One old example that comes to mind is the WIZ command that used to exist in sendmail. One could telnet to the sendmail port, start up a conversation with the remote sendmail daemon and drop oneself into root fairly trivially. Other examples are the stack overflows of various other programs that are started by the internet server inetd. Although these examples are exploits of other valid programs, the means to get to them is via telnet.
Some versions of telnet have the ability to execute non-interactive commands. If a .telnetrc file exists on the remote machine, then telnet commands in that file will be executed as if they were typed in manually at the telnet prompt. There are versions of telnet that can use Kerberos authentication, and some that can use encryption, but that is still the exception. Check your manual page to see if your version of telnet will support Kerberos authentication or encryption. Without encryption, telnet sends all commands in plaintext, making telnet sessions easy fodder for packet sniffer programs.
If your version of the telnet daemon telnetd has been built with support for authentication or encryption, then those options can be enabled in the /etc/inetd.conf file, giving a slightly more secure telnet. Whether or not your telnetd supports authentication or encryption, telnet should be wrapped via a wrapper program like TCPWrappers to at least enable some tracking of connections. Using wrappers will also allow you to restrict incoming telnet connections using the /etc/hosts.allow and /etc/hosts.deny files. Since telnet is often the target of port-scanning software, a vigilant SysAdmin could comb the logs and subsequently disallow connections from sites or domains that no one should be connecting from.
Here's a listing of past telnet exploits, courtesy of rootshell :
Now for rlogin. rlogin is part of the r-command package that also includes rsh and rexec. The really scary part about rlogin/rsh is that if an /etc/hosts.equivM file exists on the system or the user has a .rhosts file, then no password is needed for the user. One of the gaping security holes that comes to mind with this one is the vendor that shipped their operating system with "+" in the /etc/hosts.equivM (trusted hosts) file. [The + is an NIS or YP convention.] The .rhosts and /etc/hosts.equivM files can give a cracker access to other machines easier than any other method. Modern cracker scripts still search for .rhosts files and /etc/hosts.equivM files on systems to get a topology of trusted hosts. They then use those accounts and machines to propagate their cracking activities.
Newer versions of rlogin also exist that employ authentication and encryption, and if yours is compiled with that support, you are highly encouraged to use it. As with telnet, those options can be enabled for the rlogind daemon in the /etc/inetd.conffile, giving a more secure rlogin. Regardless, if you allow rlogin connections you should wrap ALL your r-commands started in /etc/inetd.confwith a wrapper program like TCPWrappers and discourage the use of .rhosts, maybe even setting up a script to prune .rhosts files from your system on an hourly basis.
Here's a listing of past r-command exploits, courtesy of rootshell :
Even better would be to install the SSH package, which is a more secure replacement for rlogin/rsh/rcp. And then turn off BOTH rlogin and telnet in your /etc/inetd.conf file.
Laurie Zirkle, CSE