|
|
This chapter examines attacks developed over the years using the Telnet service. That examination begins with a bit of history. The Telnet protocol was first comprehensively defined by Postel in 1980. In RFC 764, Postel wrote:
Cross Reference: RFC 764 can be found on the Web at http://sunsite.auc.dk/RFC/rfc/rfc764.html.
As I mentioned in Chapter 6, "A Brief Primer on TCP/IP," Telnet is unique in its design with the notable exception of rlogin. Telnet is designed to allow a user to log in to a foreign machine and execute commands there. Telnet (like rlogin) works as though you are at the console of the remote machine, as if you physically approached the remote machine, turned it on, and began working.
NOTE: PC users can get a feel for this by thinking in terms of PCAnywhere or CloseUp. These programs allow you to remotely log in to another PC and execute commands at the remote machine's C: prompt (or even execute commands in Windows, providing you have a very high-speed connection to transmit those graphics over the wire).
The magic behind Telnet is that it imitates an ASCII terminal connection between two machines located great distances from each other. This is accomplished through the use of a virtual terminal, as described by Postel in this excerpt from RFC 854:
Cross Reference: Read RFC 854 in its entirety at http://sunsite.auc.dk/RFC/rfc/rfc854.html.
A virtual terminal is the equivalent (at least in appearance) of a hard-wired serial connection between the two machines. For example, you can simulate something very similar to a Telnet session by uncommenting the respawn instructions in the inittab file on a Linux box (and most other UNIX boxes) or by disconnecting both the monitor and keyboard on a SPARC and plugging a VT200 terminal into serial A or B. In the first instance, a login: prompt is issued. In the second, all boot process messages are echoed to the connected terminal and eventually, a boot prompt is issued (or perhaps, if the right SCSI disk drive is specified as the boot device in the PROM, the machine will boot and issue a login: prompt).
Therefore, Telnet-based connections are what are called bare bones connections. You will notice that if you use a VT220 terminal as a head for your SPARC that, when the boot occurs, the cool Sun logo is not printed in color, nor do the cool graphics associated with it appear. Telnet and terminal sessions are completely text based. In addition, Telnet connections do not have facilities to interpret display-oriented languages such as HTML without the assistance of a text-based browser such as Lynx. Therefore, retrieving a Web page through Telnet will reveal no pictures or nicely formatted text; it will reveal only the source of the document (unless, of course, you have logged in via Telnet and are now using Lynx).
NOTE: Lynx is a completely terminal-based HTML browser for use with shell-account or even DOS-based TCP/IP connections. It is a no-frills way to access the World Wide Web.
Telnet has cropped up in security advisories many times. Telnet security problems vary considerably, with a large number of vulnerabilities surfacing due to programming errors. However, programming errors are not the only reasons Telnet has appeared on advisories. In August of 1989, for example, the problem was a trojan, as the CERT advisory "Telnet Break-in Warning" explains:
Cross Reference: To view this CERT advisory in its entirety, visit ftp://ftp.uwsg.indiana.edu/pub/security/cert/cert_advisories/CA-89:03.telnet.breakin.warning.
That attack occurred just prior to the establishment of the DDN Security Coordination Center (September 1989), so there is little documentation about whether it affected government computers. Also, although the efforts of CERT are appreciated and vital to Internet security, DDN advisories sometimes contain a more technical analysis of the problem at hand.
In March, 1991, the telnetd daemon on certain Sun distributions was found to be flawed. As the CERT advisory "SunOS in.telnetd Vulnerability" notes:
Cross Reference: To view this CERT advisory in its entirety, visit ftp://info.cert.org/pub/cert_advisories/CA-91%3A02a.SunOS.telnetd.vulnerability.
TIP: If you buy an old Sun 3/60 over the Net, you will want to get the patches, which are included in the previous advisory.
Months later, it was determined that a specialized LAT/Telnet application developed by Digital Corporation was flawed. As the CERT advisory "ULTRIX LAT/Telnet Gateway Vulnerability" explains:
Cross Reference: To view this CERT advisory in its entirety, visit ftp://info.cert.org/pub/cert_advisories/CA-91%3A11.Ultrix.LAT-Telnet.gateway.vulnerability.
The first Telnet problem that rocked the average man on the street was related to a distribution of the NCSA Telnet client for PC and Macintosh machines. So that there is no misunderstanding here, this was a client Telnet application that included an FTP server within it. The hole was fostered primarily from users' poor understanding of how the application worked. As articulated by the folks at DDN:
The problem was related to a configuration option file in which one could enable or disable the FTP server. Most users assumed that if the statement enabling the server was not present, the server would not work. This was erroneous. By omitting the line (or adding the line option ftp=yes), one allowed unauthorized individuals read and write access to the files on your hard drive.
I hope this will settle the argument regarding whether a PC user could be attacked from the outside. So many discussions on Usenet become heated over this issue. The NCSA Telnet mishap was only one of many situations in which a PC or Mac user could be attacked from the void. So depending on the circumstances, the average user at home on his or her PC can be the victim of an attack from the outside. People may be able to read your files, delete them, and so forth.
What is more interesting is that even today, those using the NCSA Telnet application are at some risk, even if they only allow access to the FTP server by so-called authorized individuals. If a cracker manages to obtain from the target a valid username and password (and the cracker is therefore an authorized user), the cracker may then obtain the file FTPPASS. This is an authentication file where the usernames and passwords of users are stored. The encrypted passwords in this file are easily cracked.
The username in this file is not stored in encrypted form (in reality, few programs encrypt usernames). The password is encrypted, but the encryption scheme is very poorly implemented. For example, if the password is fewer than six characters, it will take only seconds to crack. In fact, it is so trivial to crack such passwords that one can do so with a 14-line BASIC program.
Cross Reference: The BASIC program that cracks passwords can be found at http://www.musa.it/gorgo/txt/NCSATelnetHack.txt.
If you are a Mac or PC user currently using NCSA Telnet (with the FTP server), disallow all FTP access to anyone you do not trust. If you fail to heed this warning, you may get cracked. Imagine a scenario where a single individual on a network was using NCSA Telnet. Even if the rest of the network was reasonably secure, this would blow its security to pieces. Moreover, the application does not perform logging (in the normal sense) and therefore, no trail is left behind. Any network running this application can be attacked, disabled, or destroyed, and no one will be able to identify the intruder.
The most interesting Telnet hole ever discovered, though, was related to the environment variable passing option. The DDN bulletin on it was posted on November 20, 1995:
Many sites suffer from this vulnerability. To understand the problem, you must understand the term environment. In UNIX vernacular, this generally refers to the environment of the shell (that is, what shell you might use as a default, what terminal emulation you are using, and so forth).
NOTE: DOS/Windows users can most easily understand this by thinking about some of the statements in their AUTOEXEC.BAT and CONFIG.SYS files. For example, variables are established using the SET command, as in SET PATH=C:\;C:\WINDOWS; (the PATH environment variable is one of several that can be specified in the DOS environment). These statements define what your programming environment will be like when you boot into command mode. Some common environment variables that can be set this way are the shell you are using, the path, the time zone, and so forth.
In UNIX, you can view or change the environment by using either the setenv or printenv command. Here is an example of what one might see on such an instruction:
> setenv ignoreeof=10 HOSTNAME=samshacker.samshack.net LOGNAME=tr MINICOM=-c on MAIL=/spool/mail/samshack TERM=ansi HOSTTYPE=i386-linux PATH=/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:. HOME=/usr/local/etc/web-clients/samshacker/./ SHELL=/bin/bash LS_OPTIONS=--8bit --color=tty -F -T 0 PS1=\h:\w\$ PS2=> TAPE=/dev/nftape MANPATH=/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11/man:/usr/openwin/man LESS=-MM OSTYPE=Linux OPENWINHOME=/usr/openwin SHLVL=2 BASH=/bin/bash LS_COLORS= _=/bin/csh PWD=/usr/local/etc/web-clients/samshacker/./ USER=tr HOST=samshack
This listing is a very extensive output of the command on a machine on which a virtual domain has been established. A more manageable (and more easily explained) version can be taken from a bare shell machine. Here is the output:
samshacker% /usr/ucb/printenv HOME=/home/hacker HZ=100 LOGNAME=hacker MAIL=/var/mail/hacker PATH=/usr/bin: SHELL=/sbin/sh TERM=ansi TZ=US/Pacific PWD=/home/hacker USER=hacker
This output is from a SPARCstation 10 on which I set up a mock shell account (the first output was from a Linux box). This is a very stripped-down environment. The PATH statement (line 6) points only to /usr/bin. In practice, this is impractical because there are many more binaries on a UNIX system than those located in /usr/bin. For example, there are binaries located in /usr/sbin, /usr/bin/X11, and so forth. You can see, for example, that even the command given (setenv) was done by issuing the absolute path statement (/usr/ucb/setenv). In practice, I would have (within a day or so) set a much longer path, pointing to man pages, binaries, and perhaps even include directories.
NOTE: The PATH statement in UNIX works almost exactly as it does in DOS. Directories that you intend to be in the path must be articulated on the PATH statement line and separated by colons (instead of semicolons). By articulating these on the PATH line, you give the user access to commands within these directories (no matter which directory the user is currently located in).
Other variables set in the preceding statements include HOME, MAIL, SHELL, and TERM. TERM, one of the most important variables, expresses the type of terminal emulation that you will be using. Because not all readers know what terminal emulation is, I want to quickly explain it.
Years ago, the majority of servers were mainframes. In those days, users did not have powerful PCs attached to the mainframe; they had terminals, which were (usually) boxes without hard drives. These were screens attached to keyboards. Behind terminals were a series of connectors, which might offer different methods of connection. One popular method was a bare-bones serial connection (we're talking primitive here: a straight serial-to-serial interface). Other terminals might sport hardwire options such as Ethernet connections.
In any event, these terminals had very little functionality (at least in comparison to the average PC). Contained on the main board of such a terminal was a small portion of memory and firmware (software hardwired into the board itself). This firmware would grant the user several options. For example, one could set the speed and type of connection, the need for local echo, and so forth. Sometimes, there were options to set the type of printer that might be used or even what port the data was to be sent from.
TIP: Such terminals are still sold on certain Usenet newsgroups. If you are a student with limited funds and you have been granted some form of Ethernet or even serial connection to your college's server, and if that server account is a shell account, get a terminal. For a mere $25-40, you can get high-speed access to the Internet. True, you cannot generally save materials to a disk, but you can print what is currently on the screen. You will not believe how quickly the screen will update. It is the absolutely ideal situation for Internet Relay Chat (IRC). These boxes are small, cheap, and fast.
The two best-known terminals were the Tektronix 4010 and the VT100 (also the IBM 3270, which is a bit different). Each had a set number of characters per line and lines per screen that could be displayed. In fact, most terminals usually had two settings. As terminals became more fancy, one could even set columns and, eventually, graphics (the Tektronix was graphics oriented).
Because these terminals became the standard method of connecting to mainframes, they also bled into the UNIX world. As such, all UNIX operating systems have keyboard and screen mappings for terminals. Mappings are descriptions of the screen and the keyboard settings (for example, how many lines and columns per screen or, more importantly, what Ctrl key sequences represent special characters). These are required because certain terminals use more keys than are offered on the standard PC or Mac keyboard. In addition to the regular typewriter keyboard and F function keys, there may be P keys that perform special actions, including the activation of menus and the navigation of the screen cursor in databases. To make up for this on PC, Mac, or even some UNIX keyboards, Esc or Ctrl sequences are defined. These are combinations of keystrokes that equal a P key. These key assignments are called key bindings, which are statements made within the program code that define what happens if this or that key combination is executed. Key bindings are a big part of programming, especially in C where you offer a semi-graphical interface (for example, where you use Borland's famous TurboVision libraries to create drop-down menus in a DOS application).
One can generally define key bindings in a program (at least, in a well written one). This gives the user application-level control over which keys do what. For example, perhaps the user can set the binding of the Ctrl key plus the letter F to perform a variety of functions. Some specialized applications actually ask the user to do so before launching the program for the first time. There is one such program--a freeware editor for UNIX, written in Germany--that allows you to completely remap the keyboard.
In UNIX, terminal mappings are generally stored in a file called termcap. The termcap library, reportedly introduced with Berkeley UNIX, is a very important addition to the system. Without it, many machines would not communicate well with each other. For example, if you perform a fresh install of a Linux operating system and do nothing to alter the TERM variable, it will be set to Linux. If you then Telnet to a SPARCstation (or other machine that also has its default TERM configuration), you will be unable to clear the screen with the well-known command clear. This is because the two terminal emulation settings are incompatible. Furthermore, if you try to execute a program such as PINE--which relies on compatible terminal types--the program will exit on error, reporting that the terminal is not supported. (SysV systems traditionally use terminfo as opposed to termcap.)
CAUTION: Many distributions of UNIX have complete termcap listings, which sometimes contain hundreds of terminal emulations. If you are new to UNIX and are toying with the idea of altering your termcap entries, be extremely careful. You may end up with bizarre results. In some cases, what once looked like nicely formatted text may appear as strange, disjointed, scattered blocks of words that are largely illegible. Study the man page before fiddling with your termcap file.
Many different environmental variables can be set. These variables can strongly influence how a remote machine will receive, process, and support your remote Telnet connection. Thus, the Telnet protocol was designed to allow the passing of certain environment variables at the time of the connection. As explained in RFC 1408:
Cross Reference: To view RFC 1408 in its entirety, visit http://sunsite.auc.dk/RFC/rfc/rfc1408.html.
The recent Telnet security hole was based on the capability of a Telnet server to receive, respond to, and authorize the passing of these environment variables. Because this option was so prominent in the UNIX system, an incredible number of platforms were vulnerable to this attack.
This vulnerability is more common than one would expect. In a rather engrossing report, one firm, Novatech, posted the results of an actual security audit of a network with 13 hosts. In it, the Telnet vulnerability appears, as do 138 other holes. The most extraordinary thing is that the site had already been assessed as having a clean bill of health, complete with a firewall. As Novatech's sample audit report notes:
Cross Reference: For those who have a "let's wait and see" attitude about security, I suggest that you go immediately to this site and view the results. They are astonishing. See the results of the audit at http://www.novatech.net.au/sample.htm.
The line that reveals the Telnet environment option vulnerability reads as follows:
Dynamic Linker Telnet Vulnerability [High Risk]2
This line reports that a Telnet vulnerability in the high risk category was found (in the audit cited previously, this vulnerability was found on two hosts within the same subnet). [High Risk]2 refers to the level of risk the hole represents. This is an extremely high risk vulnerability. Remember, this was found on a host with a state-of-the-art firewall!
To understand the method, you must understand precisely what options can be passed from the client to the server. One of these involves the passing of a custom libc.
NOTE: libc is the standard C library. A full distribution of libc commonly contains header and include files for use in C programming. All UNIX flavors have (or should have) this library installed. It is a requisite for compiling programs written in the C programming language.
As Sam Hartman of MIT notes in his article "Telnet Vulnerability: Shared Libraries":
Cross Reference: Find Hartman's article on the Web at http://geek-girl.com/bugtraq/1995_4/0032.html.
By passing the LD_LIBRARY_PATH environment option to the server, the cracker can add to this search path a custom directory (and therefore a custom library). This can alter the dynamic linking process, greatly increasing the chances of a root compromise.
NOTE: Hartman noted that if the target was using a Kerberos-aware telnetd, only users with a valid account on the remote box could actually implement the attack. My guess, however, is that the larger majority of machines out there are not using such a means of secure Telnet.
One interesting note about this hole: It was determined that one could identify Telnet sessions in which the environment variables had been passed by executing a ps instruction. However, one individual (Larry Doolittle) determined that on certain flavors of UNIX (Linux, specifically), one has to be root to ID those processes. In response to the Hartman report, Doolittle advised:
Cross Reference: Find Larry Doolittle's article on the Web at http://geek-girl.com/bugtraq/1995_4/0042.html.
Here are patches for various distributions of telnetd:
NOTE: Although patches have been issued for this problem, some other Telnet-related modules and programs may still be affected. As late as February, 1997, in.telnetsnoopd was reported as vulnerable to the LD_PRELOAD passing on some platforms, including Linux. There is reportedly a patch for this problem, and it has been uploaded to ftp://sunsite.unc.edu.
Garden-variety Telnet is not a particularly secure protocol. One can easily eavesdrop on Telnet sessions. In fact, there is a utility, called ttysnoop, designed for this purpose. As describe by its author, Carl Declerck:
Cross Reference: Declerck's README for ttysnoop 0.12 (alpha) can be found on the Web at http://ion.apana.org.au/pub/linux/sources/admin/ttysnoop-0.12.README
NOTE: ttysnoop is not simply a Telnet-specific snooper; it snoops on the tty, not the Telnet protocol. A network sniffer like sniffit can also be used (and is probably more suitable) to sniff the Telnet protocol.
Telnet sessions are also especially sensitive. One reason for this is that these sessions are often conducted in an island-hopping pattern. That is, the user may Telnet to one network to tidy his or her Web page; from there, the user may Telnet to another machine, and another machine, and so on. If a cracker can snoop on such a session, he or she can obtain login IDs and passwords to other systems.
No; this is due primarily to a lack of education. The environment option attack described previously is quite effective on many systems in the void. This is so even though advisories about the attack are readily available on the Internet.
Telnet is an interesting protocol. As explained earlier, one can learn many things using Telnet. For example, you can cull what version of the operating system is being run. Most distributions of UNIX will report this information on connection. It is reported by at least one authoritative source that various scanners use the issue information at connect to identify the type of system (SATAN being one such scanner). The operating system can generally be determined by attacking any of these ports:
NOTE: Although I have only listed five ports, one can connect to the majority of TCP/IP ports by initiating a Telnet session. Some of these ports will remain in an entirely passive state while the connection is active, and the user will see nothing happen in particular. This is so with port 80 (HTTP), for example. However, you can issue perfectly valid requests to port 80 using Telnet and if those requests are valid, port 80 will respond. (The request needn't necessarily be valid. Issuing an erroneous GET instruction will elicit a lively response from the Web server if the request is sufficiently malformed.)
In their now-famous paper, "Improving the Security of Your Site by Breaking Into It," Dan Farmer and Wietse Venema point out ports that can be attacked. Specifically, they address the issue of port 6000:
Cross Reference: "Improving the Security of Your Site by Breaking Into It" can be found on the Web at http://stos-www.cit.cornell.edu/Mark_html/Satan_html/docs/admin_guide_to_cracking.html
In the paper by Farmer and Venema are many attacks implemented with Telnet alone or in conjunction with other programs. One such attack involves an X terminal:
The Farmer-Venema X terminal technique uses a combination of rsh and Telnet to produce a coordinated attack. The technique involves stacking several commands. The cracker uses rsh to connect to the X terminal and calls the X terminal's Telnet client program. Finally, the output is redirected to the cracker's local terminal via the specification of the DISPLAY option or variable.
Another interesting thing that Telnet can be used for is to instantly determine whether the target is a real or virtual domain (this can be done through other methods, but none perform this function quite as quickly). This can assist a cracker in determining exactly which machine he or she must crack to reach your resources or, more precisely, exactly which machine he or she is engaged in cracking.
Under normal circumstances, a real domain is a domain that has been registered with InterNIC and also has its own dedicated server. Somewhere in the void is a box with a permanent IP address, and that box is attached permanently to the Internet via 28.8Kbps modem, ISDN, 56Kbps modem, frame relay, T1, T3, ATM, or perhaps, if the owner spares no expense, SONET. As such, when you Telnet to such a real site, you are reaching that machine and no other.
Virtual domains, however, are simply directories on a real server, aliased to a particular domain name. That is, you pay some ISP to register your domain name and create a directory on its disk where your virtual domain exists. This technique allows your_company.com to masquerade as a real server. Thus, when users point their browsers to www.your_company.com, they are reaching the ISP's server. The ISP's server redirects the connection request to your directory on the server. This virtual domain scheme is popular for several reasons, including cost. It saves your company the trouble of establishing a real server and therefore eliminates some of these expenses:
Basically, you pay a one-time fee (and monthly fees thereafter) and the ISP handles everything. To crackers, this might be important. For example, if crackers are about to crack your domain--without determining whether your machine is truly a server--they may get into trouble. They think they are cracking some little machine within your internal offices when in fact, they are about to attack a large, well-known network provider.
Telnet instantly reveals the state of your server. When a cracker initiates a Telnet connection to your_company.com (and on connect, sees the name of the machine as a node on some other, large network), he or she immediately knows that your address is a virtual domain.
Moreover, Telnet can be used for other nefarious purposes. One is the ever-popular brute-force attack. I am not sure why brute-force attacks are so popular among young crackers; almost all servers do some form of logging these days. Nevertheless, the technique has survived into the 1990s. These attacks are most commonly initiated using Telnet clients that have their own scripting language built in. Tera Term is one such application.
Tera Term sports a language that allows you to automate Telnet sessions. This language can be used to construct scripts that can determine valid usernames on a system that refuses to cough up information on finger or sendmail-expn queries. Versions of Telnet reveal this information in a variety of ways. For example, if a bogus username is given, the connection will be cut. However, if a valid username is given, a new login: prompt is reissued.
Cross Reference: Tera Term can be found on the Web at http://tucows.phx.cox.com/files/ttermv13.zip.
Moreover, Telnet is a great tool for quickly determining whether a particular port is open or whether a server is running a particular service. Telnet can also be used as a weapon in denial-of-service attacks. For example, sending garbage to certain ports on an NT Web server under IIS can cause the targeted processor to jump to 100 percent utilization. Initiating a Telnet session to other ports on an NT Web server can cause the machine to hang or crash. This is particularly so when issuing a Telnet connection request to port 135.
Cross Reference: A fix for this problem, issued by Microsoft, can be found at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postS
One can also crash Microsoft's Internet Information Server by Telnetting to port 80 and issuing a GET.../... request. Reportedly, however, that problem was remedied with the Microsoft Windows NT Service Pack 2 for Windows NT 4.0. If you do not have that patch/service pack, get it. A good treatment of this and other problems can be found in the Denial of Service Info post, posted by Chris Klaus of Internet Security Systems. In it, Klaus writes:
Cross Reference: Visit the Denial of Service Info post at http://geek-girl.com/bugtraq/1996_2/0052.html.
NOTE: This was only a vulnerability in the Internet Information Server 2.0 World Wide Web server (HTTP). Later versions of IIS are reportedly clean.
Finally, Telnet is often used to generate fakemail and fakenews. Spammers often use this option instead of using regular means of posting Usenet messages. There are certain options that can be set this way that permit spammers to avoid at least some of the screens created by spam-killing robots on the Usenet network.
Telnet is a very versatile protocol and, with some effort, it can be made secure. (I personally favor SSH as a substitute, for it prevents against snooped Telnet sessions.) Nevertheless, Telnet is not always secure out of the box. If you are using older software (pre 1997), check whether the appropriate patches have been installed.
Telnet can also be used in a variety of ways to attack or otherwise cull information from a remote host (some of those are discussed in this chapter). By the time this book is released, many more Telnet attack techniques will have surfaced. If you run a network and intend to supply your users with Telnet access, beware. This is especially so on new Telnet servers. These new servers may have bugs that have not yet been revealed. And, because Telnet is so interactive and offers the user so much power to execute commands on remote machines, any hole in a Telnet distribution is a critical one. It stands in the same category as FTP or HTTP in this respect (or is perhaps even worse).
Sendmail Bug Exploits List. Explains methods of attacking sendmail. Some of these techniques use Telnet as the base application.
Improving the Security of Your Site by Breaking Into It. Dan Farmer and Wietse Venema.
The Telnet Protocol Specification (RFC 854). J. Postel and J. Reynolds. May 1983.
The Telnet Environment Option (RFC 1408). D. Borman, Editor. Cray Research, Inc. January 1993.
Telnet Environment Option (RFC 1572). S. Alexander.
Telnet Authentication: SPX (RFC 1412). K. Alagappan.
Telnet Remote Flow Control Option. (RFC 1372). C. Hedrick and D. Borman.
Telnet Linemode Option (RFC 1184). D.A. Borman.
The Q Method of Implementing Telnet Option Negotiation (RFC 1143). D.J. Bernstein.
Telnet X Display Location Option (RFC 1096). G.A. Marcy.
Telnet Binary Transmission (RFC 856). J. Postel and J.K. Reynolds.
Remote User Telnet Service (RFC 818). J. Postel.
Discussion of Telnet Protocol (RFC 139). T.C. O'Sullivan. Unfortunately, this RFC is no longer available online.
First Cut at a Proposed Telnet Protocol (RFC 97). J.T. Melvin and R.W. Watson. Unfortunately, this RFC is no longer available online.
The Telnet Authentication Option. Internet Engineering Task Force Internet Draft. Telnet Working Group. D. Borman, Editor. Cray Research, Inc. February 1991.
Telnet Authentication: Kerberos Version 4 (RFC 1411). D. Borman, Editor. Cray Research, Inc. January 1993.
STEL: Secure Telnet. Encryption-enabled Telnet. David Vincenzetti, Stefano Taino, and Fabio Bolognesi.
Session-Layer Encryption. Matt Blaze and Steve Bellovin. Proceedings of the Usenix Security Workshop, June 1995.
Attaching Non-TCP-IP Devices with Telnet. Stefan C. Johnson. Sys Admin: The Journal for UNIX Systems Administrators. June 1996.
Secure RPC Authentication (SRA) for Telnet and FTP. David K. Hess, David R. Safford, and Douglas Lee Schales. Proceedings of the Fourth Usenix Security Symposium, Supercomputer Center, Texas A&M University, 1993.
Internetworking with TCP/IP Vol. 1: Principles, Protocols and Architecture. Douglas Comer. Prentice Hall. 1991.
Terminal Hopping. Karen Bannan. PC Magazine's InternetUser--CRT, Version 1.1.4 (01/30/97).
Telnet & Terminal Emulation. PC Magazine's InternetUser. January 30, 1997.
EFF's (Extended) Guide to the Internet--Telnet. Adam Gaffin. Mining the Net, Part I.
© Copyright, Macmillan Computer Publishing. All rights reserved.