UNIX System Administration Handbook - Evi Nemeth [491]
The fifth column gives the username under which the daemon should run. If you do not trust a particular program or you know that it has security problems, you can run it as someone other than root to reduce your exposure. Of course, this technique works only for daemons that do not require rootly powers. In the example above, fingerd runs as the user “guest.”
The remaining fields give the fully qualified pathname of the daemon and its command-line arguments. The first argument should always be the short name of the program. This requirement is not a peculiarity of inetd but a traditional UNIX convention that is normally hidden by the shell.
The services file
After adding a new service to inetd.conf, you may also need to make an entry for it in the services file. This file is usually found in /etc. It is used by several standard library routines that map between service names and port numbers. For example, when you type the command
% telnet anchor smtp
telnet looks up the port number for the “smtp” service in the services file. Most systems ship with all the common services already configured; you need only edit the services file if you add something new.
The services file is used only for bona fide TCP/IP services; similar information for RPC services is stored in a separate configuration file, usually /etc/rpc.
Here are some selected lines from a services file (the original is about 70 lines long):
tcpmux 1/tcp # TCP port multiplexer
echo 7/tcp
echo 7/udp
...
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
name 42/tcp # IEN 116
whois 43/tcp nicname
...
The format of a line is
name port/proto aliases # comment
Services are generally listed in numerical order, although this order is not required. name is the symbolic name of the service (the name you use in the inetd.conf file). The port is the port number at which the service normally listens; if the service is managed by inetd, it is the port that inetd will listen on.3
The proto indicates the protocol used by the service; in practice, it is always tcp or udp. If a service can use either UDP or TCP, a line for each must be included (as with the time service above). The alias field contains additional names for the service (for example, whois can also be looked up as nicname).
Restarting inetd
Changes to /etc/inetd.conf do not take effect until you tell inetd to reread it, which you do by sending inetd a hangup signal. After signalling, wait a minute and then check the log files for error messages related to your changes (inetd logs errors to syslog under the “daemon” facility). Test out any new services you have added to be sure they work correctly.
See Chapter 11 for more information about syslog.
Securing inetd
Because inetd is responsible for managing many common network-based services, it plays an important role in securing your system. It’s important to verify that only services you need and trust have been enabled in inetd.conf. On a new system, you will almost certainly need to modify inetd.conf to disable services that are unnecessary or undesirable in your environment. A good rule of thumb is to enable only the services that you absolutely need and turn everything else off.
Even then, it’s a good idea to supplement inetd with Wietse Venema’s TCP wrappers package, which logs all connection attempts and restricts access to daemons, depending on who is attempting to connect to them. The package description starts on page 666.
HP-UX comes with a version of inetd that has TCP-wrapper-like features built in. It checks the file /var/adm/inetd.sec to determine who’s allowed to connect to which services. If started with the -l flag, it also performs connection logging. For instructions on configuring HP’s security features, see page 666.