Red Hat Linux configures a variety of popular network services to be used with
xinetd, including FTP, IMAP, POP, and Telnet. When
any of these services are accessed via their port numbers in
/etc/services, the xinetd daemon
handles the request. Before bringing up the requested network service,
xinetd ensures that the client host information meets
the access control rules, the number of instances of this service is
under a particular threshold, and any other rules specified for that
service or all xinetd services are followed. Once the
target service is brought up for the connecting client,
xinetd goes back to sleep, waiting for additional
requests for the services it manages.
xinetd Configuration Files
The xinetd service is controlled by the
/etc/xinetd.conf file, as well as the various
service-specific files in the /etc/xinetd.d/
directory.
/etc/xinetd.conf
The xinetd.conf file is the parent of all
xinetd-controlled service configuration files, as
the service-specific files are also parsed every time
xinetd starts. By default,
xinetd.conf contains some basic configuration
settings that apply to every service. Below is an example of a
typical xinetd.conf:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d |
These lines control various aspects of xinetd:
instances — Sets the
maximum number of requests a particular service can handle at
once.
log_type — Tells
xinetd to use the
authpriv log, specified in
/etc/syslog.conf and set to
/var/log/secure by default, rather than using
another specific file. Using FILE
/var/log/xinetdlog here instead would move
xinetd logging to a separate
/var/log/xinetdlog file.
log_on_success — Lets
xinetd know what to log if the connection is
successful. By default, the remote host's IP address and the
process ID of server processing the request are recorded.
log_on_failure — Tells
xinetd what to log if the connection fails or
is not allowed.
cps — Tells
xinetd to allow no more than 25 connections
per second to a given service. If this limit is reached, the
service is retired for 30 seconds.
 | Note |
|---|
| | Both the log_on_success and
log_on_failure settings in
/etc/xinetd.conf are often modified by each
service, meaning that successful and failed connections will
usually log more information than is indicated in
/etc/xinetd.conf.
|
Various logging options are available in
/etc/xinetd.conf and the service-specific
xinetd configuration files:
ATTEMPT — Logs the fact that a failed
attempt was made. (log_on_failure)
DURATION — Logs the length of time
the service is used by a remote
system. (log_on_success)
EXIT — Logs the exit status or
termination signal of the service. (log_on_success)
HOST — Logs the remote host's IP
address. (log_on_failure and
log_on_success)
PID — Logs the process ID of the
server receiving the request. (log_on_success)
RECORD — Records information about
the remote system in the case the service cannot be
started. Only particular services, such as
login and finger, may
use this option. (log_on_failure)
USERID — Logs the remote user using
the method defined in RFC 1413 for all multi-threaded stream
services. (log_on_failure and
log_on_success)
Other options for /etc/xinetd.conf are
available, such as per_source,
which limits the maximum number of connections from a particular IP
address to a specific service. See the man page for
xinetd for more information.
Files in the /etc/xinetd.d/
Directory
The files in the /etc/xinetd.d/ directory are
read every time xinetd starts, due to the
includedir /etc/xinetd.d/ statement
at the bottom of /etc/xinetd.conf. These files,
with names such as finger,
ipop3, and rlogin,
correlate to the services controlled by xinetd.
The files in /etc/xinetd.d/ use the same
conventions as /etc/xinetd.conf. The primary
reason they are stored in separate configuration files is to make it
easier to add and remove a service from xinetd
without affecting other services.
To get an idea of how these files are structured, consider the
wu-ftp file:
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = yes
} |
The first line defines the service's name. The lines within the
brackets contain settings that define how this service is supposed
to be started and used. The wu-ftp file states
that the FTP service uses a stream socket type
(rather than dgram), the binary executable file to
use, the arguments to pass to the binary, the information to log in
addition to the /etc/xinetd.conf settings, the
priority with which to run the service, and more.
The use of xinetd with a service also can serve
as a basic level of protection from a Denial of Service (DoS)
attack. The max_load option takes a floating point
value to set a CPU usage threshold when no more connections for a
particular service will be accepted, preventing certain services
from overwhelming the system. The cps option
accepts an integer value to set a rate limit on the number of
connections available per second. Configuring this value to
something low, such as 3, will help
prevent attackers from being able to flood your system with too many
simultaneous requests for a particular service.
Access Control within xinetd
Users of xinetd services can choose to use the
TCP wrapper host access control files
(/etc/hosts.allow and
/etc/hosts.deny), provide access control via the
xinetd configuration files, or a mixture of
both. Information concerning the use of TCP wrapper host access
control files can be found in the Section called Host-Based Access Control Lists. This section will discuss
using xinetd to control access to services.
| Note |
|---|
| | Unlike TCP wrapper host access control files, any changes to
xinetd configuration files require a restart of
the xinetd service to go into affect.
|
The xinetd host access control available through
its various configuration files is different from the method used by
TCP wrappers. While TCP wrappers places all of the access configuration
within two files, /etc/hosts.allow and
/etc/hosts.deny, each service's file in
/etc/xinetd.d can contain access control rules
based on the hosts that will be allowed to use that service.
The following options are supported in the xinetd
files to control host access:
only_from — Allows the hosts specified
to use the service.
no_access — Blocks these hosts from
using this service.
access_times — Specifies the time
range when a particular service may be used. The time range must
be stated in a HH:MM-HH:MM
format using 24-hour notation.
The only_from and no_access
options can use a list of IP addresses or host names, or can specify
an entire network. Like TCP wrappers, combining
xinetd access control with the proper logging
configuration for that service, you can not only block the request
but also record every attempt to access it.
For example, the following /etc/xinetd.d/telnet
file can be used to block telnet access to a
system by a particular network group and restrict the overall time
range that even legitimate users can log in:
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
no_access = 10.0.1.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
} |
In this example, when any system from the 10.0.1.0/24 subnet, such
as 10.0.1.2, tries to telnet into the server,
they will receive a message stating Connection
closed by foreign host. In addition, their login
attempt is logged in /var/log/secure:
May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256 |
Binding and Port Redirection
The service configuration files for xinetd also
support binding the service to an IP address and redirecting
incoming requests for that service to another IP address, hostname,
or port.
Binding is controlled with the bind option in the
service configuration files and links the service to one IP address
on the system. When used, the bind option
only allows requests for the proper IP address to access
the service. Each service can be bound to different network
interfaces based on your needs. This is particularly useful
for systems with multiple network adapters or using multiple IP
addresses. For instance, you can configure telnet to listen only on
the interface connected to a private network and not to the
interface connected with the Internet.
The redirect option accepts an IP address or
hostname followed by a port number. It tells the service to redirect
any requests for this service to the specified host and port
number. This feature can be used to point to another port number on
the same system, redirect the request to different IP address on the
same machine, shift the request to a totally different system and
port number, or any combination of these options. In this way, a
user connecting to certain service on a system may be rerouted to
another system with no disruption.
The xinetd daemon is able to accomplish this
redirection by spawning a process that stays alive for the duration
of the connection between the requesting client machine and the host
actually providing the service, transferring data between the two
systems.
The real strength of the bind and
redirect options can be seen when they are used
together. By binding a service to a particular IP address on a
system and then redirecting requests for this service to a second
machine that only the first machine can see, you can use an internal
system to provide services for a totally different
network. Alternatively, these options can be used to limit the
exposure of a particular service on a multi-homed machine to a known
IP address, as well as redirect any requests for that service to
another machine specially configured for that purpose.
For example, consider a system that is used as a firewall with this
setting for its telnet service:
service telnet
{
socket_type = stream
wait = no
server = /usr/sbin/in.telnetd
log_on_success += DURATION USERID
log_on_failure += USERID
bind = 123.123.123.123
redirect = 10.0.1.13 21 23
} |
The bind and redirect options in
this file will ensure that the telnet service on the machine is bound
to the external IP address (123.123.123.123), the one facing the
Internet. In addition, any requests for telnet service sent to
123.123.123.123 will be redirected via a second network adapter to
an internal IP address (10.0.1.13) that only the firewall and
internal systems can access. The firewall will then send the
communication between the two systems, and the connecting system
will think it is connected to 123.123.123.123 when it is actually
connected to a different machine.
This feature is particularly useful for users with broadband
connections and only one fixed IP address. When using Network
Address Translation (NAT), the systems behind the gateway machine,
which are using internal-only IP addresses, are not available from
outside the gateway system. However, when certain services
controlled by xinetd are configured with the
bind and redirect options, the
gateway machine can act as a type of proxy between outside systems
and a particular internal machine configured to provide the service. In
addition, the various xinetd access control and
logging options are also available for additional protection, such
as limiting the number of simultaneous connections for the redirected
service.
