xinetd.conf - Extended Internet Services Daemon configura
tion file
DESCRIPTION
xinetd.conf is the configuration file that determines the
services provided 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 ser
vice_name. The following is a list of available
attributes:
id This attribute is used to uniquely iden
tify a service. This is useful because
there exist services that can use differ
ent protocols and need to be described
with different entries in the configura
tion 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.
UNLISTED if this is a service not
listed in a standard system
file (like /etc/rpc for RPC
services, or /etc/services
for non-RPC services).
flags Any combination of the following flags
REUSE Set the SO_REUSEADDR flag on
the service socket (check
setsockopt(2) for more infor
mation).
INTERCEPT Intercept packets or accepted
connections in order to ver
ify that they are coming from
acceptable locations (inter
nal or multi-threaded ser
vices cannot be intercepted).
NORETRY Avoid retry attempts in case
of fork failure.
IDONLY Accept connections only when
the remote end identifies the
remote user (i.e. the remote
host must run an identifica
tion server). This flag
applies only to connection-
based services. This flag is
ineffective if the USERID log
option is not used.
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 ser
vice 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.
DISABLE The DISABLE flag specifies
that this service is to be
disabled. This flag over
rides the defaults "enabled"
directive. That is, if you
say "enabled = foo", and foo
has the DISABLE flag, foo
will not start. The use of
this flag with the service
recommended, the result will
be unpredictable.
KEEPALIVE If the service is a tcp ser
vice 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 call
ing of the tcpwrap library to
determine access to the ser
vice. This may be needed in
order to use libwrap func
tionality 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.
disable This is boolean "yes" or "no". This will
not starting. See the DISABLE flag
description.
socket_type Possible values for this attribute
include:
stream stream-based service
dgram datagram-based service
raw service that requires direct
access to IP
seqpacket service that requires reli
able sequential datagram
transmission
protocol determines the protocol that is employed
by the service. 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. 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. If the attribute value
is no, the service is multi-threaded and
xinetd will keep handling new service
requests.
user determines the uid for the server pro
cess. The user name must exist in
/etc/passwd. This attribute is ineffec
tive if the effective user ID of xinetd
is not super-user.
group determines the gid for the server pro
cess. 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 ineffec
tive if the effective user ID of xinetd
is not super-user.
instances determines the number of servers that can
be simultaneously 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
nice determines the server priority. Its value
is a (possibly negative) number; check
nice(3) for more information.
server determines the program to execute for
this service.
server_args determines the arguments passed to the
server. In contrast to inetd, the server
name should not be included in
server_args.
only_from determines the remote hosts to which the
particular service is available. Its
value is a list of IP addresses which can
be specified in any combination of the
following ways:
a) a numeric address in the form of
%d.%d.%d.%d. If the rightmost compo
nents are 0, they are treated as
wildcards (for example, 128.138.12.0
matches all hosts on the 128.138.12
subnet). 0.0.0.0 matches all Inter
net 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.
c) a network name (from /etc/networks)
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.
Specifying this attribute without a value
makes the service available to nobody.
no_access determines the remote hosts to which the
value can be specified in the same way as
the value of the only_from attribute.
These two attributes determine the loca
tion access control enforced by xinetd.
If none of the two is specified for a
service, the service is available to any
one. 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 con
tains 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 inter
val). 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 specified facility. Possi
ble facility names include: dae
mon, auth, authpriv, user,
local0-7. Possible level names
include: emerg, alert, crit, err,
warning, notice, info, debug. If
a level is not present, the mes
sages will be recorded at the info
level.
FILE file [soft_limit [hard_limit]]
The log output is appended to file
which will be created if it does
not exist. Two limits on the size
of the log file can be optionally
specified. The first limit is a
soft one; xinetd will log a mes
sage the first time this limit is
exceeded (if xinetd logs to sys
log, the message will be sent at
the alert priority level). The
second limit is a hard limit;
xinetd will stop logging for the
affected service (if the log file
is a common log file, then more
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 con
stants are defined in config.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 combina
tion of the following values may be spec
ified:
PID logs the server process id
(if the service is imple
mented 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 ser
vice session
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 ser
vice id is always included in the log
entry along with the reason for failure.
Any combination of the following values
may be specified:
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.
ATTEMPT logs the fact that a failed
attempt was made (this option
is implied by all others).
RECORD records information from the
remote end in case the server
could not be started. This
allows monitoring of attempts
to use the service. For
example, the login service
logs the local user, remote
user and terminal type. Cur
rently, the services that
support this option are:
login, shell, exec, finger.
rpc_version determines the RPC version for a RPC ser
vice. The version can be a single number
or a range in the form number-number.
rpc_number determines the number for an UNLISTED RPC
service (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 environment plus the specified
strings).
passenv The value of this attribute is a list of
environment variables from xinetd's envi
ronment 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 argu
ment will be passed to the server).
port determines the service port. If this
attribute is specified for a service
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 pro
cess that establishes a connection to the
host and port number specified, and for
wards 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 per
formed 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 spe
cific interface on the machine. This
means you can have a telnet server lis
tening 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 inter
face can do something completely differ
ent. 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 con
nection has been made.
banner_success Takes the name of a file to be splatted
at the remote host when a connection to
that service is granted. This banner is
printed as soon as access is granted for
the service.
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
bad and they shouldn't be doing it any
more.
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 connections per second
to handle. If the rate of incoming con
nections is higher than this, the service
will be temporarily disabled. The second
argument is the number of seconds to wait
before re-enabling the service after it
has been disabled.
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 sys
tems. This attribute can be set in the
defaults section as well.
umask Sets the inherited umask for the service.
Expects an octal value. This option may
be set in the "defaults" section to set a
umask for all services. xinetd sets its
own umask to the previous umask OR'd with
022. This is the umask that will be
inherited by all child processes if the
umask option is not used.
enabled Takes a list of service names to enable.
This will enable only the services listed
as arguments to this attribute; the rest
will be disabled. Not that the service
"disable" attribute and "DISABLE" flag
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 direc
tive is given. The included file must be
in the same form as xinetd.conf. This
may not be specified from within a ser
vice. 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 end
ing 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 specified 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 repre
senting the number of bytes to set the
limit to (K or M may be used to specify
kilobytes/megabytes) or "UNLIMITED". Due
to the way Linux's libc malloc is imple
mented, 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 service 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 service. 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 service. Setting this value low
will make the process a likely candidate
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 repre
senting the number of bytes or "UNLIM
ITED".
deny_time Sets the time span that access to all
services on all IP addresses are denied
to someone that sets off the SENSOR. The
unit of time is in minutes. Valid
options are: FOREVER, NEVER, and a
numeric value. FOREVER causes the IP
address not to be purged until xinetd is
restarted. NEVER has the effect of just
logging the offending IP address. A typi
cal time value would be 60 minutes. This
should stop most DOS attacks while allow
ing IP addresses that come from a pool to
be recycled for legitimate purposes. This
option must be used in conjunction with
the SENSOR flag.
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 '-=' opera
tor)
These attributes can also appear more than once in a ser
vice 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
defaults
{
<attribute> = <value> <value> ...
...
}
This entry provides default attribute values for service
entries that don't specify those attributes. Possible
default attributes:
log_type
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)
Attributes with a cumulative effect can be specified mul
tiple times with the values specified each time accumulat
ing (i.e. '=' does the same thing as '+='). With the
exception of disabled they all have the same meaning as if
they were specified in a service entry. disabled deter
mines services that are disabled even if they have entries
in the configuration file. This allows for quick reconfig
uration by specifying disabled services with the disabled
attribute instead of commenting them out. The value of
this attribute is a list of space separated service ids.
enabled has the same properties as disabled. The differ
ence 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 services 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, chargen, and discard) have no limitation in the num
ber of instances.
xinetd also provides two UNLISTED internal stream-based
services: servers and services. The former lists informa
tion about running servers while the latter provides a
list of currently active services. There is one service
(e.g. "tcp") and port number.
There is also now an administrative interface that is an
internal service. The service name "xadmin" is reserved,
and will always be an internal service. You should spec
ify a port number for this service, and probably also some
IP based access control, since at the time of this writing
it does not have any password protection. You can telnet
to this port and query xinetd for some information.
NOTES
1. The following service attributes cannot be changed on
reconfiguration: 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 considered 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 reconfigured. 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 various datagram sizes. For TCP-
based services we measured the bandwidth 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
send(2) system call transferred so many bytes of data.
The bandwidth reduction is given in terms of bytes per
second and as a percentage of the bandwidth when
interception is not performed. All measurements were
done on a SparcStation IPC running SunOS 4.1.
Datagram size (bytes) Latency (msec)
--------------------- --------------
64 1.19
256 1.51
1024 1.51
4096 3.58
Bytes sent Bandwidth reduction
---------- -------------------
10000x64 941 (1.2%)
10000x256 4,231 (1.8%)
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 RECORD
only_from = 128.138.193.0 128.138.204.0 128.138.209.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
#
service shell
{
socket_type = stream
wait = no
user = root
instances = UNLIMITED
server = /usr/etc/in.rshd
log_on_success += HOST RECORD
}
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.ftpd
server_args = -l
instances = 4
log_on_success += DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
# Limit telnet sessions to 8 Mbytes of memory and a total
# 20 CPU seconds for child processes.
service telnet
{
socket_type = stream
wait = no
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
{
type = INTERNAL
socket_type = dgram
user = root
wait = no
}
service servers
{
type = INTERNAL UNLISTED
protocol = tcp
port = 9099
socket_type = stream
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
protocol = tcp
wait = no
server = /home/user/some_server
port = 20020
}
SEE ALSO
xinetd(1L),
xinetd.log(5)
Postel J., Echo Protocol , RFC 862, May 1983
Postel J., Discard Protocol , RFC 863, May 1983
Postel J., Character Generator Protocol , RFC 864, May
Postel J., Daytime Protocol , RFC 867, May 1983
Postel J., Harrenstien K., Time Protocol , RFC 868, May
1983
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 ser
vices.
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.
Man(1) output converted with
man2html