20.1 Objective 1: Configure and
Manage inetd and Related Services
Most network
services execute as software daemons,
which "listen" to a specific port for inbound requests from
client software on the outside. (See Section
19.1 for a discussion on ports.) For example, the Telnet
daemon, telnetd,
listens on port 23 for inbound requests from Telnet clients.
Each such request is handled by the daemon, which starts the
login process for the client. If a single server were to offer
many such services, many of the telnetd daemons would be running at
any one time to handle multiple inbound Telnet requests.
In order to reduce the number of daemons
necessary to service requests, the Internet superdaemon, or inetd, was created. Instead of
running individual daemons for each service, inetd runs as a single service
listening to all of the desired port numbers (23 for telnet, 21 for ftp, etc.). When an inbound request
is received, it is handed off to the actual daemon for
processing. With this scheme, the host daemons are still used
as before, but they run only when needed and are started by
inetd, freeing resources for
other tasks.
This scheme also offers another convenience.
Instead of launching the target daemons directly, inetd is usually configured to use
the TCP wrappers access control facility. TCP wrappers, or
tcpd , allows the administrator to define
restrictions on the origin of inbound requests. TCP wrappers
is described fully in Section
21.1.
inetd is well
suited for services requested on a relatively infrequent
basis, such as telnet and ftp. However, using inetd on services such as Apache
would significantly impact the performance of a heavily used
server under constant load. In such cases, it is common to
simply configure the web server to handle its own connections.
20.1.1 The inetd Configuration
File
inetd is usually
started during system initialization and continues to run
indefinitely (or until the process is stopped). When started
(and later in response to signal SIGHUP), inetd reads its configuration file
from /etc/inetd.conf, which
is nothing more than a plain text file that defines the
services managed by inetd.
(Commented lines begin with #.) Example
20-1 shows portions of an inetd.conf, with lines wrapped to fit the page
(your inetd.conf will be different and should be
configured with your security requirements in mind; more on
this later).
Example 20-1. Sample
inetd.conf File # /etc/inetd.conf
# Internet server configuration database
# See inetd(8) for further information.
#
<service_name> <socket_type> <proto> <flags> <user> <server_path> <args>
#
ftp stream tcp nowait root /user/sbin/tcpd /user/sbin/in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
#
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
#
finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in-fingerd
ident stream tcp nowait nobody /usr/sbin/identd identd -I
#
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
Each noncommented
line in inetd.conf must contain each of the following
fields:
- service_name
-
This is the name of a service as defined in
/etc/services.
- socket_type
-
This entry specifies one of a few types of
communications the service will use. It's usually
stream or dgram.
- proto
-
This field specifies the service's protocol
from among those in /etc/protocols. For most
services, it will be either tcp or udp,
which correspond to the stream and dgram
socket types.
- flags
-
The wait/nowait
(.max) flag is used only for datagram services,
where it helps to control the handling of inbound requests
and is typically set to wait. It should be set to
nowait for others. You can limit the number of
server instances spawned by inetd within any 60-second interval
by appending a dot and the maximum number (.max).
For example, to limit the service to 20 instances, use
.20 after the nowait flag: nowait.20
The default maximum is 40 instances
(.40).
- user[.group]
-
This entry specifies the username (and
optionally the group name) under which the service should
execute, allowing them to be run with fewer permissions than
root. A typical entry is the user nobody.
- server_ path
-
This field is the full path to the
executable daemon of the server program. When TCP wrappers
is used, this entry specifies tcpd, as shown in Example
20-1.
- args
-
This last entry on the line may consist of
multiple fields. It contains the name of the server daemon
and all arguments that are to be passed to it.
In many Linux installations, a majority of
the lines in inetd.conf are commented out to increase
security. The fewer services a system offers, the more likely
it is to stand up to an attack. You should review your file to
be certain that only necessary services are offered.
20.1.1.1 TCP wrappers with
inetd
If you have a need to control access to inetd-managed services by IP address
or by domain name, you may wish to configure TCP wrappers. For
each inbound connection to a service protected by TCP
wrappers, tcpd consults two
files that define access:
- /etc/hosts.allow
-
If a rule in this
file is met, access to the service is allowed.
- /etc/hosts.deny
-
If a rule in this
file is met, access to the service is denied.
Rules in these files can be constructed to
match all services or alternatively to match specific
services. If no match occurs in the two files, access to the
service (or services) is allowed. It is common to specify
particular rules in the .allow file and
provide a blanket denial in the .deny file, thereby
limiting access to clients you specifically allow.
The language in the control files consists of
a service list, followed by a colon, followed by a list of
hosts. Hosts may be specified by name or by IP address. For
example, to deny access to all service except inbound
ftp from the local domain, these two simple files
could be used:
- hosts.allow
-
This entry allows FTP access to clients in
the local domain: ftp: LOCAL
- hosts.deny
-
This entry denies access to all services
from all clients: ALL: ALL
The hosts.deny file is consulted after
hosts.allow, enabling the administrator to define
specific allow rules that will be matched prior to deny rules
or a blanket denial.
20.1.2 Starting and Stopping
Services
If inetd is not running, all of the
services it manages are disabled. Likewise, if inetd is reconfigured, any changes to
individual managed services take effect at the same time. To
cause inetd to reread its
configuration file, simply send it SIGHUP: $ killall -HUP inetd
All inetd
services that are commented out or missing from
/etc/inetd.conf will be disabled. However, a number of
other services on Linux systems are managed through other
means -- typically through the runlevel system and the series
of scripts and links in /etc/rc.d. See Section
5.2 for details on starting and stopping services such as
Apache (httpd).
|
You must be generally familiar with the
content and function of inetd.conf,
hosts.allow, and hosts.deny. Memorizing
configuration details is not necessary, but be prepared
for questions on available services and the effect of
TCP wrappers rules in the hosts.allow and
hosts.deny files. Be sure you understand what
happens to services that are commented out of
inetd.conf, and that inetd must be signaled to
reread the control file after any changes. | 
|