17.1.1 The /etc/services File

The /etc/services file is a relational database file. Each line of the /etc/services file consists of a service name, a network port number, a protocol name, and a list of aliases. A rather extensive list of Internet services, including their uses on UNIX systems, their security implications, and our recommendations as to whether or not you should run them, appears in Appendix G, Table of IP Services .

The /etc/services file is referenced by both Internet client programs and servers. The information in the /etc/services file comes from Internet RFC s[1] and other sources. Some of the services listed in the /etc/services file are no longer in widespread use; nevertheless, their names still appear in the file to prevent the accidental reassignment of their ports in the event that the services are still used somewhere on the global network.

[1] RFC stands for Request For Comment. The RFCs describe many of the actual standards, proposed standards, and operational characteristics of the Internet. There are many online sources for obtaining the RFCs.

The following is an excerpt from the /etc/services file that specifies the Telnet, SMTP , and Network Time Protocol ( NTP ) services:

# /etc/services 
# 
telnet 23 /tcp 
smtp   25 /tcp mail 
time   37 /udp timeserver
...

UNIX servers should determine their port numbers by looking up each port in the /etc/services file using the UNIX system call getservicebyname(). The /etc/services file can be supplemented or replaced by distributed database systems such as NIS , NIS +, Netinfo, or DCE Most of these systems patch the system's getservicebyname() system call, so that they are transparent to the application.

Some programmers bypass this system call and simply hard-code the service number into their programs. Thus, if you make a change to a program's port number in the /etc/services file, the server may or may not change the port to which it is listening. This can result in significant problems if a change is necessary, although well-known services seldom change their ports.

17.1.2 Starting the Servers

There are fundamentally two kinds of UNIX servers:

• Servers that are always running. These servers are started automatically from the /etc/rc* files when the operating system starts up.[2] Servers started at boot time are usually the servers that should provide rapid responses to user requests, must handle many network requests from a single server process, or both. Servers in this category include nfsd (Network Filesystem daemon) and sendmail .

  [2] On System V-derived operating systems, such as Solaris 2.x, these servers are usually started by an entry in a file located inside the /etc/rc2.d/ directory.

• Servers that are run only when needed. These servers are usually started from inetd , the UNIX "Internet" daemon. inetd is a flexible program that can listen to dozens of Internet ports and automatically start the appropriate daemon as needed. Servers started by inetd include popper (Post Office Protocol daemon) and fingerd (the finger daemon).

Servers that are always running are usually started by a command in the /etc/rc* files. For example, the lines in the /etc/rc file that start up the Simple Mail Transfer Protocol ( SMTP ) server looks like this:

if [ -f /usr/lib/sendmail -a -f /etc/sendmail/sendmail.cf ]; then  
/usr/lib/sendmail -bd -q1h && (echo -n ' sendmail') > /dev/console 
fi

This example checks for the existence of /usr/lib/sendmail and the program's control file, /etc/sendmail/sendmail.cf. If the two files exist, /etc/rc runs the sendmail program and prints the word " sendmail " on the system console. After the program is running, sendmail will bind to TCP/IP port number 25 and listen for connections.[3]

[3] The option -bd makes the sendmail program "be a daemon" while the option -q1h causes the program to process the mail queue every hour.

Each time the sendmail program receives a connection, it uses the fork () system call to create a new process to handle that connection. The original sendmail process then continues listening for new connections.

17.1.3 The /etc/inetd Program

The first version of UNIX to support the Internet, BSD 4.2, set a different server program running for every network service.[4] As the number of services grew in the mid-1980s, UNIX systems started having more and more server programs sleeping in the background, waiting for network connections. Although the servers were sleeping, they nevertheless consumed valuable system resources such as process table entries and swap space. Eventually, a single program called /etc/inetd (the Internet daemon) was developed, which listened on many network ports at a time and ran the appropriate TCP -based or UDP -based server on demand when a connection was received.

[4] BSD 4.1a was an early test release of UNIX with TCP/IP support. BSD 4.2, released in September 1983, was the first non-test release with TCP/IP support.

inetd is run at boot time as part of the start-up procedure. When it starts execution, it examines the contents of the /etc/inetd.conf file to determine which network services it is supposed to manage. inetd uses the bind () call to attach itself to many network ports and then uses the select () call to cause notification when a connection is made on any of the ports.

A sample inetd.conf file might look like this:

# @(#)inetd.conf 1.1 87/08/12 3.2/4.3NFSSRC 
# 
# Internet server configuration database 
# 
ftp      stream tcp nowait root    /usr/etc/ftpd ftpd 
telnet   stream tcp nowait root    /usr/etc/telnetd telnetd 
shell    stream tcp nowait root    /usr/etc/rshd rshd 
login    stream tcp nowait root    /usr/etc/rlogind rlogind 
exec     stream tcp nowait root    /usr/etc/rexecd rexecd 
uucp     stream tcp nowait uucp    /usr/etc/uucpd uucpd 
finger   stream tcp nowait nobody  /usr/etc/fingerd fingerd 
tftp     dgram  udp wait   nobody  /usr/etc/tftpd tftpd 
comsat   dgram  udp wait   root    /usr/etc/comsat comsat 
talk     dgram  udp wait   root    /usr/etc/talkd talkd 
ntalk    dgram  udp wait   root    /usr/etc/ntalkd ntalkd 
echo     stream tcp nowait root    internal 
discard  stream tcp nowait root    internal 
chargen  stream tcp nowait root    internal 
daytime  stream tcp nowait root    internal 
time     stream tcp nowait root    internal 
echo     dgram  udp wait   root    internal 
discard  dgram  udp wait   root    internal 
chargen  dgram  udp wait   root    internal 
daytime  dgram  udp wait   root    internal 
time     dgram  udp wait   root    internal

Each line contains at least six fields, separated by spaces or tabs:

Service name

The service name that appears in the /etc/services file. inetd uses this name to determine which port number it should listen to.

Socket type

Whether the service expects to communicate via a stream or on a datagram basis.

Protocol type

Whether the service expects to use TCP - or UDP -based communications. TCP is used with stream sockets, while UDP is used with dgram , or datagrams.

Wait/nowait

If the entry is "wait," the server is expected to process all subsequent connections received on the socket. If "nowait" is specified, inetd will fork () and exec () a new server process for each additional datagram or connection request received. Most UDP services are wait, while most TCP services are nowait, although this is not a firm rule. Although some man pages indicate that this field is only used with datagram sockets, the field is actually interpreted for all services.

User

Specifies the UID that the server process is to be run as. This can be root ( UID 0), daemon ( UID 1), nobody (often UID -2 or 65534), or an actual user of your system. This field allows server processes to be run with fewer permissions than root , to minimize the damage that could be done if a security hole is discovered in a server program.

Command name and arguments

The remaining arguments specify the command name to execute and the arguments that the command is passed, starting with argv[0] .

Some services, like echo , time , and discard , are listed as "internal." These services are fairly trivial, and they are handled internally by inetd rather than requiring a special program to be run. Although these services are useful for testing, they can also be used for denial of service attacks. You should disable them.

You should routinely check the entries in the /etc/inetd.conf file and verify that you understand why each of the services in the file is being offered to the Internet. Sometimes, when attackers break into systems, they create new services to make future break-ins easier. If you cannot explain why a service is being offered at your site, you may wish to disable it until you know what purpose it serves.