After successfully setting up IP and the resolver, you then must look at the services you want to provide over the network. This chapter covers the configuration of a few simple network applications, including the inetd server and the programs from the rlogin family. We’ll also deal briefly with the Remote Procedure Call interface, upon which services like the Network File System (NFS) and the Network Information System (NIS) are based. The configuration of NFS and NIS, however, is more complex and are described in separate chapters, as are electronic mail and network news.
Of course, we can’t cover all network applications in this book. If you want to install one that’s not discussed here, like talk, gopher, or http, please refer to the manual pages of the server for details.
Programs that provide application services via the network are called network daemons. A daemon is a program that opens a port, most commonly a well-known service port, and waits for incoming connections on it. If one occurs, the daemon creates a child process that accepts the connection, while the parent continues to listen for further requests. This mechanism works well, but has a few disadvantages; at least one instance of every possible service you wish to provide must be active in memory at all times. In addition, the software routines that do the listening and port handling must be replicated in every network daemon.
To overcome these inefficiencies, most Unix installations run a special network daemon, what you might consider a “super server.” This daemon creates sockets on behalf of a number of services and listens on all of them simultaneously. When an incoming connection is received on any of these sockets, the super server accepts the connection and spawns the server specified for this port, passing the socket across to the child to manage. The server then returns to listening.
The most common super server is called inetd,
the Internet Daemon. It is started at system boot time and takes the list
of services it is to manage from a startup file named
/etc/inetd.conf. In addition to those servers,
there are a number of trivial services performed by inetd
itself called internal services. They include
chargen, which simply generates a string of characters,
and daytime, which returns the system’s idea of the time
An entry in this file consists of a single line made up of the following fields:
Each of the fields is described in the following list:
Gives the service name. The service name has to be translated to a port
number by looking it up in the
/etc/services file. This
file will be described later in this chapter in the section Section 12.3.”
Specifies a socket type, either
(for connection-oriented protocols) or
dgram (for datagram protocols).
TCP-based services should therefore always use
stream, while UDP-based services
should always use
Names the transport protocol used by the service. This must be a valid
protocol name found in the
protocols file, explained
This option applies only to
sockets. It can be either
wait is specified,
inetd executes only one server for the specified
port at any time. Otherwise, it immediately continues to listen on
the port after executing the server.
This is useful for “single-threaded” servers that read all
incoming datagrams until no more arrive, and then exit. Most RPC servers
are of this type and should therefore specify
wait. The opposite type,
“multi-threaded” servers, allow an unlimited number of
instances to run concurrently. These servers should specify
stream sockets should always use
This is the login ID of the user who will own the process when it is executing. This will frequently be the root user, but some services may use different accounts. It is a very good idea to apply the principle of least privilege here, which states that you shouldn’t run a command under a privileged account if the program doesn’t require this for proper functioning. For example, the NNTP news server runs as news, while services that may pose a security risk (such as tftp or finger) are often run as nobody.
Gives the full pathname of the server program to be executed. Internal
services are marked by the keyword
This is the command line to be passed to the server. It starts with the name of the server to be executed and can include any arguments that need to be passed to it. If you are using the TCP wrapper, you specify the full pathname to the server here. If not, then you just specify the server name as you’d like it to appear in a process list. We’ll talk about the TCP wrapper shortly.
This field is empty for internal services.
inetd.conf file is shown in
Example 12.1. The finger
service is commented out so that it is not available. This is often done
for security reasons, because it can be used by attackers to obtain names
and other details of users on your system.
Example 12-1. A Sample /etc/inetd.conf File
# # inetd services ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless #login stream tcp nowait root /usr/sbin/rlogind in.rlogind #shell stream tcp nowait root /usr/sbin/rshd in.rshd #exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd internal services # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal
The tftp daemon is shown commented out as well.
tftp implements the Trivial File Transfer
Protocol (TFTP), which allows someone to transfer any
world-readable files from your system without password checking.
This is especially harmful with the
/etc/passwd file, and even more so when you don’t use shadow passwords.
TFTP is commonly used by diskless clients and Xterminals to download their code from a boot server. If you need to run tftpd for this reason, make sure to limit its scope to those directories from which clients will retrieve files; you will need to add those directory names to tftpd’s command line. This is shown in the second tftp line in the example.