Using xinetd

The xinetd (pronounced "zi-net-dee") super server can be thought of as a souped-up version of inetd. This server incorporates two major improvements that make it appealing:

• You can break the super server's configuration into multiple files, one for each server. This fact means that server packages from a distribution's maintainer can include xinetd configurations as ordinary files in their packages, which is a boon for distribution maintainers.

• The xinetd super server incorporates security features similar to those provided by TCP Wrappers. This fact is particularly important on systems with multiple network interfaces, because xinetd can listen for connections to a server on only one interface, improving security over the inetd/TCP Wrappers approach. Chapter 20 describes xinetd's security features in more detail.

The xinetd super server includes some less dramatic improvements over inetd, some of which are detailed shortly. The main xinetd configuration file is/etc/xinetd.conf. Both Mandrake and Red Hat use a minimal xinetd.conf file, though. This file sets only a few defaults and calls the files in /etc/xinetd.d to handle individual servers. A configuration that's equivalent to the one presented for an IMAP server in the previous section, "Using inetd," is as follows:

socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/imapd server_args =

disable = no

This entry contains all of the information present in the inetd configuration for the same server, except that it's split across multiple lines and each line is labeled. In practice, xinetd isn't very fussy about the order of these options, so you may see them in different orders. You may also see empty options, such as server_args in this example, omitted.

You can use assorted options to xinetd that aren't available in inetd. One of these options is disable, which takes a yes or no parameter. If this option is set to yes, xinetd ignores the server. You can use this feature to temporarily or permanently disable a server without uninstalling it. Many servers ship with a disable = yes entry so that you must explicitly enable the server before it will work. A few other options that may be of interest include:

group Instead of specifying the group under whose name a server is launched after a dot in the user specification, xinetd uses a separate group line to do this job.

instances You can limit the number of servers that xinetd will allow to be simultaneously active for a given service type. Specify a number or UNLIMITED (which is the default) if you don't want to use this feature. This feature can be useful to prevent problems caused by a server becoming too popular.

per_source This option works just like instances, except that it specifies a limit per source IP address. It can be useful in preventing problems from certain types of denial-of-service (DoS) attacks or to ensure that a system's server resources aren't monopolized by a handful of legitimate but heavy users.

nice You can specify a priority for a server's process by using the nice option, which works much like the nice command for launching programs, as described in Chapter 14, "Programs and Processes."

maxjoad To protect your system's performance from degrading too far because of CPU load imposed by servers, you can have xinetd refuse connections when the CPU load rises too high. For instance, maxjoad = 3.5 tells xinetd to refuse connections if the one-minute load average equals or exceeds 3.5.

log_on_success and log_on_failure Like inetd, xinetd logs information about connections. You can fine-tune what information the super server logs on successful and unsuccessful connection attempts with these options. For successful connections, you can specify PID (the server's process ID), HOST (the client's address), USERID (the remote username, if the client is running an auth/ident server), EXIT (an entry when the connection was terminated), and DURATION (the length of the connection when it's terminated). For unsuccessful connections, only HOST, USERID, and ATTEMPT (a mere notice that an unsuccessful connection attempt was made) are available. In either case, you can specify a list of options separated by spaces, or you can change the default by using plus (+) or minus (-) prefixes to the assignment operator to add or subtract the options from the default. For instance, log_on_success = HOST PID tells the system to log the client hostname and the server's PID. The line log_on_success += USERID tells xinetd to log the remote username in addition to whatever the default is.

log_type This option tells xinetd how to log information. You can specify SYSLOG log-facility, where log-facility is a code for the syslog facility to be used, such as daemon, auth, authpriv, user, mail, Ipr, news, uucp, or ftp. You can also specify the logging level after the log-facility, such as emerg, alert, crit, err, warning, notice, info, or debug. If you prefer to log information to a file independently of the syslog facility, you can do so by specifying log_type = FILE filename, where filename is the log filename. You can append two numbers to a FILE log type, specifying the number of events that must occur to trigger a logging event and the number of events beyond which xinetd stops logging (to prevent the log file from filling with identical log messages).

redirect You can tell xinetd to pass TCP connection attempts on to another computer. For instance, redirect = 172.19.201.78 143 redirects the connection attempt to port 143 on 172.19.201.78. Firewall rules can also be used to achieve this effect, and they're generally more efficient. You might want to use this feature in conjunction with other xinetd features, though, such as temporal restrictions, as described in Chapter 20.

Security Options You can configure xinetd with an assortment of access control tools based on IP address, time, and so on. Chapter 20 describes these options in more detail.

Just as with inetd, you must tell xinetd to restart or reread its configuration file after making changes to that file. This is also necessary if you add a new configuration file to /etc/xinetd.d, such as after you install a new server. You can use the same methods to restart xinetd or have it reread its configuration file that you can use with inetd. As with inetd, the method that's least likely to cause disruption is to pass the server a HUP signal, as in killall -HUP xinetd.

On Mandrake and Red Hat, some of the tools described earlier for modifying SysV startup script configurations also work with xinetd configurations. Most importantly, chkconfig, ntsysv, and Red Hat's Service Configuration tool can handle xinetd-mediated servers. All xinetd-mediated servers run in the same runlevels in which xinetd runs, though, so it's not possible to modify the runlevels for individual xinetd-mediated servers.

Team LiB

Team LIB

previous previous

0 0

Post a comment