|
|
| Previous | Table of Contents | Next |
In some sense, the prevention of sniffing by installing hardware barriers may be considered the last line of defense in a security system. When building medieval fortresses, the last line of defense was typically the most formidable but could only protect those who would be left inside after the outer defenses had been breached. In dealing with sniffing, the first line of defense is simply not to transmit anything sensitive on the network in the first place. The local hardware defenses may limit intrusion into the local systems. However, if authorized users may access those systems from remote locations, one must not transmit sensitive information over remote parts of the Internet lest the information be sniffed somewhere along the way. One extreme that preserves security is simply not to permit access from remote locations. Also, the most formidable defenses against inward directed attack do nothing to provide for the security of one leaving the area being protected. Legitimate Internet sessions initiated inside a network with those out side must also be protected.
The most glaring security hole beyond simple loss of confidentiality is the opportunity for a sniffer to gather passwords. The best way to deal with this problem is simply not to transmit cleartext passwords across the network. Simply transmitting an encrypted password that could be captured and replayed by a sniffer is also not acceptable. Several different methods are in use to provide this kind of protection:
The rlogin Family of Protocols
The rlogin protocol, originally used with Unix-to-Unix terminal sessions, uses end-to-end mutual trust to avoid the transmission of any form of password. The protocol requires that the server trust the client to “authenticate” the user. The user places a file on the server indicating what combinations of user name and hostname may connect to a particular account on machines using the server. The user may connect from these without presenting any further credentials such as a password. This file is called the rhosts file. For the original Unix server, the file name had to be preceded with a dot, “.rhosts,” but on non-Unix systems using this protocol, the file may have to have a different name to satisfy the constraints imposed for file names or different mechanisms used to store the information about what users are accepted on what trusted systems. The user must trust that the server is sufficiently secure, that no one else can alter the rhosts file and that no one else can read the rhosts file. The requirement that the rhosts file not be altered is obvious—if someone modified the rhosts file, he or she could connect to the account via the rlogin protocol without the permission of the legitimate user. The requirement that no one else can read the rhosts file is a bit more obscure, but learned from painful experience. If an attacker gains access to another account on the machine hosting the rlogin server, the attacker can read the rhosts file of a user and target the user for an indirect attack. In an indirect attack, the attacker attempts to gain access to an account listed in the rhosts file on another machine and use it to obtain access to the machine hosting the rlogin server.
Another file used by some servers for the rlogin protocol is called the host equivalence file, which is named “/etc/hosts.equiv” in the original Unix implementation. Any user of any host listed in the host equivalence file may access an account with the same username on the machine on which the host equivalence file exists without presenting a password. The use of a host equivalence file adds convenience for the user by relieving individual users from the need to create their own rhosts file. However, it opens up users to the risks of ARP spoofing and name server spoofing (both covered later in this chapter) without the implicit consent they give to that risk when creating their own rhosts file. System administrators are strongly urged not to use a host equivalence file because of those risks. Users without the network savvy to create an rhosts file are being put at risk from a threat they have no possibility of understanding.
Note: The rlogin protocol is used by a whole family of programs that use the same protocol. The family is collectively referred to as the r-commands. The family includes rlogin for terminal sessions, rsh for remote shell execution of command-line programs, and rcp for remote file copying. rcp is preferred over FTP for its security and ease of use. It is easier to use because it can transfer multiple files specified with the same syntax as the local file copying command.
The rlogin protocol remains vulnerable to ARP spoofing and DNS spoofing (discussed later in this chapter). It also does not completely protect a user who uses machines that he or she does not control. For example, when you start an rlogin terminal session from a client’s or col-league’s office, the client’s or colleague’s machine is not listed in your rhosts. In these cases, you must remember my password and have it transmitted across the network in plain sight of any sniffers that may be out there.
Note: The r-commands are not limited to Unix. DEC VMS has a variety of TCP/IP software available for it including both clients and servers for many of the programs in this family. Many TCP/IP software packages for the PC offer r-command clients. There is a networking suite for Windows NT that provides an rlogin server, enabling you to have access to the command line from a remote location without being logged into it locally. There are many freeware packages that provide a similar server for any PC with winsock.dll.
| Previous | Table of Contents | Next |