The fundamental purpose of networking is to enable different computer systems to communicate with one another. This communication happens in different ways, ranging from a program accessing a database across a network to a person sitting at a workstation engaging in an interactive session with another computer by way of a direct network connection. This chapter focuses on the latter connection.
One of the most popular protocols that provides a direct interface for a remote system is the Telnet protocol. In this chapter, you learn about the Telnet protocol and how it works. This chapter compares Telnet to its partner remote logon protocol, rlogin. I explain Telnet's relationship to the intranet and discuss methods of monitoring resource utilization by way of Telnet. Additionally, I explore the all-important issues surrounding the security of data transmitted via Telnet.
Telnet is a well-established component of the TCP/IP protocol suite, and this is what makes it so relevant and useful to an intranet. The basic premise of an intranet is to offer universal access to an organization's public data and programs, and Telnet is the one universal cross-platform utility for directly accessing a host system. You don't have to worry too much about your client base-whether you have UNIX workstations, Macs, NT workstations, DOS/Windows machines with third-party TCP/IP stacks, or a mix of all of these-all will be able to interact with a system set up as a Telnet server. Telnet even lets your workstation run its own operating system, run programs on a remote host running some completely different operating system, and interactively display the results of that "incompatible" system's program back at your workstation! In short, Telnet's near-universal support across platforms makes it an ideal tool for enabling host access when you might not even know who will need to access your intranet or what machines they will be using.
In a nutshell, Telnet provides the ability to perform remote logons. Telnet has both a client and a server component. When a user initiates a Telnet session through the Telnet client, the user sends a request to a remote system to supply the user with a virtual terminal session-in other words, a session that looks and behaves exactly as if the user were sitting in front of the remote computer. Figure 29.1 illustrates an example of a Telnet session. In the figure, a remote system named varmint is located on a local area network. At a different physical location is another system on the network named vittle. Assume that a user is sitting in front of vittle, and he or she must look at a file that resides on varmint. The user initiates a Telnet session with varmint from within a window on vittle; the window then responds exactly as a session would respond if the user were actually sitting at varmint.
Figure 29.1: A Telnet session between varmint and vittle.
Now look at an actual initiation of a Telnet session. In this example, a user named Anna is sitting at the vittle system just described. In Listing 29.1, Anna types the command telnet varmint. This command executes the Telnet client program with the argument varmint, which tells her system to initiate a Telnet session with a system named varmint. Her local system maps the name varmint to an IP address, 194.5.30.68. The Telnet client program then informs Anna that it is trying to connect to that IP address via Telnet.
Listing 29.1. Initiating a Telnet session.
Vittle% telnet varmint Trying 194.5.30.68 ... Connected to varmint. Escape character is '^]". SunOS UNIX (varmint) login: anna Password: varmint%
Vittle begins sending packets of data addressed to the IP address 194.5.30.68 and requests a response from the Telnet server. If the Telnet server process is running on the system addressed to 194.5.30.68, the server responds and a connection between the two systems is established. The Telnet client announces it has connected successfully and surrenders control of the window to system varmint. At this point, Anna sees in her window exactly what she would see if she were sitting in front of system varmint. All the commands Anna executes from within this Telnet session are executed on the remote system varmint, not on her local machine vittle. If she prints a file to the local printer, as illustrated in Figure 29.2, the file is printed on the local printer connected to varmint, not vittle.
Figure 29.2: Printing to the local printer from within Telnet.
When Anna is finished working on system varmint, she ends her Telnet session by logging out or exiting her session in the same way she would if she were in front of varmint and wanted to log off and go home for the weekend. The control of the window is then returned to her local system vittle.
Now that you've witnessed a brief example of a Telnet session, you'll look more closely at how Telnet works in the following sections.
Telnet is a client/server-based program. The client side of Telnet is a program that a user runs to request an interactive session. The server side of Telnet is a process that is in a dormant or sleeping state until it hears a request from a Telnet client. The server side grants the client's request and passes the keystrokes entered from the Telnet client session on to the operating system of the server.
As a part of the TCP/IP protocol suite, Telnet is provided with most TCP/IP packages, and clients behave much the same across the board. On the server side of Telnet, however, are some limitations. Telnet operates on the principle of multitasking; in other words, the system can divide its attention among multiple functions and perform them all at the same time, although slower than if performing only one function at a time. Multitasking lets Anna Telnet to the system varmint while another user is actually at the system's console doing something else. Multitasking permits the server to divide its attention between the person at the local machine and Anna, who is at a remote location. If varmint were not a multitasking system and if Anna were granted access via Telnet, the local user would be unable to perform any functions.
If your system does not multitask, it can't serve as a Telnet server. Because MS-DOS systems lack multitasking capabilities, they cannot serve as Telnet servers. PCs do have multitasking capabilities, however, as the ability to multitask is tied to the operating system, not the type of hardware. Linux (a PC-based implementation of UNIX), for example, is a multitasking operating system and can serve as a Telnet server. Windows NT also is a multitasking operating system, but Telnet servers for this operating system just recently hit the market. For these reasons, I focus on the UNIX implementation of Telnet, which is more stable and more prevalent than Windows NT Telnet services.
Although this section gets somewhat technical, you need to understand how Telnet works at the TCP/IP level from a security standpoint. TCP/IP is a set of protocols that use the concept of ports and sockets. Within TCP/IP networks, many types of transactions move from machine to machine across the network, including Telnet requests and commands; FTP transactions, such as "getting" a file; and network routing data. TCP/IP uses the port/socket model to distinguish the data being received and to sort the different types of transactions coming into a system through a single network connection.
Each type of transaction is assigned a certain port number. Think of your computer as a popular delicatessen with a large menu of sandwiches. Instead of ordering sandwiches by name, you order by a corresponding number that appears next to each sandwich on the menu. If you want pastrami on rye, you order "number 42." In this analogy, different network transactions are the same as different types of sandwiches. Whenever a chunk of data (a "packet") is transmitted, a header appears before it, identifying a certain port number. This way, the system can handle multiple network sessions concurrently. As the data from the different transactions is received by the network interface, it is passed up to different applications by the port number in the header. If you want a portion of the TCP/IP "menu" identifying certain services with certain port numbers, look at the /etc/services file on any UNIX system. Port number 23 is typically reserved as the port number for outgoing Telnet data. I come back to the port/socket model later in this chapter; see "Security Issues: Transmissions Over Ethernet."
Telnet has a similar "sister" remote login protocol called rlogin. It also is a part of TCP/IP, and most UNIX systems with a TCP/IP stack provide both Telnet and rlogin as connectivity services. Why two different protocols? What is the difference? First, from the user standpoint, rlogin automatically assumes that when a user tries to connect to another system, the username will be consistent from system to system. If user Bill utilizes rlogin to connect to another server, the remote system assumes that it is user Bill trying to connect and asks immediately for a password, not permitting Bill to use a different login name.
rlogin also can be configured to allow trusted hosts. This way, a user can connect directly to another system via rlogin without even typing a password. rlogin may seem like a tremendous time-saver, bypassing the inconvenience of typing in usernames and passwords when connecting to another system. Keep in mind, however, the security issues that arise. Walking away from your desk for a half hour does not merely compromise the security of your local machine, but also any other systems on your LAN that permit rlogin and regard your system as a trusted host.
From a technical standpoint, Telnet is not only more secure, but it also is more stable than rlogin. The Telnet protocol allows both the client and server systems to negotiate the flow control and duplex, letting the systems make adjustments for slow network links, which rlogin does not.
Now that you know what Telnet does, look at how it is used in most local area networks.
Telnet is one of the most coveted tools of the system administrator. Usually the first step in troubleshooting a system's problem is to Telnet to the problem system. Many system administrators set up the system on their desktop with a large number of windows, each one connected to another system via a Telnet session. If a system goes down unexpectedly, the Telnet session ends abruptly. Thus, by looking at the screen and seeing that all the Telnet sessions are running, the system administrator can see that all the systems appear to be up. Of course, this method is not foolproof because in many situations a system "freezes," leaving the system administrator in the dark until he or she tries to execute a command and then learns that the system is hung. So, consider the Telnet a fundamental troubleshooting tool but not the end-all and be-all of the system administrator's tools.
Any command that you can enter from the command line on a system works via Telnet. These commands include any command that is not in a graphics window, that is not comprised of a "point and click," or that does not elicit a graphical response (like a dialog box opening up or displaying a new window). All other commands function as expected through Telnet. Graphic applications are addressed in the next section.
The following are some examples of command-line uses of Telnet:
These examples run from the very appropriate to the sneaky to the illegal. I included them to prove that Telnet is more than just a powerful tool; it is a powerful tool that can be used to elude authority. Keep your eyes open, and be aware of what activities can occur during a Telnet session. In fact, in the last example, the Telnet session was not even established, and there was a substantial security risk. I address using Telnet to keep tabs on all the users on your system in the section called "The who Command." Right now, just be aware of the breadth of ways individuals can use Telnet, and don't underestimate the resourcefulness of the wicked.
In the preceding section, I alluded to the complexities surrounding a graphical application. Let me show you why this is a sticking point. Imagine that user Anna is still sitting in front of vittle and connected to varmint via Telnet. She's had a long day, and she needs a break. She knows that varmint has a graphic blackjack program on it, and Anna feels she's due to relax for a few minutes. She runs the blackjack program.
Now when she runs the blackjack program, the system runs it exactly as though she is sitting at the console. The program therefore displays a window on the console with a deck of cards spread out waiting for Anna to click the Shuffle button. The problem is that Anna is not at the console; another user, Bill, is. Bill is surprised when a window with a deck of cards appears on his screen. If Telnet behaves exactly as if you were sitting at the console, applications that are run from within it don't know that you are at a remote location. This means that you can't simply run a graphical program over a Telnet session by just running the program as if you were on the system. You must take certain steps prior to running the program in order to direct the application to send graphical images and tools to your "remote" screen. In a moment, I will describe these steps for a system running the X Window windowing system.
One of the most popular graphic windowing systems under TCP/IP is the X Window windowing system. The X Window system has a way to designate another system running X Window as the system to display any new graphics. Anna can log into varmint via Telnet, for example, tell it to send any graphic displays executed from within this session to vittle, and then run the blackjack program and have it display on the system at which she is sitting. Two steps make this process possible. First, on the local system, you can enable the display of remote graphics. This option typically is disabled because enabling remote displays results in other security issues. Anna can turn on the display by typing xhosts varmint to allow varmint to display graphics on her system or xhosts + if she wants to allow applications from any system to display graphics on her system. This command is entered on the system vittle, but not on varmint. After logging into varmint, Anna tells varmint to display data to vittle. She can do so by setting an environmental variable named DISPLAY (note that it is all in caps) to her local machine, followed by a colon and the number 0 (:0). If you're using the C-shell to run UNIX, you set it with the command setenv DISPLAY vittle:0.0 and then press Return. If you're running the Bourne Shell, you use the command DISPLAY=vittle:0.0; export DISPLAY. Following these two steps, all graphics spawned from the window in which the DISPLAY variable was set should display on the local system.
Remember, to change the display successfully, you must have a version of X Window running on the client system. If you have a PC with a Telnet client and TCP/IP stack, this is not enough. Make sure that you have a PC-based X Window emulation program, such as Hummingbird System's Exceed, to handle the local side of the graphics displays.
In the following sections, I explore the issues behind the effects of enabling Telnet from the server, with emphasis on user control and process control. I address the following questions:
What affects its performance?
How can you troubleshoot a Telnet server effectively?
How can you administer it better?
I wrote this chapter from a UNIX standpoint, because when this book was published there were limited Windows NT-based Telnet server capabilities.
Because running Telnet services opens up an individual host machine to an entire LAN, when that system becomes overworked, you must look beyond the console for the culprit. Here I address how to track who is logged into a system and how to monitor who logs into it.
When Telnet is used within a LAN, the user community of a given computer is extended beyond the physical system. As a result, any interruption of service, maintenance, or general system administration tasks may affect people outside the LAN. You must keep in mind that you cannot simply reboot a system without first asking, "Who is this reboot affecting that I can't see?"
Application resources also may be affected by the number of users. If you have purchased a database application with three concurrent licenses, all the users may be staff members accessing the application via Telnet, and the person at the system console may be unable to run the application. You may get a call from a frustrated user telling you that the database program is not working when, in essence, the database program is almost working too well.
Basically, enabling a system to be a Telnet server mandates a different philosophy of ownership. The computer on your desk is no longer yours and yours alone. You must keep this fact in mind in all circumstances, whether you're using a system's resources or interrupting its availability.
Using the UNIX command who, you can quickly discover who is logged into a system. Listing 29.2 shows the output of the who command.
Listing 29.2. The who
command.
Varmint% who anna ttyp0 May 29 12:35 (vittle... anna ttyp0 May 29 12:38 (vittle... varmint%
One entry exists for every unique login session. Listing 29.2 shows that Anna has two different Telnet sessions into the local system, and for that reason, two different entries correspond to her. Each line also displays the device that the user is using to connect to the system, the date and time the user logged in, if the session is a remote session, and from where the session originated. When prompted, the who command immediately gives you a quick snapshot of the system's user community.
If you want to review more detailed data on who has been logging in and accessing your system, the last command may fill your needs. Each time a user logs into a UNIX system, the system adds an entry to two files, one named /etc/utmp and another named /usr/adm/wtmp (or /var/adm/wtmp in some systems). When a user logs out, the entry in the utmp file is removed, and another entry is added to the wtmp file. As time passes, the wtmp file keeps a running history of who logs into the system, how long they were logged onto the system, and from where they logged in. At the same time, the utmp keeps track of who is logged into the system currently.
As you may guess, the who command parses data from the utmp file to provide the list of who is logged into the system. Likewise, the last command parses data from the wtmp file and presents a history of all the previous logins back to the time of creation of the wtmp file. Of course, for a system with a lot of activity, the output of this command can be unwieldy, but some command-line arguments can make it more reasonable. You can supply as an argument a certain username and gain as output only the time that that certain user logged into the system. You also can supply a number as an argument and get only the last n entries instead of the whole list. The command last -40, for example, generates only the last 40 sessions recorded in the wtmp file.
Listing 29.3 shows the output of the command last -5 Anna, which outputs data corresponding to the last five times user Anna logged into the system.
Listing 29.3. The last
command.
varmint% last -5 anna anna ttyp0 varmint Wed July 17 02:34 anna ttyp0 varmint Wed July 17 15:21 anna ttyp0 varmint Fri July 19 06:54 anna ttyp0 varmint Fri July 19 12:01 anna ttyp0 varmint Sat July 20 03:15 varmint%
The output of the last command contains fields that display the user's login name, an entry corresponding to the type of connection, the IP address or remote host name of the remote host system, the time of login and logout, and the total network time for which the connection was open. A plethora of information is available through the last command to aid the system administrator in determining who was logged into the system at certain times or to develop some trending data. This data helps track use of a given system.
You can use the command ac for connect-time accounting. It formats the data in the wtmp file in total login time in minutes. This command is available only in BSD-style (Berkeley Standard Distribution) UNIX implementations such as SunOS or Digital's OSF. The command ac with no output generates the total hours of connect time since the start of the wtmp file. The command ac -p shows each user who has logged in and the total number of connect hours each user has expended. The command ac -d provides a profile of total connection hours by date, as shown in Listing 29.4. Keep in mind that these commands monitor connections established not only by Telnet, but also by rlogin, along with any connections established at the console or any other terminals directly connected to the system. Interpret the data carefully.
Listing 29.4. The ac
-d command.
varmint% /usr/etc/ac -d Jul 10 total 6.06 Jul 11 total 25.36 Jul 12 total 23.91 Jul 13 total 24.00 Jul 17 total 96.06
Do not try to edit the utmp or wtmp files directly. They are not standard ASCII files, and you should access the data within them only with the commands designed to extract data from them. Also remember that these files contain all your historical data. Anyone can delete these files and erase his or her tracks. Of course, other tools to track down rogue users or hackers are at your disposal, but you should keep in mind that your data is only as reliable as the stability of these files. On the flip side, if your system is up and running for, say, 18 months, your wtmp file may get quite large, and you may want to "prune" this file. The best way to prune is to remove the file by using the rm command and re-create it empty with the touch command by typing touch /usr/adm/wtmp. By doing so, you lose the accounting data from the previous period. But if you want to keep that data, just print it out and store it in a folder before removing the file. Plan to prune monthly or at least at regular intervals.
Also, remember that you are looking at connection time by account, and not necessarily by person, so train your staff to log off or lock their systems when they leave their desks or go home for the weekend. Also, advise staff to keep their passwords to themselves so that the activity of their accounts is directly attributed to their own work and tasks. The significance of logging out at night is twofold. Not only does it ensure that no one else will sit at a person's desk and start working with the system assuming the identity of the original user, it also helps yield relevant accounting data. The person who stays logged in for the weekend logs at least 50 extra hours of connect time if you examine data from the ac command.
Keep in mind, too, that so far you have looked at the users logged into a system, not the processes running on the system. A single user can tie up a system's CPU with just one process, just as 50 users can have two Telnet sessions each open to a system and use very little CPU time. The latter might occur if a majority of sessions are inactive or the users are just performing non-CPU-intensive tasks. The greatest skill a system administrator has is the ability to interpret data wisely. You need to understand not only what data implies, but also what it does not imply.
Now that you have explored how to monitor who is accessing a system via Telnet, you're ready to look at how to understand what these remote users are doing on a system. As I mentioned previously, the number of users logged onto a system don't necessarily have the most effect on system performance, rather the jobs and tasks the users are performing are likely to have the most impact. In this section, you explore how to monitor processes, how to determine how demanding certain processes are, and how to match specific processes with a specific user.
All multitasking operating systems have internal methods to track the different processes running concurrently on a system and the various attributes associated with them. These attributes typically are kept in a process table. If you're a systems administrator, your ability to look at this process table and draw sound conclusions from it is perhaps the most important troubleshooting skill you can possess.
One of the main tools for process control under UNIX is the ps command. Because this command has many different options that vary from system to system, you should read your system's online man page or systems manual to utilize ps fully. (Man pages are a UNIX-based form of online help. If you type the command man followed by a UNIX command, an online "systems manual" page for the command you entered is displayed.) Here, I briefly cover the basics of the command and differentiate only between the BSD style of UNIX (for example, SunOS and DEC OSF) and the AT&T SVR4-style of UNIX (for example, Solaris and HP-UX). I focus on the BSD implementation of ps in this section.
The ps command unadorned lists the processes created by the current user from the same controlling terminal, as you can see in Listing 29.5. Each line corresponds to a unique process. The first field on each line is a process ID (PID). The PID is a unique number assigned to each process by the operating system kernel. The next two fields describe the processes controlling the terminal's ID and the current process status. The status field can be extremely useful in determining whether a process is behaving properly. Status codes may tell if the process is running (R), sleeping (I), or stopped (S) among other states. The next field tells how much CPU time has been utilized, and the last field shows exactly what the program or command tied to the process is.
Listing 29.5. The ps
command.
vittle% ps PID TT STAT TIME COMMAND 26312 p3 IW 0:00 -sh (csh) 26431 p3 IW 0:00 telnet varmint 26503 p4 S 0:00 -csh (csh) 26579 p4 R 0:00 ps
If you are addressing performance problems systems-wide, looking at the process you own only gives you part of the picture. If you supply the argument -aux (or the argument -elf, if you're using SVR4 UNIX), you get more extensive data on all processes running on the system, as shown in Listing 29.6.
Listing 29.6. Partial output from the ps
-aux command.
vittle% ps -aux USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root 1 0.0 0.0 52 0 ? IW Jul 23 0:13 /sbin/init - root 55 0.0 0.0 68 0 ? IW Jul 23 0:07 portmap root 98 0.0 0.0 64 0 ? IW Jul 23 0:32 syslogd root 105 0.0 0.0 108 0 ? IW Jul 23 0:04 /usr/lib/sendmail -bd -q root 140 0.0 0.0 128 0 ? IW Jul 23 1:36 /usr/etc/snmpd -c /etc/s root 261 0.0 0.0 52 0 ? IW Jul 23 0:00 /usr/lib/lpd root 582 0.0 0.2 32 44 ? S 12:24 0:00 in.telnetd . . . anna 27536 0.0 0.0 88 0 p0 IW Aug 1 0:01 -csh (csh) john 27540 0.0 0.0 90 0 p0 IW Aug 1 0:01 -csh (csh) anna 27555 0.0 0.0 500 0 p0 IW Aug 1 0:24 vi myfile ron 27554 0.0 1.1 164 296 p0 S Aug 1 1:28 -csh (csh) craig 27535 0.2 0.0 312 0 ? IW Aug 1 0:20 -csh (csh) john 28720 12.7 0.0 6268 0 p1 IW Aug 1 8:12 netscape vittle%
The output from the ps -aux command tells exactly who is doing what on your system. You not only get a list of how many users are on your system, but also what, if any, programs they are running. In Listing 29.6, you can see that user Anna is running an interactive shell program (csh), and she is using the vi text editing program to edit a file. You also can see that two users named Ron and Craig are running interactive shell programs, and a user named John is running the Web browser Netscape as well as an interactive shell session. If I were contacted because this system was running sluggishly, given the above user information, I would start with John. I would ask John to exit his Netscape application to see whether the performance improves. Undoubtedly, I would probably learn that Netscape had used more of the CPU than any other user processes.
Again, interpretation of the results is important. A process that has been up and running for weeks may have, over the course of these weeks, logged a great deal of CPU time but may not be the culprit of a sudden drop in performance. Take careful note of the %CPU field. It tells exactly what percent of the system resources are expended by each process. Many more sophisticated commands and tools are available, but they vary dramatically from system to system. I recommend that you refer to a book that focuses on your specific operating system (AIX, Solaris, and so on).
Before leaving the arena of process control, I want to touch briefly on an attribute of processes called Parent Process ID. If you execute the command ps -alx instead of ps -aux, a different set of process attributes will be listed, much of it advanced data regarding process control. The one field I want to focus on in this data is the Parent Process ID, which is under the heading PPID. Listing 29.7 shows the output of the ps -alx command for the exact set of processes shown in Listing 29.6.
Listing 29.7. Partial output from the ps
-alx command.
vittle% ps -alx F UID PID PPID CP PRI NI SZ RSS WCHAN STAT TT TIME COMMAND 20088000 1 0 0 0 5 0 52 0 child IW ? 0:13 /sbin/init - 88000 55 1 1 0 1 0 68 0 select IW ? 0:07 portmap 88001 98 1 1 0 1 0 64 148 select S ? 0:32 syslogd 88000 105 1 1 0 1 0 108 0 socket IW ? 0:04 /usr/lib/sen 80488000 140 1 1 0 1 0 128 0 socket IW ? 1:36 /usr/etc/snm 88000 261 1 1 0 1 0 52 0 select IW ? 0:00 /usr/lib/lpd 20088001 582 1 258 0 1 0 32 44 select S ? 0:00 in.telnetd . . . a048800010368 27536 1 0 3 0 88 0 Sysbase IW p0 0:01 -csh (csh) a04880001037- 27540 582 0 3 0 88 0 Sysbase IW p0 0:01 -csh (csh) 2008800010368 27555 27536 0 1 0 500 0 select IW p0 0:24 vi myfile 2008800110368 27554 582 0 1 0 164 296 select S p0 1:28 -csh (csh) 2008800010368 27535 582 0 1 0 312 0 select IW ? 0:20 -csh (csh) 2000800010370 28720 27540 1 1 06268 0 select IW p1 8:12 netscape vittle%
Every process is fired off by another process-its parent. If you look at the ps -alx output, you can trace John's Netscape process to its parent by way of its parent's ID, which is the program csh. In turn, you can trace the csh process to its parent, the process in.telnetd, the Telnet server program. You can effectively trace back the potential system overload to a program executed by a user over a Telnet session. Through the PPID, you can learn a great deal about the origin of a process.
When users are connecting to a system remotely via Telnet, there are more points of failure than if they are not remote. To the Telnet users, any problem with the network or either the local or remote system yields the same unhappy responses from users-"The system is down! I can't do my work!" Understanding the connectivity issues is as important as understanding the issues regarding system availability. In the following sections, I troubleshoot connectivity problems, first by looking at the remote system (which appears down since it is unreachable) and then by working into the local system.
When a connectivity problem occurs, most often the first assumption is that the remote system is down. Is it really down? Can you reach it with a ping? ping is a TCP/IP-based command that sends a signal to a remote system and expects a reply. It is named after the term used for sending sonar signals. Even if you cannot ping it, that does not mean that the problem lies within the remote system.
Assume that you can physically reach the system and confirm that it is up and running. A good first test is to try to Telnet to the machine from itself. This approach may seem confusing or recursive, but because a system that can serve Telnet commands must be able to multitask, it should be able to assume both the role of the client and the server. If you are in front of a system that is unreachable from other systems, for example, and its name is vittle, type telnet vittle and try to establish a Telnet session without moving over your LAN.
If you cannot connect, make sure that you are using the right hostname by executing a command such as hostname on the local system. Make note of the system's IP address. Make sure that the process in.telnetd is running by looking at the process table. Try to rlogin into the system instead of Telnet. One of these commands should give you a connection. If you can rlogin to the system, try restarting the Telnet daemon. Also, try to bring down and then back up the network interface by using the ifconfig command. If all these efforts fail, try to reboot the system. These symptoms probably indicate a fundamental problem with this remote system at the operating system level.
If, upon visiting the remote system, you find that all is well, look at the network running between the two systems. Can you Telnet to the system from a third system that is independent of the other two? If not, try to Telnet to the IP address instead of the hostname. In other words, if system vittle has the IP address 10.23.5.30, instead of typing telnet vittle, try typing telnet 10.23.5.30 and see what happens. If Telnetting via IP address is successful, look at how your systems translate hostnames into IP addresses. This translation is typically performed through either a local file named /etc/hosts, the Network Information Service (NIS) protocols, or Domain Name Services (DNSs). Make sure that whichever of these your LAN uses, it resolves the names correctly.
Try to Telnet to another system on the same network segment. Try to Telnet to another system on a different network segment. Are the problems limited to the one system in question, a single network segment, or is it LAN-wide? Check both the network segment on which the local system resides and the segment of the remote client in the same manner. If you can confine the problem to occurring over an entire network segment and duplicate the problem when two entirely different systems are involved, you should probably get a network specialist involved.
Furthermore, if the problem is poor response time, determine if it is isolated to communication between the two systems or if poor performance occurs across a larger collection of systems. Examine the process that is trying to run over the network through the Telnet session. Your network is only as fast as the slowest device that your data is passing through. Even if a system is powerful, if it is receiving data over an Ethernet interface that yields a throughput of 10 megabits/second, the system can respond only as fast as it can receive data on which to operate. Be aware of these network limitations and where bottlenecks are likely to occur on your LAN data.
I want to focus on Ethernet-based networks in our discussion about security. Most LANs in industry are built with at least some Ethernet networks, so the issues surrounding these networks are pertinent to almost all readers. Ethernet, as a network protocol, differs dramatically from Token Ring (often considered the second most popular network protocol) in one significant way: Ethernet is a broadcast-based protocol. This means that data packets are not sent in an exclusive channel from host A to host B. Instead, when system A wants to pass a data packet to system B, it broadcasts the data packet over the network. Every host on the LAN gets the packet addressed to system B, and all systems disregard the packet, because it's not addressed to them, except for system B, which receives the packet. System B then passes the packet up the TCP/IP stack, which looks at the port number and so on and then processes the data. Because every computer receives the packet, the data passes through every wire in the LAN, as illustrated in Figure 29.3. With all this data flowing, you should begin to understand why physically securing your network is so important. Can someone actually list data off the wire? Would the data even be readable? Yes and Yes. A common tool of network specialists is even engineered to "sniff" out such data. Not surprisingly, this tool is called a sniffer.
Figure 29.3: Data broadcast over Ethernet.
Think of a sniffer as a nosy networked computer. Most systems ignore any data packet that is not specifically addressed to them. A sniffer is a computer with a network interface configured to keep and store every data packet passing through the wire for later analysis. A network specialist may use this type of tool to determine what is causing excessive network traffic or to collect some statistical data to get a baseline on a network. A baseline is a profile of what standard network activity looks like on a specific LAN.
Consider a Telnet session. When you Telnet to a system, a connection is opened between the two systems. The remote system asks for your login and password. In other words, it sends a packet to your system, addressed to port number 23 (the Telnet port) with the text string Password: in it. You respond by typing in your password. Even though you do not see it when you type it, that password is passed across the network in data packets addressed to port number 23 on the remote system. A malicious person with a sniffer can simply plug the sniffer into your network, instruct it to listen specifically for any data targeted to port number 23 on any system, and in time can probably lift more than a few users' login names and passwords off your LAN.
The creative technologist can configure almost any system to behave like a sniffer, although doing so is very difficult. Ironically, rlogin, with its trusted host issues, gets around this problem. Because passwords are not necessary, they are never typed in and never sent out on the wire. Remember, though, that trusted hosts open up another Pandora's box of issues. With rlogin, if one system is compromised, so are all those that trust it. For this reason, in the most secure networks, the actual wires and network ports are physically secure, perhaps even sealed in conduit tubes.
Another solution for securing data that is gaining popularity is to encrypt all data passed over the wire. In other words, system A encrypts the data and broadcasts it scrambled. System B accepts the data, decodes it, and then uses it. Of course, the flip side is that because every piece of data transmitted must be encrypted on the way out and decrypted on the way in, data moves slower. You also may get complaints about shoddy network performance.
The risks that apply to passwords transmitted across the network apply to any ASCII data transmitted over the network. If payroll data is sent unencrypted from one system to another, this data too is broadcast with the possibility of getting picked up by a sniffer.
One way to protect portions of your LAN is to implement packet filtering. Packet filtering is a standard feature with most routers. Through packet filtering, a user can tell a router to permit or forbid data to pass through it onto a portion of the LAN by either IP address or by TCP/IP port number. With packet filtering, for example, you can tell a router to forbid any data addressed to port 23 to pass through a router, thereby disabling Telnet between two systems on different sides of the routers. You also can then enable port 23 only on a system with the IP address w.x.y.z, thereby permitting only Telnet access through the router from that one system. This is an example of basic and simple network security. The method of configuring packet filtering may vary from router model to router model, so you should consult the user's guide for your router for specific information on how to configure it.
I want to discuss briefly the process table from the standpoint of security to underscore the amount of data visible to a user looking at the process table and use this section as a segue to a discussion of common sense and security.
Assume that you write a program that performs a task and requires a password. Perhaps it is a password of another account on the system, or maybe it is a password that is used by a specific application. Being a clever programmer, you write the program so that it takes a password as an input argument and then uses whatever is typed on the command line as the password. Assume that the program is named special_program and the password is booboo. To run this program, you can type special_program booboo. Listing 29.8 shows part of the output of the ps -aux command while this program is running.
Listing 29.8. A look at the program special_program
from ps -aux.
USR PID %CPU %MEM SZ TT STAT START TIME COMMAND root 1 0.0 0.1 52 ? S May 1 0:36 /sbin/init - root 2 0.0 0.0 0 ? D May 1 0:06 pagedaemon root 159 0.0 0.0 108 ? IW May 1 0:31 cron . . . root 159 0.0 0.0 108 ? IW May 1 0:31 cron anna 26479 0.0 0.0 40 p0 IW 11:36 0:31 telnet varmint anna 25926 0.0 0.0 220 ? IW 09:53 0:06 special_program booboo
Remember that any user can execute the ps -aux command. Any user, therefore, can see that the password passed through the program is booboo. You are obviously compromising the account's security by basically publishing the password in the process table. (Not to mention opening yourself to personal embarrassment with the password booboo!)
This example underscores the need for system administrators and programmers to expand their concepts of security and heighten their awareness of the many places that may seem harmless and reasonable but could be substantial breaches of security. You could do everything right technically and still have a potential disaster on your hands. At this point, you move away from the technical issues and more to the commonsense issues.
At one time, a potential hacker trying to guess passwords could log into a system via a modem, try to guess a password, fail, get disconnected, and try again, each attempt necessitating another phone call. Today, with the rise of the Internet and the greater implementation of TCP/IP over it, a hacker can repeatedly Telnet into a system and guess passwords without having to redial into a system via a phone modem. This means that today a hacker can move faster, guess more passwords, and have a better chance of finding weaknesses in your LAN than in previous times. This example further underscores the need to set strict rules regarding passwords and security in your LAN. Before you even worry about a hacker sniffing passwords out of your network traffic, worry about the dreaded account named guest with a password guest. Accounts like this (with the same password and login names) are called "joe" accounts-any old Joe can guess the password!-and are probably the first place that a hacker will look to break into your system.
Always practice the following commonsense recommendations:
Telnet is an often-used and powerful tool. As with most powerful tools, understanding its limitations is as important as understanding its benefits. Telnet and similar remote access protocols force you, as a system or network administrator, to look beyond the physical workstation when you consider the user community. This is true from both a user standpoint and a resource-utilization standpoint. Retaining this broader vision is important when it comes to making decisions regarding remote access. Do you permit unlimited access? Do you enforce different passwords on different systems? How much protection do the physical lines your network is composed of need? The answers are important, but asking the right questions is absolutely essential.