Using xinetd

Replacing inetd, xinetd provides access control, improved logging and resource management. It has become the standard Internet super dæmon for Red Hat 7 and Mandrake 7.2. This article is designed to get you started with using some of its features—hopefully some of its more interesting ones—and is based on features available in xinetd 2.1.8.8pre3.

The original author of xinetd, Panagoitis Tsirigotis (panos@cs.colorado.edu), seems to have dropped the project. Rob Braun (bbraun@synack.net) has picked up the project and is now responsible for maintaining the package. One problem I noticed with the package in its current state was that I had to add a couple of header files to get select( ) to work on my old libc5 system. Should you need them, they are as follows:

xinetd/internals.c.orig
Fri Jun 16 19:00:15 2000
+++ xinetd/internals.c
Fri Jun 16 19:00:53 2000
@@ -12,6 +12,8 @@
 #include <time.h>
 #include <fcntl.h>
 #include <syslog.h>
 #include <unistd.h>
 #include <sys/time.h>
 #include "sio.h"

xinetd replaces the common inetd lines with bracketed, expanded syntax. In addition, new possibilities are given for logging and access control. While inetd allows control for TCP connections using Venema's tcp_wrappers software (tcpd), you cannot control UDP connections. Also, it doesn't do well with RPC (portmapper) type services. Additionally, while you can control the rate of connections using inetd (by appending a number to the wait or no wait argument, for example, nowait.1 for one instance per second), you cannot control the maximum number of instances. This could lead to process table attacks, for example, an effective denial of service. By using xinetd, we can thwart this.

I usually start xinetd with the following command, placed in my startup scripts where Internet services are started:

/usr/sbin/xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf

This tells xinetd to log everything to the file /var/adm/xinetd.log and use the configuration file /etc/xinetd.conf. The bulk of this article will deal with this configuration file.

The three compile-time options you should pay attention to that provide added access control are libwrap, loadavg (a threshold monitor for load averaging) and IPv6 support. As with most libwrap-aware dæmons (like portmapper and sendmail), the option “with-libwrap” in the configure script tells xinetd to be built linking in support for the tcp_wrappers file /etc/hosts.allow and /etc/hosts.deny. These options for xinetd work exactly as they do for inetd and support all of the xinetd-controlled dæmons. Note that if you're starting from scratch with xinetd, using tcpd is no longer needed as access control is done within xinetd. However, this support for libwrap is useful if you're migrating from inetd/tcpd and don't want to change your access files too.

The second interesting configuration option is support load average monitoring, accomplished using the with-loadavg option in the ./configure script. sendmail supports dropping connections at high load, presuming that it has spun out of control and is taking down the machine. The max_load option can be enabled using this configuration option to limit connections to any or all services based on the load average of the machine.

Lastly, the configuration option to add IPv6 support is accomplished by using the with-inet6 capability in ./configure. This adds xinetd support for IPv6 addresses and connections. Note that your kernel (and network) must support IPv6 for this to be effective. IPv4 support is maintained, of course.

The xinetd configuration file, usually /etc/xinetd.conf, can be built by hand or automatically from an inetd.conf file. The former is more time consuming and prone to errors; the latter is readily accomplished using the itox utility or xconv.pl script. Although the itox utility is being dropped in favor of the xconv.pl script, it is still useful. However, note that running it repeatedly will overwrite the existing file. Both itox and xconv work in the same way, but we'll show it for itox:

$ itox < /etc/inetd.conf > xinetd.conf

The newer utility, xconv, understands comments and the use of tcpd better than itox does. For itox you have to specify the directory where dæmons live, such as /usr/sbin. The first section you may want to include is the defaults section. This gives, as the name implies, defaults for the xinetd service:

defaults
{
   instances       = 25
   log_type        = FILE /var/adm/servicelog
   log_on_success  = PID HOST EXIT
   flags           = NORETRY
   log_on_failure  = HOST RECORD ATTEMPT
   only_from       = 129.22.0.0
   no_access       = 129.22.210.61
   disabled        = nntp uucp tftp bootps who
                     shell login exec
   disabled       += finger
}

Table 1. Directives for xinetd

Operators are quite simple, either = or +=. Using =, the values on the right are given to the directive on the left. += is also quite intuitive and is used to append values to an already defined directive. Without it, earlier directives are overwritten. This can also be used to spread access lists or, for example, over multiple lines.

Service descriptions are given by the format:

servicename
{
        directive = value
        directive += value
}

Servicename must be listed in the /etc/services to occur on the proper socket and with the proper protocol.