Controlling Access to Your Services with xinetd

By: Dee-Ann LeBlanc
Monday, October 21, 2002 10:33:42 AM EST
URL: http://www.linuxplanet.com/linuxplanet/tutorials/4505/1/

Creatures of the Linux Underworld

Whenever you learn about controlling access to a Linux box, one "creature" you usually encounter is the "superdaemon." A superdaemon is a daemon that controls other daemons--and daemons are typically network service control programs that run long-term behind the scenes, waiting for when they need to step into action.

In the Linux realm, "the superdaemon" has typically referred inetd, which handles requests for a number of daemons that either aren't used often enough to justify running in the background all of the time, or have such a simple job that a standalone daemon simply isn't needed. The problem with inetd is that this superdaemon makes little attempt to be secure. It allows you to disable various services if you don't want to use them, but there is no fine control available.

Enter xinetd (http://www.xinetd.org). This program is a "secure" replacement for inetd, meaning in this case that it offers many features that allow you to control who accesses which services, and from where. I always keep the Titanic in mind when I talk about security or safety, meaning that nothing is fully secure, but any level of native access control in the superdaemon certainly helps us to protect our systems.

Some distributions (such as Mandrake and Red Hat) currently come with xinetd installed and enabled by default. Yours might include xinetd but not by default, or you can download the tool from the project site.

xinetd Versus inetd, an Overview

Let's take a look at the real differences between xinetd and inetd before we get into using xinetd. Anyone who's dealt with the inetd superdaemon is likely familiar with its configuration file, inetd.conf. This file contains a list of all of the services the daemon controls, along with commented out items that it could control if you wanted to activate those services.

That's pretty much all there is to inetd. You can control these services using additional features of Linux itself, such as hosts.allow, hosts.deny, traffic filtering, and so on. But for many people that's not enoughmost of the files discussed in this article are in the /etc directory on most Linux distributions, but sometimes distributions like to utilize a different setup, so you might have to dig for them.

xinetd has a collection of configuration files. The base file is xinetd.conf, which allows for general configuration. Along with the main configuration file is the subdirectory xinetd.d, which contains a series of individual files pertaining to various applications. Each of these files is loaded by the xinetd.conf when xinetd loads its configuration data into memory.

Within each of the xinetd configuration files you have a wide range of choices to control where people can access a service from, what local accounts they can use to access the service, what remote accounts they can use, and much more.

Installing xinetd

Since there are so many distributions that don't come with xinetd already installed by default, I'll go through the process of getting and installing xinetd from its web site. Those who have access to this tool already or through their distribution's package management system might prefer to install from there insteadlook for the distribution version first, that will make your life much easier since it will ensure your distribution knows the program is installed.

Point your browser to the xinetd site, and download the source file. You'll find that it's remarkably small, and that the installation is a pretty standard process. To compile and install this software, do the following:

  1. Uncompress and unpackage it by typing tar xzvf xinetd-version*. You might find as I did that, oddly, the file came through with an extra .tar on the end. You'll need to rename the file so that it ends in .tar.gz, not .tar.gz.tar, if that happens to you.
  2. Change to the directory created during this process.
  3. Type ./configure to run the autoconfiguration routine. You might be told that you need to add particular software packages. If so, do that now, and start Step 3 again.
  4. Type make to compile the program. The speed of your machine, its RAM, and what else you're doing all are factors in how long this process will take. However, even on my PIII 450 it took less than five minutes.
  5. Type make install to put the package and its files into place. This process finishes quite fast.
  6. If you want to base your xinetd configuration on your current inetd configuration, then make sure you have Perl installed, and then type the following as suggested by the xinetd team: 
    xinetd/xconv.pl < /etc/inetd.conf > /tmp/xinetd.conf

That's the first stage. Notice that your new configuration file was copied into /tmp. Do not try to use the default file. It likely won't work.

Understanding xinetd Configuration Files

The xinetd program has two major configuration setups. First, there's the default configuration, which is in the file /etc/xinetd.confthough your distribution might put this file in a different place. Then there's a group of files typically in the /etc/xinetd.d directory that each corresponds to a different service.

We'll start with xinetd.conf. A default setup for this file might look like: 

# Simple configuration file for xinetd

defaults
{
        only_from             = localhost
        instances             = 60
        log_type              = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
          cps                         = 25 30
}

includedir /etc/xinetd.d

If you've only seen the inetd configuration file before, it should already be obvious just how different xinetd setup is. Contained in xinetd.conf are your global defaultsthough you can do individual configurations here as well. The globals are assigned in the defaults statement, and its contents are marked off with the braces ({}). Let's take a look at the options from top to bottom:

  • only_from Restricts access to a service to only the specified external machines.
  • instances Restricts how many simultaneous accesses to this service will be accepted.
  • log_type Sets logging rules for this particular service. The options here are SYSLOG and FILE. SYSLOG tells xinetd to utilize syslogd, the "standard" Linux system logging daemon, and the term that follows it tells syslogd which facility and level (see man syslogd) to utilize.
  • log_on_success Sets logging rules for a successfully started server instance. The value(s) allowed are DURATION, EXIT, HOST, PID, and USERID (see man xinetd.conf for more details).
  • log_on_failure Sets logging rules for when a requested server instance cannot start, either due to bugs or the request not matching the set rules. Value(s) allowed are ATTEMPT, HOST, and USERID (again, see man xinetd.conf for more information).
  • cps Restricts the rate of incoming connections that xinetd will bother with. The first argument is how many requests per second the server will put up with before it disables the requested service completely. The second argument tells xinetd how many seconds to wait before opening the port again.

If you see the following as the last line then your xinetd is set up to look in /etc/xinetd.d (or whatever directory is specified) for specific configurations: 

includedir /etc/xinetd.d

You can add such a line as well, if needed.

When we turn our attention to the broader range of elements you might configure for specific services, we discover that there is a long list of options. Rather than spending the time and space covering every option in detail, I'll cover one specific example so that we can get on to more tutorial. You can get more information about any option, and of course the whole list of available options, in the xinetd.conf man page.

Let's use the vsftpd xinetd configuration file: 

# default: off
# description: The vsftpd FTP server serves FTP connections. It uses \
#       normal, unencrypted usernames and passwords for authentication.
service ftp
{
        disable         = no
        socket_type             = stream
        wait                    = no
        user                    = root
        server          = /usr/sbin/vsftpd
        nice                    = 10
}

Notice that this file, like all of its cousins in /etc/xinetd.conf, starts with a line in the form service <servicename>. <servicename> is one of the items in /etc/services or one of the other files listed in this tutorial, and refers to the basic functionality provided by this particular tool. In the case of vsftpd, it's not hard to guess that the service is ftp.

Inside the braces are the options for this specific service. Here I'm only going to define what these particular settings mean. We'll get into the specifics of these options in the tutorial. The vsftpd setup is, from top to bottom:

  • The port is open and the service is available.
  • FTP uses TCP so that it can ensure that all of the data has arrived, and so is a streaming socket type.
  • Streaming sockets are typically set to no wait.
  • This FTP server runs as root.
  • This FTP server is located at /usr/bin/vsftpd.
  • This command runs at an average priority level.

All of these settings are in addition to what was set in xinetd.conf.

Configuring xinetd.conf and the xinetd.d files

When it comes to configuring your own superdaemon, you might be much more fussy than just accepting the defaults. The first thing you need to do is determine which services you want to configure, because what the service is and does will tell you what statements you must include, and what statements won't work at all.

Once you've got a list of what you want to custom configure, decide if you want to alter xinetd.conf itself, or to create a separate file in the xinetd.d directory. I typically recommend that if it's not global, to use the separate files. It just keeps things neater.

Now you have to choose what you want to set for this particular service. There are forty-four available parameters, but only two that must be set for any service. These two are:

  • socket_type This entry is determined by whether the underlying protocol used is TCP (which yields a socket type of stream) or UDP (which yields a socket type of "dgram").
  • wait This entry is also determined by whether you're using TCP (not) or UDP (yes).

The other required parameters depend on the type of service you're setting up. For the services that xinetd does not handle for you, such as incoming FTP and web requests, you must also have:

  • server The path to the program that xinetd needs to start.
  • server_args Only required if you need to pass flags, options, or values to the server when it's started.
  • user The user that this program should run as. More often than not, this user is root, but never just blindly use root if you can help it.

Another pair of services are referred to as RPC services, and unlisted services. An RPC (Remote Procedure Call) service is a C programming library that supports client/server architecture, allowing a machine to send a command to another machine, which executes the command and then sends back the results. An unlisted service is one that isn't included in /etc/services or /etc/rpcthe file that contains the list of all RPC services.

Keeping the RPC and unlisted services in mind, the remaining required statements (if appropriate for the service you're setting up) are:

  • port The port to accept communications for this service on. Only required for unlisted services that don't use RPC.
  • protocol The protocol from /etc/protocols that this service requires. Only absolutely necessary for RPC and unlisted services.
  • rpc_number The number from /etc/rpc for this services. Only absolutely necessary for RPC and unlisted services.
  • rpc_version The version number of RPC that this service requires, either a single number or a range separated by dashes. Only required for RPC services.

From here, everything is optional. Rather than putting you to sleep covering all of the items in the xinetd.conf man page, here are the ones you are most likely to want to use or to run into when editing existing filessee the xinetd.conf man page for in depth specifics on exact syntax and options:

  • banner_fail A banner to print for the user who tries to access this service but isn't allowed.
  • banner_success A banner to print for the user who successfully accesses this service.
  • bind Only accept accesses for this service through a particular network device.
  • cps The threshold of connections per second that push xinetd to temporarily disable the service.
  • disable A no if you want xinetd to pick up the phone when someone tries to access this service, and a yes if you don't. Often distributions that utilize xinetd will install software such as FTP servers with disable = yes so that they will not be available until you've fully configured the server and then enable it.
  • env Ensures that the specified environment variables are in this service's environment.
  • group The group that this program should run as.
  • instances The number of simultaneous accesses xinetd should allow for this service. UNLIMITED is the default.
  • log_on_success What information to log when the service starts and when it stops.
  • log_on_failure What information to log when a service can't start due to an error or someone trying to get in who shouldn't.
  • log_type Whether to use the syslog daemon or log to a file.
  • max_load The threshold of the one minute load average that causes xinetd to refuse connections for this service.
  • nice The priority this particular service should have in taking up CPU cycles. See the nice man page for details.
  • no_access Expressly forbids access from the specified location to this service. Uses the same formats as only_from.
  • only_from Which hosts outside of this server are allowed to access this service.
  • per_source Limits how many times someone can access this service from the same location at the same time.
  • redirect Whenever someone tries to access this service, point the request to another location and forward it along.

Most of these entries are used in the format: 

statement = item1 item2 ...

So, once you know what service you want to configure, where you want to configure it (what file), and what portions you want to configure, you create an entry that looks like this whether you're doing it in the main file or in one of the separate files: 

servicename

        statement1 = item1 item2 ...
        statement2 = item1 item2 ...
        ...
}

Once you're finished making these configuration changes, be sure to restart xinetd so it can load the new setup. It's typically a good idea to use the control scripts if your distribution supports them. For example, in Red Hat Linux you would type: 

/etc/rc.d/init.d/xinetd restart

Hopefully you've found here that xinetd deserves further investigation. If you're used to inetd then this more secure superdaemon can give you a few headaches at first, but the better control over who's accessing your system, and when, makes up for it.

Sites of interest:
http://www.faqs.org/rfcs/
http://www.networksorcery.com/enp/topic/ipsuite.htm

Dee-Ann LeBlanc has written over 10 computer books, over sixty articles, taught classes, and more, mostly involving the Linux operating system and its programs. You can follow her work and share your input through her new mailing list at http://www.dee-annleblanc.com/mailman/listinfo/general, or find out more in general at http://www.Dee-AnnLeBlanc.com/.

Copyright Jupitermedia Corp. All Rights Reserved.