Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
XINETD.CONF(5)		      File Formats Manual		XINETD.CONF(5)

NAME
       xinetd.conf - Extended Internet Services	Daemon configuration file

DESCRIPTION
       xinetd.conf is the configuration	file that determines the services pro-
       vided by	xinetd.	 Any line whose	first non-white-space character	 is  a
       '#' is considered a comment line. Empty lines are ignored.

       The file	contains entries of the	form:

	      service <service_name>
	      {
		     <attribute> <assign_op> <value> <value> ...
		     ...
	      }

       The assignment operator,	assign_op, can be one of '=', '+=', '-='.  The
       majority	of attributes support only  the	 simple	 assignment  operator,
       '='.   Attributes whose value is	a set of values	support	all assignment
       operators.  For such attributes,	'+=' means adding a value to  the  set
       and  '-='  means	 removing  a  value  from  the	set.   A list of these
       attributes will be given	after all the attributes are described.

       Each entry defines a service identified by the service_name.  The  fol-
       lowing is a list	of available attributes:

       id		This attribute is used to uniquely identify a service.
			This is	useful because there exist services  that  can
			use  different protocols and need to be	described with
			different  entries  in	the  configuration  file.   By
			default,  the  service	id  is the same	as the service
			name.

       type		Any combination	of the following values	may be used:

			RPC	    if this is an RPC service

			INTERNAL    if this is a service provided by xinetd.

			TCPMUX/TCPMUXPLUS
				    if this is a service that will be  started
				    according  to the RFC 1078 protocol	on the
				    TCPMUX well-known port.  See  the  section
				    describing TCPMUX services below.

			UNLISTED    if this is a service not listed in a stan-
				    dard system	file (like  /etc/rpc  for  RPC
				    services,  or  /etc/services  for  non-RPC
				    services).

       flags		Any combination	of the following flags may be used:

			INTERCEPT   Intercept packets or accepted  connections
				    in	order  to  verify that they are	coming
				    from  acceptable  locations	 (internal  or
				    multi-threaded  services  cannot be	inter-
				    cepted).

			NORETRY	    Avoid retry	attempts in case of fork fail-
				    ure.

			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 executing
				    the	 server,  as  specified	 in  "server".
				    This allows	you to	use  tcpd  by  putting
				    tcpd  in  "server"	and  the  name	of the
				    server in  "server_args"  like  in	normal
				    inetd.

			NODELAY	    If	the  service  is a tcp service and the
				    NODELAY flag is set, then the  TCP_NODELAY
				    flag  will	be  set	on the socket.	If the
				    service is not a tcp service, this	option
				    has	no effect.

			KEEPALIVE   If	the  service  is a tcp service and the
				    KEEPALIVE	flag   is   set,   then	   the
				    SO_KEEPALIVE  socket  flag	will be	set on
				    the	socket.	 If the	service	is not	a  tcp
				    service, this option has no	effect.

			NOLIBWRAP   This disables internal calling of the tcp-
				    wrap library to determine  access  to  the
				    service.   This  may be needed in order to
				    use	libwrap	functionality not available to
				    long-running  processes such as xinetd; in
				    this case, the tcpd	program	can be	called
				    explicitly (see also the NAMEINARGS	flag).
				    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 con-
				    text to match that of the incoming connec-
				    tion  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  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 and if the groups attribute is not  set
			to 'yes'.

       instances	determines  the	number of servers that can be simulta-
			neously	active	for  a	service	 (the  default	is  no
			limit).	 The  value  of	this attribute can be either a
			number or UNLIMITED  which  means  that	 there	is  no
			limit.

       nice		determines the server priority.	Its value is a (possi-
			bly negative) number; check nice(3) for	more  informa-
			tion.

       server		determines the program to execute for this service.

       server_args	determines the arguments passed	to the server. In con-
			trast to inetd,	the server name	should not be included
			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	speci-
			     fied host name.  You may also use domain names in
			     the form of .domain.com.  If the  reverse	lookup
			     of	the client's IP	is within .domain.com, a match
			     occurs.

			e)   an	 ip  address/netmask  range  in	 the  form  of
			     1.2.3.4/32.   IPv6	 address/netmask ranges	in the
			     form of 1234::/46 are also	valid.

			Specifying this	attribute without a  value  makes  the
			service	available to nobody.

       no_access	determines  the	 remote	 hosts to which	the particular
			service	is unavailable.	Its value can be specified  in
			the  same way as the value of the only_from attribute.
			These two attributes  determine	 the  location	access
			control	 enforced  by  xinetd.	If  none of the	two is
			specified for a	service, the service is	 available  to
			anyone.	 If  both are specified	for a service, the one
			that is	the better match for the address of the	remote
			host  determines  if  the service is available to that
			host (for example,  if	the  only_from	list  contains
			128.138.209.0	and   the   no_access	list  contains
			128.138.209.10	then  the  host	  with	 the   address
			128.138.209.10 can not access the service).

       access_times	determines  the	 time  intervals  when	the service is
			available. An interval has the form  hour:min-hour:min
			(connections  will  be	accepted  at  the bounds of an
			interval). Hours can range from	0 to  23  and  minutes
			from 0 to 59.

       log_type		determines where the service log output	is sent. There
			are two	formats:

			SYSLOG	syslog_facility	[syslog_level]
			       The log output is sent to syslog	at the	speci-
			       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,  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 ser-
			       vice (if	the log	file is	 a  common  log	 file,
			       then more than one service may be affected) and
			       will log	a message about	this (if  xinetd  logs
			       to  syslog,  the	 message  will	be sent	at the
			       alert priority level).  If a hard limit is  not
			       specified,   it	defaults  to  the  soft	 limit
			       increased by 1% but  the	 extra	size  must  be
			       within	the   parameters   LOG_EXTRA_MIN   and
			       LOG_EXTRA_MAX  which  default  to  5K  and  20K
			       respectively  (these  constants	are defined in
			       xconfig.h).

       log_on_success	determines what	information is logged when a server is
			started	 and when that server exits (the service id is
			always included	in the log entry).  Any	combination of
			the following values may be specified:

			PID	    logs the server process id (if the service
				    is implemented by xinetd  without  forking
				    another process the	logged process id will
				    be 0)

			HOST	    logs the remote host address

			USERID	    logs the user id of	the remote user	 using
				    the	  RFC  1413  identification  protocol.
				    This option	is available only  for	multi-
				    threaded stream services.

			EXIT	    logs  the  fact that a server exited along
				    with the exit status  or  the  termination
				    signal  (the  process id is	also logged if
				    the	PID option is used)

			DURATION    logs the duration of a service session

			TRAFFIC	    logs the total bytes  in  and  out	for  a
				    redirected service.

       log_on_failure	determines  what  information  is logged when a	server
			cannot	be  started  (either  because  of  a  lack  of
			resources  or because of access	control	restrictions).
			The service id is always included  in  the  log	 entry
			along with the reason for failure.  Any	combination of
			the following values may be specified:

			HOST	    logs the remote host address.

			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 ver-
			sion 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	 envi-
			ronment	plus the specified strings).

       passenv		The  value  of this attribute is a list	of environment
			variables  from	 xinetd's  environment	that  will  be
			passed	to  the	server.	 An empty list implies passing
			no variables to	the server except for those explicitly
			defined	using the env attribute.  (notice that you can
			use  this  attribute  in  conjunction  with  the   env
			attribute  to specify exactly what environment will be
			passed to the server).

       port		determines the service	port.  If  this	 attribute  is
			specified  for	a  service listed in /etc/services, it
			must be	equal to the port number listed	in that	file.

       redirect		Allows a tcp service to	be redirected to another host.
			When  xinetd receives a	tcp connection on this port it
			spawns a process that establishes a connection to  the
			host  and port number specified, and forwards all data
			between	the two	hosts.	This  option  is  useful  when
			your  internal machines	are not	visible	to the outside
			world.	Syntax is: redirect  =	(ip  address)  (port).
			You  can also use a hostname instead of	the IP address
			in this	field.	The hostname lookup is performed  only
			once, when xinetd is started, and the first IP address
			returned is the	one  that  is  used  until  xinetd  is
			restarted.   The  "server"  attribute  is not required
			when  this  option  is	specified.   If	 the  "server"
			attribute is specified,	this attribute takes priority.

       bind		Allows	a  service to be bound to a specific interface
			on the machine.	 This means  you  can  have  a	telnet
			server	listening  on  a local,	secured	interface, and
			not on the external interface.	Or  one	 port  on  one
			interface  can	do something, while the	same port on a
			different interface can	do something  completely  dif-
			ferent.	 Syntax: bind =	(ip address of interface).

       interface	Synonym	for bind.

       banner		Takes  the name	of a file to be	splatted at the	remote
			host when a connection to that service is established.
			This  banner  is printed regardless of access control.
			It should *always* be printed when  a  connection  has
			been made.  xinetd outputs the file as-is, so you must
			ensure the file	is correctly formatted	for  the  ser-
			vice'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 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 paticular, if the protocol
			requires CR-LF pairs for line  termination,  you  must
			supply them.

       per_source	Takes  an integer or "UNLIMITED" as an argument.  This
			specifies the maximum instances	of  this  service  per
			source	IP address.  This can also be specified	in the
			defaults section.

       cps		Limits the rate	of incoming  connections.   Takes  two
			arguments.   The  first	argument is the	number of con-
			nections per second to handle.	If the rate of	incom-
			ing  connections is higher than	this, the service will
			be temporarily disabled.  The second argument  is  the
			number	of seconds to wait before re-enabling the ser-
			vice after it has been disabled.  The default for this
			setting	is 50 incoming connections and the interval is
			10 seconds.

       max_load		Takes a	floating point value as	the load at which  the
			service	will stop accepting connections.  For example:
			2 or 2.5.  The service will stop accepting connections
			at  this  load.	  This is the one minute load average.
			This is	an OS dependent	feature,  and  currently  only
			Linux,	Solaris,  and  FreeBSD are supported for this.
			This feature is	only avaliable if xinetd  was  config-
			ured 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	speci-
			fied from within a service declaration.

       rlimit_as	Sets the Address Space resource	limit for the service.
			One parameter is required, which is either a  positive
			integer	 representing  the  number of bytes to set the
			limit to  (K  or  M  may  be  used  to	specify	 kilo-
			bytes/megabytes)  or  "UNLIMITED".   Due  to  the  way
			Linux's	libc malloc is implemented, it is more	useful
			to  set	 this  limit  than rlimit_data,	rlimit_rss and
			rlimit_stack. This resource limit is only  implemented
			on Linux systems.

       rlimit_cpu	Sets  the  maximum number of CPU seconds that the ser-
			vice may use.  One parameter  is  required,  which  is
			either	a  positive integer representing the number of
			CPU seconds limit to, or "UNLIMITED".

       rlimit_data	Sets the maximum data size resource limit for the ser-
			vice.	One  parameter	is required, which is either a
			positive integer representing the number of  bytes  or
			"UNLIMITED".

       rlimit_rss	Sets  the maximum resident set size limit for the ser-
			vice.  Setting this value low will make	the process  a
			likely	candidate for swapping out to disk when	memory
			is low.	 One parameter is required, which is either  a
			positive  integer  representing	the number of bytes or
			"UNLIMITED".

       rlimit_stack	Set the	maximum	stack size limit for the service.  One
			parameter  is  required,  which	 is  either a positive
			integer	representing the number	of  bytes  or  "UNLIM-
			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 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 mul-
	      tiple 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 ser-
       vices  are  under  the  same  access restrictions as all	other services
       except for the ones that	don't require xinetd to	fork  another  process
       for them. Those ones (time, daytime, and	the datagram-based echo, char-
       gen, and	discard) have no limitation in the number of instances.

TCPMUX Services
       xinetd supports TCPMUX services that conform to RFC  1078.  These  ser-
       vices  may  not have a well-known port associated with them, and	can be
       accessed	via the	TCPMUX well-known port.

       For each	service	that is	to be accessed via TCPMUX, a service entry  in
       /etc/xinetd.conf	 or in a configuration file in an includedir directory
       must exist.

       The service_name	field (as defined above	for each service in any	xinetd
       configuration  file)  must  be  identical  to the string	that is	passed
       (according to RFC 1078 protocol)	to  xinetd  when  the  remote  service
       requestor  first	 makes	the  connection	on the TCPMUX well-known port.
       Private protocols should	use a service name that	has a high probability
       of  being unique. One way is to prepend the service name	with some form
       of organization ID.

       The type	field can be either TCPMUX or TCPMUXPLUS. If the type is  TCP-
       MUXPLUS,	 xinetd	will handle the	initial	protocol handshake (as defined
       in RFC 1078) with the calling process before initiating the service. If
       the  type is TCPMUX, the	server that is started is responsible for per-
       forming the handshake.

       The type	field should also include  UNLISTED  if	 the  service  is  not
       listed  in  a  standard system file (like /etc/rpc for RPC services, or
       /etc/services for non-RPC services).

       The socket_type for these services must be  stream,  and	 the  protocol
       must be tcp.

       Following is a sample TCPMUX service configuration:

	      service myorg_server
	      {
		     disable		 = no
		     type		 = 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 con-
	   sidered successful (i.e. access will	not be denied).

       3.  The address check is	based on the IP	address	of the remote host and
	   not	on  its	domain address.	We do this so that we can avoid	remote
	   name	lookups	which may take a long time (since  xinetd  is  single-
	   threaded,  a	name lookup will prevent the daemon from accepting any
	   other requests until	the lookup is resolved).   The	down  side  of
	   this	 scheme	 is  that  if the IP address of	a remote host changes,
	   then	access to that host may	be denied until	 xinetd	 is  reconfig-
	   ured.   Whether  access  is	actually  denied or not	will depend on
	   whether the new host	IP address is among those allowed access.  For
	   example,  if	 the  IP  address  of  a  host changes from 1.2.3.4 to
	   1.2.3.5 and only_from is specified as 1.2.3.0 then access will  not
	   be denied.

       4.  If  the  USERID  log	option is specified and	the remote host	either
	   does	not run	an identification server or the	server	sends  back  a
	   bad reply, access will not be denied	unless the IDONLY service flag
	   is used.

       5.  Interception	works by forking a process  which  acts	 as  a	filter
	   between  the	 remote	 host(s) and the local server.	This obviously
	   has a performance impact so it is up	to you to make the  compromise
	   between  security  and performance for each service.	 The following
	   tables show the overhead of interception.  The  first  table	 shows
	   the	time overhead-per-datagram for a UDP-based service using vari-
	   ous datagram	sizes.	For TCP-based services we measured  the	 band-
	   width  reduction  because  of  interception while sending a certain
	   amount of data from client to server	(the time overhead should  the
	   same	 as  for UDP-based services but	it is "paid" only by the first
	   packet of a continuous data transmission).  The amount of  data  is
	   given  in  the table	as system_callsxdata_sent_per_call, i.e.  each
	   send(2) system call transferred so many bytes of data.   The	 band-
	   width reduction is given in terms of	bytes per second and as	a per-
	   centage of the bandwidth when interception is not  performed.   All
	   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)

NAME | DESCRIPTION | INTERNAL SERVICES | TCPMUX Services | NOTES | EXAMPLE | SEE ALSO | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=xinetd.conf&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help