xinetd
Summary:
Section index -
KB index
xinetd is the eXtented ~InterNET services Daemon. It replaces the venerable inetd as a more secure alternative allowing for a fine-grained control of who is allowed to access what or how many services at which time and log all that.
Configuration
If you already have an inetd.conf file, you can convert it to a xinetd.conf file using the 'xconv' utility provided in the source archive at
xinetd.org. You'd use it like this:
xconv.pl < /etc/inetd.conf > /etc/xinetd.conf
The standard '/etc/xinetd.conf' file provided with the Mandrake xinetd RPM looks like this:
~#
~# Simple configuration file for xinetd
~#
~# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
}
includedir /etc/xinetd.d
This file sets some defaults for xinetd in general and than forks to the /etc/xinetd.d/ directory which contains the configuration files for the services managed by xinetd. There's a maximum of 60 instances of the same server type at the same time, logging is done via the syslog authpriv facility and xinetd logs hostname and PID in case of a successful connection. If the connect isn't successful, it logs the hostname.
One important thing to note is that the per-service configuration files in '/etc/xinetd.d/' inherit all settings from the main configuration file unless they explicitly change them. If you for example add the option
only_from = 192.168.0.0/24
to '/etc/xinetd.conf' then this access restriction to machines in the 192.168.0.x network will apply to
all the services with files in '/etc/xinetd.d/'. If you want a service to be accessible from machines in other ranges, too, or not at all, you'll have to specify that in the service's configuration file, e.g. with
only_from = 192.168.0.0/24 10.0.0.0/24
The 'only_from' and 'no_access' (which correspond to the 'old' 'hosts.allow' and 'hosts.deny' files of the tcp wrapper) are the only options interesting in the context of xinetd.conf. If you're very security conscious, you will add
to 'xinetd.conf' thus by default blocking
all clients for
all services, whereas having no access rule in the 'default' section allows access to all services by everyone unless stated otherwise in each service's configuration file. You will then have to allow access on a per-service basis by adding the allowed networks to each service's configuration file in '/etc/xinet.d/'.
Have a look at a typical standard service configuration file, like the one for cvs:
service cvspserver
{
disable = yes
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/cvspserver
}
turns this service off. All xinetd service configuration files I've seen so far come with this default setting. Either set this to 'no' or delete the line to enable this service.
can be 'stream' (TCP), 'dgram' (UDP), 'raw' (IP direct access) or 'seqpacket'. Most of the common Internet services like POP, SMTP or FTP use TCP, i.e. 'stream'.
is a bit redundant here, but since cvspserver might also run via UDP, this setting avoids any possible confusion.
determines if the xinetd is allowed to start a new server process for every incoming request (
), or if only one connection at a time is allowed (
). This settings depends on the type of service you want to provide, but for most services you definitely want to set
here.
sets the system user for the service. Check the service's documentation under which UID the process runs. Usually it's either 'root' or 'nobody'.
provides the path for the service executable.
There are of course a lot of interesting options you could add here ;-):
only_from {IP1} {IP2}
to allow only certain networks.
access_times {HH:MM}
to determine when the service can be accessed (24h format).
instances {number}
to say how many concurrent instances of a server you allow. This comes in handy in case of Denial-of-Service attack or when a link to your server appears on Slashdot ;-).
sets the priority of the server ().
- allows you to bind a service to a certain IP. This way you can run a server on an internal network IP for the LAN only, and another on an IP reachable from the outside (the machine needs at least two network interface, of course). If you do this, you need an entry for each server and you have to add the option, with a different 'name' for each entry.
redirect {IP} {Port}
allows you to redirect incoming requests for this service to another machine on the network.
This was just a quick glance into the wonderful world of xinetd. has more. You might also find 'sample.conf' and the FAQ in '/usr/share/doc/xinetd-{...}/' helpful.
section index
Related Resources:
xinetd.org
xinetd FAQ
~LinuxFocus: xinetd
Revision / Modified: Aug. 09, 2001
Author: Tom Berger
Legal: This page is covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.