|
|
| Previous | Table of Contents | Next |
The inetd.conf file is used to provide the information to the inetd command. As discussed later in the chapter, inetd is the Internet super-server. It listens on a specified TCP/IP port and starts the appropriate command when a connection is requested on that port. This saves system resources by only starting the daemons when they are needed.
The following illustrates an inetd.conf file from an SCO system, along with the file format.
# ftp stream tcp nowait NOLUID /etc/ftpd -l -v ftpd telnet stream tcp nowait NOLUID /etc/telnetd telnetd shell stream tcp nowait NOLUID /etc/rshd rshd login stream tcp nowait NOLUID /etc/rlogind rlogind exec stream tcp nowait NOLUID /etc/rexecd rexecd # finger stream tcp nowait NOUSER /etc/fingerd fingerd
The SCO inetd.conf file differs from the format of most systems because of the C2 security components found in the SCO Unix operating system. Specifically, SCO requires the Login UID, or LUID, to be set for each user who accesses the system. Because setting the LUID should not be done until a user actually logs in, the LUID must not be set when the daemon starts up. This is accomplished by using the NOLUID parameter in the file.
The following illustrates the standard inetd.conf file that is found on most other Unix systems.
# ftp stream tcp nowait root /usr/etc/in.ftpd in.ftpd telnet stream tcp nowait root /usr/etc/in.telentd in.telentd shell stream tcp nowait root /usr/etc/in.rshd in.rshd login stream tcp nowait root /usr/etc/in.rlogind in.rlogind exec stream tcp nowait root /usr/etc/in.rexecd in.rexecd # finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd
Two files can have a significant impact on the security of your system. These files are the /etc/hosts.equiv and the .rhosts files.
The /etc/hosts.equiv file contains a list of trusted hosts. This file is used by the r* commands rlogin, rcp, rcmd, and rsh, and is discussed in detail later in this chapter. The format of this file consists of a list of machine names, one per line, as illustrated here:
localhost oreo wabbit.widgets.ca chare chelsea widgets pirate
Tip: It’s a good habit to use a fully qualified name, but if the domain is omitted, TCP/IP adds it to the hostname when validating the remote system.
The .rhosts file that is used in the user’s HOME directory accomplishes a similar purpose to /etc/hosts.equiv. The file format is the same, with one notable exception. The hosts.equiv file is used to provide equivalence between hosts, while the .rhosts file is used to provide equivalence between users. The .rhosts file is appended to the information found in /etc/hosts.equiv when checking for equivalence.
Note: The hosts.equiv file is not used for the root user. The only file processed in this case is /.rhosts.
Host Equivalency, or Trusted Host Access, is configured by the system administrator by using the file /etc/hosts.equiv. This file consists of hostnames, one per line.
Tip: It is a good idea to document in the file who the network administrator is, as comments can be included by using the comment symbol (#).
Each entry in the hosts.equiv file is trusted. That is, users on the named machine can access their equivalent accounts on this machine without a password. This is not applicable for root, however, as will be explained later. Figure 1.5 will be used in the discussion of user equivalency.
)
Figure 1.5 A sample network
The two machines shown in figure 1.5, oreo and wabbit, both have a user named chare. If the user chare currently is logged into wabbit, and issues the command
$ rlogin oreo
with host equivalency established, then chare will be logged into oreo without being asked for his password. If host equivalency is not there, chare will be asked for his password on the remote machine.
The following must be considered with /etc/hosts.equiv:
There is a second format for the hosts.equiv file, known as .rhosts, which was shown previously. This format lists a system name and a user name. With the addition of the user name, the user is allowed to log in with any user name found in /etc/passwd.
User equivalence is a mechanism in which the same user is known to all of the machines in the network. This makes the network administrator’s job easier in the long run. It should be considered absolutely necessary for environments where NFS is used or is planned.
To configure user equivalence, the user creates a file in his home directory called .rhosts. This file must be writeable only by the owner of the file. If it is not, then the file is ignored for validation purposes. As with the hosts.equiv file, this file contains a system name per line, but generally also includes the name of the user who is being equivalenced.
Because of the varying implementations of TCP/IP that are available, a wide range of daemons can comprise the system. As many as possible are listed here along with a brief explanation of what they do. If they are operating system specific, the operating system version information also is included.
Many of the TCP/IP daemons are named with the name of the service they provide followed by the letter “d,” as in bootpd. This convention is used to indicate that this command is a daemon.
The slink daemon provides the necessary components to link the STREAMS modules required for streams TCP/IP. When the system is started, a configuration file, typically /etc/strcf, is processed, thus establishing the links between STREAMS modules for each of the network devices present in the system.
This daemon is found only on versions of Unix that use STREAMS-based TCP/IP, such as most System V derivatives.
The ldsocket command initializes the System V STREAMS TCP/IP Berkeley networking compatibility interface. This daemon also is found only on System V-based implementations of TCP/IP, as the BSD-based versions do not use a STREAMS-based implementation. As the ldsocket program is loaded, a file, generally /etc/sockcf, is processed, and the streams modules are loaded and configured to provide the socket style interface.
| Previous | Table of Contents | Next |