Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

10.3. The xinetd Alternative

An
alternative to the standard inetd has emerged
and is now widely accepted. It is considered a more secure and robust
program, and provides protection against some DoS attacks used
against inetd. The number of features offered by
xinetd also makes it a more appealing
alternative. Here is a brief list of features:

• Provides full-featured access control and logging

• Limits to the number of servers run at a single time

• Offers granular service-binding -services, which
  can be bound to specific IP addresses

xinetd
is now a standard part of most Linux distributions, but if you need
to find the latest source code or information, check the main
distribution web site http://www.xinetd.org. If you are compiling,
and use IPv6, you should make certain that you use the
--with-inet6 option.

The configuration of xinetd is somewhat
different, but not more complex than inetd.
Rather than forcing one master configuration file for all services,
xinetd can be configured to use a master
configuration file, /etc/xinetd.conf, and
separate configuration files for each additional service configured.
This, aside from simplifying configuration, allows for more granular
configuration of each service, leading to
xinetd's greater flexibility.

The first
file you'll need to configure is
/etc/xinetd.conf. A sample file looks like this:

# Sample configuration file for xinetd
defaults
{
only_from      = localhost
instances      = 60
log_type       = SYSLOG authpriv info
log_on_success = HOST PID
log_on_failure = HOST
cps            = 25 30
}
includedir /etc/xinetd.d

There are a number of options that can be configured, the options
used above are:

only_from

This specifies the IP addresses or
hostnames from which you allow connections. In this example,
we've restricted connections to the loopback
interface only.

instances

This sets the total number of servers that
xinetd will run. Having this set to a reasonable
number can help prevent malicious users from carrying out a DoS
attack against your machine.

log_type SYSLOG|FILE

This option allows you to set the type of logging
you're planning to use. There are two options,
syslog or file. The first,
syslog, will send all log information to the
system log. The file directive will send logs to a
file you specify. For a list of the additional options under each of
these, see the xinetd.conf manpage.

log_on_success

With this option, you can set the type of information logged when a
user connection is successful. Here's a list of some
available suboptions:

HOST

This will log the remote host's IP address.

PID

This logs the new server's process ID.

DURATION

Enable this to have the total session time logged.

TRAFFIC

This option may be helpful for administrators concerned with network
usage. Enabling this will log the total number of bytes in/out.

log_on_failure

HOST

This will log the remote host's IP address.

ATTEMPT

This logs all failed attempts to access services.

cps

Another security feature, this option will
limit the incoming rate of connections to a service. It requires two
options: the first is the number of connections per second which are
allowed, and the second is the amount of time in seconds the service
will be disabled.

Any of these options can be overridden in
the individual service configuration files, which
we're including in the
/etc/xinetd.d directory. These options set in
the master configuration file will serve as default values.
Configuration of individual services is also this simple.
Here's an example of the FTP service, as configured
for xinetd:

service ftp
{
socket_type     = stream
wait            = no
user            = root
server          = /usr/sbin/vsftpd
server_args     = /etc/vsftpd/vsftpd.conf
log_on_success  += DURATION USERID
log_on_failure  += USERID
nice            = 10
disable         = no
}

The first thing you will want to note is that in the
xinetd.d directory, the individual services tend
to be helpfully named, which makes individual configuration files
easier to identify and manage. In this case, the file is simply
called vsftp, referring to the name of the FTP
server we're using.

Taking a look
at this example, the first active configuration line defines the name
of the service that's being configured.
Surprisingly, the service type is not defined by the
service directive. The rest of the configuration
is contained in brackets, much like functions in C. Some of the
options used within the service configurations overlap those found in
the defaults section. If an item is defined in the defaults and then
defined again in the individual service configuration, the latter
takes priority. There are a large number of configuration options
available and are discussed in detail in the
xinetd.conf manpage, but to get a basic service
running, we need only a few:

socket_type

This defines the type of socket used by the service. Administrators
familiar with inetd will recognize the following
available options, such as stream,
dgram, raw, and
seqpacket.

wait

This option specifies whether the service is single or dual-threaded.
yes means that the service is single threaded and
that xinetd will start the service and then will
stop handling requests for new connections until the current session
ends. no means that new session requests can be
processed.

user

Here, you set the name of the user that will run the service.

server

This option is used to specify location of the service
that's being run.

server_args

You can use this option to specify any additional options that need
to be passed to the server.

nice

This option determines the server priority. Again, this is an option
that can be used to limit resources used by servers.

disable

Really a very straightforward option, this
determines whether or not the service is enabled.