no way to compare when less than two revisions

Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.


—espec:man-xinetd.conf [2008/06/19 19:50] (atual) – created maziero
Linha 1: Linha 1:
 +** mudar para português**
  
 +<code>
 +XINETD.CONF(5)        XINETD.CONF(5)
 +
 +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  opera-
 +       tor,  '='.   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 ser-
 + vice. 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 inter-
 +     cepted).
 +
 + 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 con-
 +     nection-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  execut-
 +     ing 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  avail-
 +     able  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 subse-
 +     quent 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.
 +
 + REUSE     The REUSE flag is deprecated.   All ser-
 +     vices  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 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
 + 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.
 +
 +       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 (pos-
 + sibly negative) number; check nice(3) for more infor-
 + mation.
 +
 +       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 ser-
 + vices and the service name for redirected  services).
 + This  attribute is only valid if xinetd has been con-
 + figured 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 spec-
 +      ified 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 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
 + 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-
 +        fied   facility.   Possible   facility names
 +        include: daemon,  auth, authpriv, user, mail,
 +        lpr, news, uucp, ftp local0-7.  Possible level
 +        names  include: emerg, alert, crit, err, warn-
 +        ing, 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 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 combina-
 + tion of the following values may be specified:
 +
 + PID     logs the server process id (if  the ser-
 +     vice  is  implemented  by  xinetd without
 +     forking another process the logged pro-
 +     cess 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 oth-
 +     ers).
 +
 +       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  (there-
 + fore  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 explic-
 + itly 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  connec-
 + tion  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  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 estab-
 + lished. This banner is printed regardless of  access
 + control.   It  should *always* be printed when a con-
 + nection has been made. xinetd outputs the  file  as-
 + is,  so you must ensure the file is correctly format-
 + ted for the service's protocol. In paticular, 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 paticular, if the proto-
 + col 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 paticular, if the  proto-
 + col  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 exam-
 + ple:  2 or 2.5. The service will stop accepting con-
 + nections at this load. This is the one minute load
 + average.   This is an OS dependent feature, and cur-
 + rently only Linux, Solaris, and FreeBSD are supported
 + for  this.   This feature is only avaliable 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.   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 bet-
 + ter 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 spec-
 + ified from within a service declaration.
 +
 +       rlimit_as Sets  the  Address  Space resource limit for the ser-
 + vice. 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
 + 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 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-
 + 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 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 ser-
 +       vice.  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 ser-
 +       vice entry.  disabled determines services  that are  disabled
 +       even  if they  have  entries  in the configuration file. This
 +       allows for quick reconfiguration by  specifying  disabled ser-
 +       vices  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 ser-
 +       vices  are  assumed  to be enabled, except those listed in dis-
 +       abled.
 +
 +
 +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 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 ser-
 +       vice 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
 +       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/etc/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 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
 +    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 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
 +    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/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
 +      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
 +       {
 +      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
 +      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)
 +</code>
  • espec/man-xinetd.conf.txt
  • Última modificação: 2008/06/19 19:50
  • por maziero