Book HomeTCP/IP Network AdministrationSearch this book

5.3. The Internet Daemon

The internet daemon, inetd (pronounced "i net d"), is started at boot time from an initialization file such as /etc/rc2.d/S72inetsvc. When it is started, inetd reads its configuration from the /etc/inetd.conf file. This file contains the names of the services that inetd listens for and starts. You can add or delete services by making changes to the inetd.conf file.

An example of a file entry from a Solaris 8 system is:

ftp  stream  tcp6  nowait  root  /usr/sbin/in.ftpd   in.ftpd

The fields in the inetd.conf entry are, from left to right:

name

The name of a service, as listed in the /etc/services file. In the sample entry, the value in this field is ftp.

type

The type of data delivery service used, also called socket type. The commonly used socket types are:

stream

The stream delivery service provided by TCP, i.e., TCP byte stream.[49]

[49]Here the reference is to TCP/IP sockets and TCP streams, not to AT&T streams I/O or BSD socket I/O.

dgram

The packet (datagram) delivery service provided by UDP.

raw

Direct IP datagram service.

The sample shows that FTP uses a stream socket.

protocol

The name of a protocol, as given in the /etc/protocols file. Its value is usually either "tcp" or "udp". To indicate that a service can run over both IPv4 and IPv6, Solaris uses "tcp6" or "udp6" in this field. The FTP protocol uses TCP as its transport layer protocol, so the sample entry contains tcp6 in this field.

wait-status

The value for this field is either "wait" or "nowait." Generally, but not always, datagram type servers require "wait," and stream type servers allow "nowait." If the status is "wait," inetd must wait for the server to release the socket before it begins to listen for more requests on that socket. If the status is "nowait," inetd can immediately begin to listen for more connection requests on the socket. Servers with "nowait" status use sockets other than the connection request socket for processing; i.e., they use dynamically allocated sockets.

uid

The uid is the username under which the server runs. This can be any valid username, but it is normally root. There are several exceptions. For example, in the default Solaris 8 configuration, the finger service and the Sun Font Server (fs) both run as the user nobody for security reasons.

server

This is the full pathname of the server program started by inetd. Because our example is from a Solaris system, the path is /usr/sbin/in.ftpd. On your system the path may be different. It is more efficient for inetd to provide some small services directly than it is for inetd to start separate servers for these functions. For these small services, the value of the server field is the keyword "internal," which means that this service is an internal inetd service.

arguments

These are any command-line arguments that should be passed to the server program when it is invoked. This list always starts with argv[0] (the name of the program being executed). The program's manpage documents the valid command-line arguments for each program. In the example, only in.ftpd, the name of the program, is provided.

There are a few situations in which you need to modify the inetd.conf file. For example, you may wish to disable a service. The default configuration provides a full array of servers. Not all of them are required on every system, and for security reasons you may want to disable non-essential services on some computers. To disable a service, place a # at the beginning of its entry (which turns the line into a comment) and pass a hang-up signal to the inetd server. When inetd receives a hang-up signal, it re-reads the configuration file, and the new configuration takes effect immediately.

You may also need to add new services. We'll see some examples of that in later chapters. Let's look in detail at an example of restoring a service that has been previously disabled. We'll begin by looking at some entries and comments from the Solaris /etc/inetd.conf file:

# Tftp service is provided primarily for booting.  Most sites run this
# only on machines acting as "boot servers."
#
#tftp  dgram  udp6 wait   root   /usr/sbin/in.tftpd  in.tftpd -s /tftpboot
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers."  Many sites choose to disable
# some or all of these services to improve security.
#
finger stream tcp6 nowait nobody /usr/sbin/in.fingerd  in.fingerd 

This part of the file shows two TCP/IP services. One of these, tftp, is commented out. The TFTP protocol is a special version of FTP that allows file transfers without username/password verification. Because of this, it is a possible security hole and is often disabled in the inetd.conf file. The other is finger, which the comments suggest we might want to comment out.

As an example of modifying the inetd.conf file, we'll reconfigure the system to provide tftp service, which is sometimes necessary for supporting diskless devices. First, use your favorite editor to remove the comment (#) from the tftp entry in inetd.conf. (The example uses sed, everyone's favorite editor!) Then find out the process ID for inetd and pass it the SIGHUP signal. The following steps show how this is done:

# cd /etc 
# mv inetd.conf inetd.conf.org 
# cat inetd.conf.org | sed s/#tftp/tftp/ > inetd.conf 
# ps -acx | grep inetd 
  144 ?  I     0:12 inetd
# kill -HUP 144

In some situations, you may also need to modify the pathname of a server or the arguments passed to a particular server when it is invoked. For example, look again at the tftp entry. This line contains command-line arguments that are passed to the tftp server when it is started. The -s /tftpboot option addresses the most obvious tftp security hole. It prevents tftp users from retrieving files that are not located in the directory specified after the -s option. If you want to use another directory for tftp, you must change the inetd.conf file. The only command-line arguments passed to servers started by inetd are those defined in the inetd.conf file.



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.