DESCRIPTION
xinetd.conf is the configuration file that determines the services pro-
vided by xinetd. Any line whose first non-white-space character is a
'#' is considered a comment line. Empty lines are ignored.
The file contains entries of the form:
service <service_name>
{
<attribute> <assign_op> <value> <value> ...
...
}
The assignment operator, assign_op, can be one of '=', '+=', '-='. The
majority of attributes support only the simple assignment operator,
'='. Attributes whose value is a set of values support all assignment
operators. For such attributes, '+=' means adding a value to the set
and '-=' means removing a value from the set. A list of these
attributes will be given after all the attributes are described.
Each entry defines a service identified by the service_name. The fol-
lowing is a list of available attributes:
id This attribute is used to uniquely identify a service.
This is useful because there exist services that can
use different protocols and need to be described with
different entries in the configuration file. By
default, the service id is the same as the service
name.
type Any combination of the following values may be used:
RPC if this is an RPC service
INTERNAL if this is a service provided by xinetd.
TCPMUX/TCPMUXPLUS
if this is a service that will be started
according to the RFC 1078 protocol on the
TCPMUX well-known port. See the section
describing TCPMUX services below.
UNLISTED if this is a service not listed in a stan-
dard system file (like /etc/rpc for RPC
services, or /etc/services for non-RPC
services).
flags Any combination of the following flags may be used:
INTERCEPT Intercept packets or accepted connections
in order to verify that they are coming
from acceptable locations (internal or
NAMEINARGS This will cause the first argument in
"server_args" to be argv[0] when executing
the server, as specified in "server".
This allows you to use tcpd by putting
tcpd in "server" and the name of the
server in "server_args" like in normal
inetd.
NODELAY If the service is a tcp service and the
NODELAY flag is set, then the TCP_NODELAY
flag will be set on the socket. If the
service is not a tcp service, this option
has no effect.
KEEPALIVE If the service is a tcp service and the
KEEPALIVE flag is set, then the
SO_KEEPALIVE socket flag will be set on
the socket. If the service is not a tcp
service, this option has no effect.
NOLIBWRAP This disables internal calling of the tcp-
wrap library to determine access to the
service. This may be needed in order to
use libwrap functionality not available to
long-running processes such as xinetd; in
this case, the tcpd program can be called
explicitly (see also the NAMEINARGS flag).
SENSOR This replaces the service with a sensor
that detects accesses to the specified
port. NOTE: It will NOT detect stealth
scans. This flag should be used only on
services that you know you don't need.
When an access is made to this service's
port, the IP Address is added to a global
no_access list. This causes all subsequent
accesses from the originating IP address
to be denied access until the deny_time
setting expires. The amount of time spent
on this list is configurable as the
deny_time attribute. The SENSOR flag will
also cause xinetd to consider the server
attribute to be INTERNAL no matter what is
typed on the same line. Another important
thing to remember is that if the
socket_type is set to stream, then the
wait attribute should be set to no.
IPv4 Sets the service to be an IPv4 service
(AF_INET).
IPv6 Sets the service to be an IPv6 service
dgram datagram-based service
raw service that requires direct access to IP
seqpacket service that requires reliable sequential
datagram transmission
protocol determines the protocol that is employed by the ser-
vice. The protocol must exist in /etc/protocols. If
this attribute is not defined, the default protocol
employed by the service will be used.
wait This attribute determines if the service is single-
threaded or multi-threaded and whether or not xinetd
accepts the connection or the server program accepts
the connection. If its value is yes, the service is
single-threaded; this means that xinetd will start the
server and then it will stop handling requests for the
service until the server dies and that the server
software will accept the connection. If the attribute
value is no, the service is multi-threaded and xinetd
will keep handling new service requests and xinetd
will accept the connection. It should be noted that
udp/dgram services normally expect the value to be yes
since udp is not connection oriented, while tcp/stream
servers normally expect the value to be no.
user determines the uid for the server process. The user
name must exist in /etc/passwd. This attribute is
ineffective if the effective user ID of xinetd is not
super-user.
group determines the gid for the server process. The group
name must exist in /etc/group. If a group is not
specified, the group of user will be used (from
/etc/passwd). This attribute is ineffective if the
effective user ID of xinetd is not super-user.
instances determines the number of servers that can be simulta-
neously active for a service (the default is no
limit). The value of this attribute can be either a
number or UNLIMITED which means that there is no
limit.
nice determines the server priority. Its value is a (possi-
bly negative) number; check nice(3) for more informa-
tion.
server determines the program to execute for this service.
server_args determines the arguments passed to the server. In con-
trast to inetd, the server name should not be included
apply to IPv6 addresses.
b) a factorized address in the form of
%d.%d.%d.{%d,%d,...}. There is no need for all 4
components (i.e. %d.%d.{%d,%d,...%d} is also ok).
However, the factorized part must be at the end
of the address. This form does not work for IPv6
hosts.
c) a network name (from /etc/networks). This form
does not work for IPv6 hosts.
d) a host name. When a connection is made to
xinetd, a reverse lookup is performed, and the
canonical name returned is compared to the speci-
fied host name. You may also use domain names in
the form of .domain.com. If the reverse lookup
of the client's IP is within .domain.com, a match
occurs.
e) an ip address/netmask range in the form of
1.2.3.4/32. IPv6 address/netmask ranges in the
form of 1234::/46 are also valid.
Specifying this attribute without a value makes the
service available to nobody.
no_access determines the remote hosts to which the particular
service is unavailable. Its value can be specified in
the same way as the value of the only_from attribute.
These two attributes determine the location access
control enforced by xinetd. If none of the two is
specified for a service, the service is available to
anyone. If both are specified for a service, the one
that is the better match for the address of the remote
host determines if the service is available to that
host (for example, if the only_from list contains
128.138.209.0 and the no_access list contains
128.138.209.10 then the host with the address
128.138.209.10 can not access the service).
access_times determines the time intervals when the service is
available. An interval has the form hour:min-hour:min
(connections will be accepted at the bounds of an
interval). Hours can range from 0 to 23 and minutes
from 0 to 59.
log_type determines where the service log output is sent. There
are two formats:
SYSLOG syslog_facility [syslog_level]
The log output is sent to syslog at the speci-
limit is exceeded (if xinetd logs to syslog,
the message will be sent at the alert priority
level). The second limit is a hard limit;
xinetd will stop logging for the affected ser-
vice (if the log file is a common log file,
then more than one service may be affected) and
will log a message about this (if xinetd logs
to syslog, the message will be sent at the
alert priority level). If a hard limit is not
specified, it defaults to the soft limit
increased by 1% but the extra size must be
within the parameters LOG_EXTRA_MIN and
LOG_EXTRA_MAX which default to 5K and 20K
respectively (these constants are defined in
xconfig.h).
log_on_success determines what information is logged when a server is
started and when that server exits (the service id is
always included in the log entry). Any combination of
the following values may be specified:
PID logs the server process id (if the service
is implemented by xinetd without forking
another process the logged process id will
be 0)
HOST logs the remote host address
USERID logs the user id of the remote user using
the RFC 1413 identification protocol.
This option is available only for multi-
threaded stream services.
EXIT logs the fact that a server exited along
with the exit status or the termination
signal (the process id is also logged if
the PID option is used)
DURATION logs the duration of a service session
TRAFFIC logs the total bytes in and out for a
redirected service.
log_on_failure determines what information is logged when a server
cannot be started (either because of a lack of
resources or because of access control restrictions).
The service id is always included in the log entry
along with the reason for failure. Any combination of
the following values may be specified:
HOST logs the remote host address.
(this attribute is ignored if the service is not
unlisted).
env The value of this attribute is a list of strings of
the form 'name=value'. These strings will be added to
the environment before starting a server (therefore
the server's environment will include xinetd's envi-
ronment plus the specified strings).
passenv The value of this attribute is a list of environment
variables from xinetd's environment that will be
passed to the server. An empty list implies passing
no variables to the server except for those explicitly
defined using the env attribute. (notice that you can
use this attribute in conjunction with the env
attribute to specify exactly what environment will be
passed to the server).
port determines the service port. If this attribute is
specified for a service listed in /etc/services, it
must be equal to the port number listed in that file.
redirect Allows a tcp service to be redirected to another host.
When xinetd receives a tcp connection on this port it
spawns a process that establishes a connection to the
host and port number specified, and forwards all data
between the two hosts. This option is useful when
your internal machines are not visible to the outside
world. Syntax is: redirect = (ip address) (port).
You can also use a hostname instead of the IP address
in this field. The hostname lookup is performed only
once, when xinetd is started, and the first IP address
returned is the one that is used until xinetd is
restarted. The "server" attribute is not required
when this option is specified. If the "server"
attribute is specified, this attribute takes priority.
bind Allows a service to be bound to a specific interface
on the machine. This means you can have a telnet
server listening on a local, secured interface, and
not on the external interface. Or one port on one
interface can do something, while the same port on a
different interface can do something completely dif-
ferent. Syntax: bind = (ip address of interface).
interface Synonym for bind.
banner Takes the name of a file to be splatted at the remote
host when a connection to that service is established.
This banner is printed regardless of access control.
It should *always* be printed when a connection has
been made. xinetd outputs the file as-is, so you must
banner_fail Takes the name of a file to be splatted at the remote
host when a connection to that service is denied.
This banner is printed immediately upon denial of
access. This is useful for informing your users that
they are doing something bad and they shouldn't be
doing it anymore. xinetd outputs the file as-is, so
you must ensure the file is correctly formatted for
the service's protocol. In paticular, if the protocol
requires CR-LF pairs for line termination, you must
supply them.
per_source Takes an integer or "UNLIMITED" as an argument. This
specifies the maximum instances of this service per
source IP address. This can also be specified in the
defaults section.
cps Limits the rate of incoming connections. Takes two
arguments. The first argument is the number of con-
nections per second to handle. If the rate of incom-
ing connections is higher than this, the service will
be temporarily disabled. The second argument is the
number of seconds to wait before re-enabling the ser-
vice after it has been disabled. The default for this
setting is 50 incoming connections and the interval is
10 seconds.
max_load Takes a floating point value as the load at which the
service will stop accepting connections. For example:
2 or 2.5. The service will stop accepting connections
at this load. This is the one minute load average.
This is an OS dependent feature, and currently only
Linux and Solaris are supported for this.
groups Takes either "yes" or "no". If the groups attribute
is set to "yes", then the server is executed with
access to the groups that the server's effective UID
has access to. If the groups attribute is set to
"no", then the server runs with no supplementary
groups. This attribute must be set to "yes" for many
BSD systems. This attribute can be set in the
defaults section as well.
mdns Takes either "yes" or "no". On systems that support
mdns registration of services (currently only Mac OS
X), this will enable or disable registration of the
service. This defaults to "yes".
session_create Takes either "yes" or "no". If yes, xinetd will cre-
ate a new Security Framework Login Session in the
forked child process before launching the daemon.
This defaults to "no".
"DISABLE" flag can prevent a service from being
enabled despite being listed in this attribute.
include Takes a filename in the form of "include
/etc/xinetd/service". The file is then parsed as a
new configuration file. It is not the same thing as
pasting the file into xinetd.conf where the include
directive is given. The included file must be in the
same form as xinetd.conf. This may not be specified
from within a service. It must be specified outside a
service declaration.
includedir Takes a directory name in the form of "includedir
/etc/xinetd.d". Every file inside that directory,
excluding files with names containing a dot ('.') or
ending with a tilde ('~'), will be parsed as xinetd
configuration files. The files will be parsed in
alphabetical order according to the C locale. This
allows you to specify services one per file within a
directory. The includedir directive may not be speci-
fied from within a service declaration.
rlimit_as Sets the Address Space resource limit for the service.
One parameter is required, which is either a positive
integer representing the number of bytes to set the
limit to (K or M may be used to specify kilo-
bytes/megabytes) or "UNLIMITED". Due to the way
Linux's libc malloc is implemented, it is more useful
to set this limit than rlimit_data, rlimit_rss and
rlimit_stack. This resource limit is only implemented
on Linux systems.
rlimit_cpu Sets the maximum number of CPU seconds that the ser-
vice may use. One parameter is required, which is
either a positive integer representing the number of
CPU seconds limit to, or "UNLIMITED".
rlimit_data Sets the maximum data size resource limit for the ser-
vice. One parameter is required, which is either a
positive integer representing the number of bytes or
"UNLIMITED".
rlimit_rss Sets the maximum resident set size limit for the ser-
vice. Setting this value low will make the process a
likely candidate for swapping out to disk when memory
is low. One parameter is required, which is either a
positive integer representing the number of bytes or
"UNLIMITED".
rlimit_stack Set the maximum stack size limit for the service. One
parameter is required, which is either a positive
integer representing the number of bytes or "UNLIM-
You don't need to specify all of the above attributes for each service.
The necessary attributes for a service are:
socket_type
user (non-internal services only)
server (non-internal services only)
wait
protocol (RPC and unlisted services only)
rpc_version (RPC services only)
rpc_number (unlisted RPC services only)
port (unlisted non-RPC services only)
The following attributes support all assignment operators:
only_from
no_access
log_on_success
log_on_failure
passenv
env (does not support the '-=' operator)
These attributes can also appear more than once in a service entry.
The remaining attributes support only the '=' operator and can appear
at most once in a service entry.
The configuration file may also contain a single defaults entry that
has the form
defaults
{
<attribute> = <value> <value> ...
...
}
This entry provides default attribute values for service entries that
don't specify those attributes. Possible default attributes:
log_type (cumulative effect)
bind
per_source
umask
log_on_success (cumulative effect)
log_on_failure (cumulative effect)
only_from (cumulative effect)
no_access (cumulative effect)
passenv (cumulative effect)
instances
disabled (cumulative effect)
enabled (cumulative effect)
banner
banner_success
banner_fail
this attribute is a list of space separated service ids.
enabled has the same properties as disabled. The difference
being that enabled is a list of which services are to be
enabled. If enabled is specified, only the services specified
are available. If enabled is not specified, all services are
assumed to be enabled, except those listed in disabled.
INTERNAL SERVICES
xinetd provides the following services internally (both stream and
datagram based): echo, time, daytime, chargen, and discard. These ser-
vices are under the same access restrictions as all other services
except for the ones that don't require xinetd to fork another process
for them. Those ones (time, daytime, and the datagram-based echo, char-
gen, and discard) have no limitation in the number of instances.
TCPMUX Services
xinetd supports TCPMUX services that conform to RFC 1078. These ser-
vices may not have a well-known port associated with them, and can be
accessed via the TCPMUX well-known port.
For each service that is to be accessed via TCPMUX, a service entry in
/etc/xinetd.conf or in a configuration file in an includedir directory
must exist.
The service_name field (as defined above for each service in any xinetd
configuration file) must be identical to the string that is passed
(according to RFC 1078 protocol) to xinetd when the remote service
requestor first makes the connection on the TCPMUX well-known port.
Private protocols should use a service name that has a high probability
of being unique. One way is to prepend the service name with some form
of organization ID.
The type field can be either TCPMUX or TCPMUXPLUS. If the type is TCP-
MUXPLUS, xinetd will handle the initial protocol handshake (as defined
in RFC 1078) with the calling process before initiating the service. If
the type is TCPMUX, the server that is started is responsible for per-
forming the handshake.
The type field should also include UNLISTED if the service is not
listed in a standard system file (like /etc/rpc for RPC services, or
/etc/services for non-RPC services).
The socket_type for these services must be stream, and the protocol
must be tcp.
Following is a sample TCPMUX service configuration:
service myorg_server
{
disable = no
type = INTERNAL
id = tcpmux
socket_type = stream
protocol = tcp
user = root
wait = no
}
NOTES
1. The following service attributes cannot be changed on reconfigura-
tion: socket_type, wait, protocol, type.
2. When the attributes only_from and no_access are not specified for a
service (either directly or via defaults) the address check is con-
sidered successful (i.e. access will not be denied).
3. The address check is based on the IP address of the remote host and
not on its domain address. We do this so that we can avoid remote
name lookups which may take a long time (since xinetd is single-
threaded, a name lookup will prevent the daemon from accepting any
other requests until the lookup is resolved). The down side of
this scheme is that if the IP address of a remote host changes,
then access to that host may be denied until xinetd is reconfig-
ured. Whether access is actually denied or not will depend on
whether the new host IP address is among those allowed access. For
example, if the IP address of a host changes from 1.2.3.4 to
1.2.3.5 and only_from is specified as 1.2.3.0 then access will not
be denied.
4. If the USERID log option is specified and the remote host either
does not run an identification server or the server sends back a
bad reply, access will not be denied unless the IDONLY service flag
is used.
5. Interception works by forking a process which acts as a filter
between the remote host(s) and the local server. This obviously
has a performance impact so it is up to you to make the compromise
between security and performance for each service. The following
tables show the overhead of interception. The first table shows
the time overhead-per-datagram for a UDP-based service using vari-
ous datagram sizes. For TCP-based services we measured the band-
width reduction because of interception while sending a certain
amount of data from client to server (the time overhead should the
same as for UDP-based services but it is "paid" only by the first
packet of a continuous data transmission). The amount of data is
given in the table as system_callsxdata_sent_per_call, i.e. each
send(2) system call transferred so many bytes of data. The band-
width reduction is given in terms of bytes per second and as a per-
centage of the bandwidth when interception is not performed. All
10000x1024 319,300 (39.5%)
10000x4096 824,461 (62.1%)
EXAMPLE
#
# Sample configuration file for xinetd
#
defaults
{
log_type = FILE /var/log/servicelog
log_on_success = PID
log_on_failure = HOST
only_from = 128.138.193.0 128.138.204.0
only_from = 128.138.252.1
instances = 10
disabled = rstatd
}
#
# Note 1: the protocol attribute is not required
# Note 2: the instances attribute overrides the default
#
service login
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/in.rlogind
instances = UNLIMITED
}
#
# Note 1: the instances attribute overrides the default
# Note 2: the log_on_success flags are augmented
#
service shell
{
socket_type = stream
wait = no
user = root
instances = UNLIMITED
server = /usr/etc/in.rshd
log_on_success += HOST
}
service ftp
{
socket_type = stream
wait = no
nice = 10
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
#
# This entry and the next one specify internal services. Since
# this is the same service using a different socket type, the
# id attribute is used to uniquely identify each entry
#
service echo
{
id = echo-stream
type = INTERNAL
socket_type = stream
user = root
wait = no
}
service echo
{
id = echo-dgram
type = INTERNAL
socket_type = dgram
user = root
wait = no
}
#
# Sample RPC service
#
service rstatd
{
type = RPC
socket_type = dgram
protocol = udp
server = /usr/etc/rpc.rstatd
wait = yes
user = root
rpc_version = 2-4
env = LD_LIBRARY_PATH=/etc/securelib
}
#
# Sample unlisted service
#
service unlisted
{
type = UNLISTED
socket_type = stream
Postel J., Character Generator Protocol, RFC 864, May 1983
Postel J., Daytime Protocol, RFC 867, May 1983
Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078 Nov 1988
StJohns M., Identification Protocol, RFC 1413, February 1993
BUGS
If the INTERCEPT flag is not used, access control on the address of the
remote host is not performed when wait is yes and socket_type is
stream.
If the INTERCEPT flag is not used, access control on the address of the
remote host for services where wait is yes and socket_type is dgram is
performed only on the first packet. The server may then accept packets
from hosts not in the access control list. This can happen with RPC
services.
There is no way to put a SPACE in an environment variable.
When wait is yes and socket_type is stream, the socket passed to the
server can only accept connections.
The INTERCEPT flag is not supported for internal services or multi-
threaded services.
14 June 2001 XINETD.CONF(5)
Man(1) output converted with
man2html
|