Provided by: xinetd_2.3.15.3-1_amd64 bug

NAME

       xinetd.conf - Extended Internet Services Daemon configuration 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 service_name.  The following 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 standard 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
                                    multi-threaded services 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  identification
                                    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 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 tcpwrap 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).  For RPC
                                    services using TCP  transport,  this  flag  is  automatically
                                    turned  on,  because  xinetd  cannot  get remote host address
                                    information for the rpc port.

                        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 (AF_INET6), if IPv6 is
                                    available on the system.

                        LABELED     The  LABELED  flag  will  tell  xinetd  to  change  the child
                                    processes SE Linux context to  match  that  of  the  incoming
                                    connection  as  it  starts  the  service. This only works for
                                    external tcp non-waiting servers and is an error  if  applied
                                    to an internal, udp, or tcp-wait server.

                        REUSE       The  REUSE  flag  is deprecated.  All services now implicitly
                                    use the REUSE flag.

       disable          This is boolean "yes" or "no".  This will result  in  the  service  being
                        disabled and 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   reliable   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  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 attribute can  either
                        be  numeric  or  a name. If a name is given (recommended),  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 attribute can either
                        be numeric or a name. If a name is given (recommended),  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 and if the groups attribute
                        is not set to 'yes'.

       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 limit.

       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.

       libwrap          overrides the service name passed  to  libwrap  (which  defaults  to  the
                        server  name, the first server_args component with NAMEINARGS, the id for
                        internal services and the service name for  redirected  services).   This
                        attribute  is  only  valid if xinetd has been configured with the libwrap
                        option.

       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
                             components  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 Internet addresses.  IPv6 hosts may be specified in the
                             form of abcd:ef01::2345:6789.  The rightmost rule for IPv4 addresses
                             does not 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
                             specified  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. Select just one of the
                        two formats:

                        SYSLOG  syslog_facility [syslog_level]
                               The log output is  sent  to  syslog  at  the  specified  facility.
                               Possible  facility  names  include:  daemon, auth, authpriv, user,
                               mail,  lpr,  news,  uucp,  ftp  local0-7.   Possible  level  names
                               include:  emerg,  alert,  crit, err, warning, notice, info, debug.
                               If a level is not present, the messages 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 message the first time this 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 service (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.

                        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).

       rpc_version      determines the RPC version for a RPC service. 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  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  different.  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
                        ensure the file is correctly formatted for the  service's  protocol.   In
                        particular,  if  the  protocol requires CR-LF pairs for line termination,
                        you must supply them.

       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.  xinetd outputs the file as-is, so you
                        must  ensure  the file is correctly formatted for the service's protocol.
                        In particular, if the protocol requires CR-LF pairs for line termination,
                        you must supply them.

       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  particular,  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 connections per second to handle.  If the  rate
                        of  incoming  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  service  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,  Solaris,  and
                        FreeBSD are supported for this.  This feature is only available if xinetd
                        was configured with the -with-loadavg option.

       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.  Alternatively, if the  group  attribute  is
                        set,  the server is executed with access to the groups specified.  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".

       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 ID's  to  enable.   This  will  enable  only  the
                        services  listed  as  arguments  to  this  attribute;  the  rest  will be
                        disabled.  If you have 2 ftp services, you will  need  to  list  both  of
                        their  ID's  and  not  just ftp. (ftp is the service name, not the ID. It
                        might accidentally be the ID,  but  you  better  check.)  Note  that  the
                        service "disable" attribute and "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  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 representing 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  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_files     Sets  the  maximum  number  of  open files that the service may use.  One
                        parameter is required, which  is  a  positive  integer  representing  the
                        number of open file descriptors. Practical limit of this number is around
                        1024000.

       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 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 "UNLIMITED".

       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 typical time
                        value would be 60 minutes.  This  should  stop  most  DOS  attacks  while
                        allowing 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 '-=' 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
              per_source
              groups
              cps
              max_load

              Attributes with a cumulative effect can be specified multiple times
              with  the  values specified each time accumulating (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 determines services that are disabled
              even if they have  entries  in  the  configuration  file.  This  allows  for  quick
              reconfiguration 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 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  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 number of instances.

TCPMUX Services

       xinetd supports TCPMUX services that conform to RFC 1078. These services 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 TCPMUXPLUS, 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 performing 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                = TCPMUX
                     socket_type         = stream
                     protocol            = tcp
                     wait                = no
                     user                = root
                     server              = /usr/bin/my_server_exec
              }

       Besides a service entry for each service that can be accessed via  the  TCPMUX  well-known
       port, a service entry for TCPMUX itself must also be included in the xinetd configuration.
       Consider the following sample:

              service tcpmux
              {
                     type                = INTERNAL
                     id                  = tcpmux
                     socket_type         = stream
                     protocol            = tcp
                     user                = root
                     wait                = no
              }

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  table as
           system_callsxdata_sent_per_call, i.e.  each 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
                     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/sbin/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/sbin/in.rshd
                     log_on_success      += HOST
              }

              service ftp
              {
                     socket_type         = stream
                     wait                = no
                     nice                = 10
                     user                = root
                     server              = /usr/sbin/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/sbin/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/sbin/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 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.

       The NOLIBWRAP flag is automatically turned on for RPC services whose socket_type is stream
       because xinetd cannot determine the address of the remote host.

       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)