20.1. Objective 1: Configure and Manage inetd, xinetd, and Related Services 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. When an inbound request is received, it is handed off to the actual daemon for processing. With this scheme, the real daemons are still used as before, but they run only when needed and are started by inetd, freeing resources for other tasks. In addition, using inetd greatly simplifies the code of the various daemons. Instead of listening for connections and everything else required to be a proper network daemon, daemons run by inetd need to read only from stdin and write only to stdout. Many Linux distributions have started shipping xinetd as a replacement for inetd. The following information applies to only the original inetd. xinetd configuration is significantly different. Both are discussed in this chapter. For more information on xinetd, see http://www.xinetd.org. 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. The daemon name is actually the first argument, or argv[0] from a programming point of view. 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.2. TCP Wrappers with inetd Running services from inetd 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. tcpd can be used to control access to inetd-managed services by IP address or by domain name. 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 hosts.allow file and provide a blanket denial in the hosts.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 services 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.3. Starting and Stopping inetd 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 meanstypically through the runlevel system and the series of scripts and links in /etc/rc.d. See Chapter 5 for details on starting and stopping services such as Apache (httpd). | On the Exam | 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. |
20.1.4. xinetd Configuration The format of inetd.conf allows for only a specific number of options. Since xinetd offers many more options for services than inetd, it requires a different configuration file. Fortunately, the format of xinetd.conf (as shown in Example 20-2) is much more flexible, allowing you to mix and match a large number of options. Example 20-2. Sample /etc/xinetd.conf service discard { socket_type = stream protocol = tcp wait = no user = root type = INTERNAL id = discard-stream } service discard { socket_type = dgram protocol = udp wait = yes user = root type = INTERNAL id = discard-dgram } service telnet { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = yes }
|
This example turns on the discard service (both TCP and UDP varieties). It also includes an entry for a telnet daemon, although that service is disabled. 20.1.4.1. Frequently used xinetd.conf options These options can all be used in a service definition in xinetd.conf:
bind
interface This option can be used to listen on a specific IP address. For example, to allow connections to localhost only, use the following: bind = 127.0.0.1
disable
enabled These options can be used to disable a service. Either of the following will disable a service: disable = yes enabled = no
Setting disable = no or enabled = yes is not required to enable a service.
id This option can be used to set a unique ID for a service. By default, the ID is set to the service name, but in cases in which there is more than one entry for a service (for example, when there are entries for TCP and UDP versions of a service), unique IDs must be set for each service.
instances This option can be used to limit the number of simultaneous connections to a service. By default, the number of connections is not limited. This can also be forced by specifying instances = UNLIMITED.
log_on_failure
log_on_success These options can be used to control the information that is logged for failed or successful connections, respectively. For example, to specify that the result of an ident query be logged for a failed connection (due to whatever access controls are in place for a service) in addition to whatever information is logged by default, you could add the following to a service definition: log_on_failure += USERID
For both options, HOST and USERID can be specified. For log_on_failure, ATTEMPT can also be specified, but that is implied by either of the other items. For log_on_success, DURATION (the amount of time the service was connected), EXIT (notes the exit value and any signals received), PID (process ID of the program run for this connection), and trAFFIC (the amount of data transferred in redirected connections) can be specified. You can specify a list of these items, separated by spaces.
no_access
only_from These two options can be used to limit access to a service. IP addresses can be specified in CIDR notation (such as 192.168.1.0/24). Trailing zeros are considered wildcards, so the following are equivalent: only_from = 192.168.1.0 only_from = 192.168.1.0/24
Hostnames, domain names (in the form .example.com), and network names (as specified in /etc/networks) can also be specified. If both of these options are specified, the rule that matches an address most closely applies. For example, the following would limit connections to any address in 192.168.1.0/24 except 192.168.1.42: only_from = 192.168.1.0/24 no_access = 192.168.1.42
By default, connections are allowed from anywhere.
per_source This option limits the number of connections for any one source address. This keeps one user from using all available connections when using the instances option.
port This option allows you to provide a port number when you configure a service not listed in /etc/services. Normally it is not necessary.
protocol This option is used to specify the protocol for a given service. This could be any of the protocols listed in /etc/protocols, but it will usually be either tcp or udp. The default is the default protocol for the service (as specified in /etc/services).
redirect This option tells xinetd to redirect connections to this port to another host and port. This can be used only for TCP services. The following example would redirect connections to the local system's port 443 (https) to port 22 on 10.0.0.2: service https { protocol = tcp redirect = 10.0.0.2 22 user = root wait = no }
server This option is used to specify the program to run for a service. For example, the imap service might run imapd as follows: server = /usr/sbin/imapd
server_args This option is used to pass options to the server (previously specified with the server option). For example, using rsync as a daemon requires passing the --daemon option. server = /usr/bin/rsync server_args = --daemon
user This option is used to specify the user that the server program runs as. The username must be valid (listed in /etc/passwd).
wait This option is used to specify whether xinetd should wait for a connection to end before accepting another. Generally, this will be set to yes for udp services and no for tcp services. There are many more options. For a full list, see the xinetd.conf manpage. 20.1.4.2. Modular configuration xinetd can be configured to scan a directory for configuration files. Some distributions use this feature to break xinetd.conf into separate files for each service. Here's an example xinetd.conf implementing this: # # Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d
The includedir /etc/xinetd.d directive tells xinetd to look at every file in /etc/xinetd.d for configuration . xinetd skips filenames containing a dot (.) or ending with a tilde (~) as a crude but effective way of avoiding backup files. Each of these configuration files could include a service definition for a single service, which greatly simplifies packaging. For example, a distribution might include the following /etc/xinetd.d/rsync with its rsync package to make it simple to turn on the rsync daemon: service rsync { disable = yes socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon log_on_failure += USERID }
The system administrator could then enable the rsync daemon by deleting (or commenting out) the disable = yes line in that file. (On distributions that include the chkconfig command, chkconfig rsync on would have the same effect.) |
