1XINETD.CONF(5) File Formats Manual XINETD.CONF(5)
2
6 xinetd.conf - Extended Internet Services Daemon configuration file
7
9 xinetd.conf is the configuration file that determines the services pro‐
10 vided by xinetd. Any line whose first non-white-space character is a
11 '#' is considered a comment line. Empty lines are ignored.
12 The file contains entries of the form:
14 service <service_name>
16 {
17 <attribute> <assign_op> <value> <value> ...
18 ...
19 }
20 The assignment operator, assign_op, can be one of '=', '+=', '-='. The
22 majority of attributes support only the simple assignment operator,
23 '='. Attributes whose value is a set of values support all assignment
24 operators. For such attributes, '+=' means adding a value to the set
25 and '-=' means removing a value from the set. A list of these
26 attributes will be given after all the attributes are described.
27 Each entry defines a service identified by the service_name. The fol‐
29 lowing is a list of available attributes:
30 id This attribute is used to uniquely identify a service.
32 This is useful because there exist services that can
33 use different protocols and need to be described with
34 different entries in the configuration file. By
35 default, the service id is the same as the service
36 name.
37 type Any combination of the following values may be used:
39 RPC if this is an RPC service
41 INTERNAL if this is a service provided by xinetd.
43 TCPMUX/TCPMUXPLUS
45 if this is a service that will be started
46 according to the RFC 1078 protocol on the
47 TCPMUX well-known port. See the section
48 describing TCPMUX services below.
49 UNLISTED if this is a service not listed in a stan‐
51 dard system file (like /etc/rpc for RPC
52 services, or /etc/services for non-RPC
53 services).
54 flags Any combination of the following flags may be used:
56 INTERCEPT Intercept packets or accepted connections
58 in order to verify that they are coming
59 from acceptable locations (internal or
60 multi-threaded services cannot be inter‐
61 cepted).
62 NORETRY Avoid retry attempts in case of fork fail‐
64 ure.
65 IDONLY Accept connections only when the remote
67 end identifies the remote user (i.e. the
68 remote host must run an identification
69 server). This flag applies only to con‐
70 nection-based services. This flag is
71 ineffective if the USERID log option is
72 not used.
73 NAMEINARGS This will cause the first argument in
75 "server_args" to be argv[0] when executing
76 the server, as specified in "server".
77 This allows you to use tcpd by putting
78 tcpd in "server" and the name of the
79 server in "server_args" like in normal
80 inetd.
81 NODELAY If the service is a tcp service and the
83 NODELAY flag is set, then the TCP_NODELAY
84 flag will be set on the socket. If the
85 service is not a tcp service, this option
86 has no effect.
87 KEEPALIVE If the service is a tcp service and the
89 KEEPALIVE flag is set, then the
90 SO_KEEPALIVE socket flag will be set on
91 the socket. If the service is not a tcp
92 service, this option has no effect.
93 NOLIBWRAP This disables internal calling of the tcp‐
95 wrap library to determine access to the
96 service. This may be needed in order to
97 use libwrap functionality not available to
98 long-running processes such as xinetd; in
99 this case, the tcpd program can be called
100 explicitly (see also the NAMEINARGS flag).
101 For RPC services using TCP transport, this
102 flag is automatically turned on, because
103 xinetd cannot get remote host address
104 information for the rpc port.
105 SENSOR This replaces the service with a sensor
107 that detects accesses to the specified
108 port. NOTE: It will NOT detect stealth
109 scans. This flag should be used only on
110 services that you know you don't need.
111 When an access is made to this service's
112 port, the IP Address is added to a global
113 no_access list. This causes all subsequent
114 accesses from the originating IP address
115 to be denied access until the deny_time
116 setting expires. The amount of time spent
117 on this list is configurable as the
118 deny_time attribute. The SENSOR flag will
119 also cause xinetd to consider the server
120 attribute to be INTERNAL no matter what is
121 typed on the same line. Another important
122 thing to remember is that if the
123 socket_type is set to stream, then the
124 wait attribute should be set to no.
125 IPv4 Sets the service to be an IPv4 service
127 (AF_INET).
128 IPv6 Sets the service to be an IPv6 service
130 (AF_INET6), if IPv6 is available on the
131 system.
132 LABELED The LABELED flag will tell xinetd to
134 change the child processes SE Linux con‐
135 text to match that of the incoming connec‐
136 tion as it starts the service. This only
137 works for external tcp non-waiting servers
138 and is an error if applied to an internal,
139 udp, or tcp-wait server.
140 REUSE The REUSE flag is deprecated. All ser‐
142 vices now implicitly use the REUSE flag.
143 disable This is boolean "yes" or "no". This will result in
145 the service being disabled and not starting. See the
146 DISABLE flag description.
147 socket_type Possible values for this attribute include:
149 stream stream-based service
151 dgram datagram-based service
153 raw service that requires direct access to IP
155 seqpacket service that requires reliable sequential
157 datagram transmission
158 protocol determines the protocol that is employed by the ser‐
160 vice. The protocol must exist in /etc/protocols. If
161 this attribute is not defined, the default protocol
162 employed by the service will be used.
163 wait This attribute determines if the service is single-
165 threaded or multi-threaded and whether or not xinetd
166 accepts the connection or the server program accepts
167 the connection. If its value is yes, the service is
168 single-threaded; this means that xinetd will start the
169 server and then it will stop handling requests for the
170 service until the server dies and that the server
171 software will accept the connection. If the attribute
172 value is no, the service is multi-threaded and xinetd
173 will keep handling new service requests and xinetd
174 will accept the connection. It should be noted that
175 udp/dgram services normally expect the value to be yes
176 since udp is not connection oriented, while tcp/stream
177 servers normally expect the value to be no.
178 user determines the uid for the server process. The user
180 attribute can either be numeric or a name. If a name
181 is given (recommended), the user name must exist in
182 /etc/passwd. This attribute is ineffective if the
183 effective user ID of xinetd is not super-user.
184 group determines the gid for the server process. The group
186 attribute can either be numeric or a name. If a name
187 is given (recommended), the group name must exist in
188 /etc/group. If a group is not specified, the group of
189 user will be used (from /etc/passwd). This attribute
190 is ineffective if the effective user ID of xinetd is
191 not super-user and if the groups attribute is not set
192 to 'yes'.
193 instances determines the number of servers that can be simulta‐
195 neously active for a service (the default is no
196 limit). The value of this attribute can be either a
197 number or UNLIMITED which means that there is no
198 limit.
199 nice determines the server priority. Its value is a (possi‐
201 bly negative) number; check nice(3) for more informa‐
202 tion.
203 server determines the program to execute for this service.
205 server_args determines the arguments passed to the server. In con‐
207 trast to inetd, the server name should not be included
208 in server_args.
209 +.B libwrap overrides the service name passed to libwrap (which
211 defaults to the server name, the first server_args
212 component with NAMEINARGS, the id for internal ser‐
213 vices and the service name for redirected services).
214 This attribute is only valid if xinetd has been con‐
215 figured with the libwrap option.
216 only_from determines the remote hosts to which the particular
218 service is available. Its value is a list of IP
219 addresses which can be specified in any combination of
220 the following ways:
221 a) a numeric address in the form of %d.%d.%d.%d. If
223 the rightmost components are 0, they are treated
224 as wildcards (for example, 128.138.12.0 matches
225 all hosts on the 128.138.12 subnet). 0.0.0.0
226 matches all Internet addresses. IPv6 hosts may
227 be specified in the form of abcd:ef01::2345:6789.
228 The rightmost rule for IPv4 addresses does not
229 apply to IPv6 addresses.
230 b) a factorized address in the form of
232 %d.%d.%d.{%d,%d,...}. There is no need for all 4
233 components (i.e. %d.%d.{%d,%d,...%d} is also ok).
234 However, the factorized part must be at the end
235 of the address. This form does not work for IPv6
236 hosts.
237 c) a network name (from /etc/networks). This form
239 does not work for IPv6 hosts.
240 d) a host name. When a connection is made to
242 xinetd, a reverse lookup is performed, and the
243 canonical name returned is compared to the speci‐
244 fied host name. You may also use domain names in
245 the form of .domain.com. If the reverse lookup
246 of the client's IP is within .domain.com, a match
247 occurs.
248 e) an ip address/netmask range in the form of
250 1.2.3.4/32. IPv6 address/netmask ranges in the
251 form of 1234::/46 are also valid.
252 Specifying this attribute without a value makes the
254 service available to nobody.
255 no_access determines the remote hosts to which the particular
257 service is unavailable. Its value can be specified in
258 the same way as the value of the only_from attribute.
259 These two attributes determine the location access
260 control enforced by xinetd. If none of the two is
261 specified for a service, the service is available to
262 anyone. If both are specified for a service, the one
263 that is the better match for the address of the remote
264 host determines if the service is available to that
265 host (for example, if the only_from list contains
266 128.138.209.0 and the no_access list contains
267 128.138.209.10 then the host with the address
268 128.138.209.10 can not access the service).
269 access_times determines the time intervals when the service is
271 available. An interval has the form hour:min-hour:min
272 (connections will be accepted at the bounds of an
273 interval). Hours can range from 0 to 23 and minutes
274 from 0 to 59.
275 log_type determines where the service log output is sent. There
277 are two formats:
278 SYSLOG syslog_facility [syslog_level]
280 The log output is sent to syslog at the speci‐
281 fied facility. Possible facility names include:
282 daemon, auth, authpriv, user, mail, lpr, news,
283 uucp, ftp local0-7. Possible level names
284 include: emerg, alert, crit, err, warning,
285 notice, info, debug. If a level is not
286 present, the messages will be recorded at the
287 info level.
288 FILE file [soft_limit [hard_limit]]
290 The log output is appended to file which will
291 be created if it does not exist. Two limits on
292 the size of the log file can be optionally
293 specified. The first limit is a soft one;
294 xinetd will log a message the first time this
295 limit is exceeded (if xinetd logs to syslog,
296 the message will be sent at the alert priority
297 level). The second limit is a hard limit;
298 xinetd will stop logging for the affected ser‐
299 vice (if the log file is a common log file,
300 then more than one service may be affected) and
301 will log a message about this (if xinetd logs
302 to syslog, the message will be sent at the
303 alert priority level). If a hard limit is not
304 specified, it defaults to the soft limit
305 increased by 1% but the extra size must be
306 within the parameters LOG_EXTRA_MIN and
307 LOG_EXTRA_MAX which default to 5K and 20K
308 respectively (these constants are defined in
309 xconfig.h).
310 log_on_success determines what information is logged when a server is
312 started and when that server exits (the service id is
313 always included in the log entry). Any combination of
314 the following values may be specified:
315 PID logs the server process id (if the service
317 is implemented by xinetd without forking
318 another process the logged process id will
319 be 0)
320 HOST logs the remote host address
322 USERID logs the user id of the remote user using
324 the RFC 1413 identification protocol.
325 This option is available only for multi-
326 threaded stream services.
327 EXIT logs the fact that a server exited along
329 with the exit status or the termination
330 signal (the process id is also logged if
331 the PID option is used)
332 DURATION logs the duration of a service session
334 TRAFFIC logs the total bytes in and out for a
336 redirected service.
337 log_on_failure determines what information is logged when a server
339 cannot be started (either because of a lack of
340 resources or because of access control restrictions).
341 The service id is always included in the log entry
342 along with the reason for failure. Any combination of
343 the following values may be specified:
344 HOST logs the remote host address.
346 USERID logs the user id of the remote user using
348 the RFC 1413 identification protocol.
349 This option is available only for multi-
350 threaded stream services.
351 ATTEMPT logs the fact that a failed attempt was
353 made (this option is implied by all oth‐
354 ers).
355 rpc_version determines the RPC version for a RPC service. The ver‐
357 sion can be a single number or a range in the form
358 number-number.
359 rpc_number determines the number for an UNLISTED RPC service
361 (this attribute is ignored if the service is not
362 unlisted).
363 env The value of this attribute is a list of strings of
365 the form 'name=value'. These strings will be added to
366 the environment before starting a server (therefore
367 the server's environment will include xinetd's envi‐
368 ronment plus the specified strings).
369 passenv The value of this attribute is a list of environment
371 variables from xinetd's environment that will be
372 passed to the server. An empty list implies passing
373 no variables to the server except for those explicitly
374 defined using the env attribute. (notice that you can
375 use this attribute in conjunction with the env
376 attribute to specify exactly what environment will be
377 passed to the server).
378 port determines the service port. If this attribute is
380 specified for a service listed in /etc/services, it
381 must be equal to the port number listed in that file.
382 redirect Allows a tcp service to be redirected to another host.
384 When xinetd receives a tcp connection on this port it
385 spawns a process that establishes a connection to the
386 host and port number specified, and forwards all data
387 between the two hosts. This option is useful when
388 your internal machines are not visible to the outside
389 world. Syntax is: redirect = (ip address) (port).
390 You can also use a hostname instead of the IP address
391 in this field. The hostname lookup is performed only
392 once, when xinetd is started, and the first IP address
393 returned is the one that is used until xinetd is
394 restarted. The "server" attribute is not required
395 when this option is specified. If the "server"
396 attribute is specified, this attribute takes priority.
397 bind Allows a service to be bound to a specific interface
399 on the machine. This means you can have a telnet
400 server listening on a local, secured interface, and
401 not on the external interface. Or one port on one
402 interface can do something, while the same port on a
403 different interface can do something completely dif‐
404 ferent. Syntax: bind = (ip address of interface).
405 interface Synonym for bind.
407 banner Takes the name of a file to be splatted at the remote
409 host when a connection to that service is established.
410 This banner is printed regardless of access control.
411 It should *always* be printed when a connection has
412 been made. xinetd outputs the file as-is, so you must
413 ensure the file is correctly formatted for the ser‐
414 vice's protocol. In paticular, if the protocol
415 requires CR-LF pairs for line termination, you must
416 supply them.
417 banner_success Takes the name of a file to be splatted at the remote
419 host when a connection to that service is granted.
420 This banner is printed as soon as access is granted
421 for the service. xinetd outputs the file as-is, so
422 you must ensure the file is correctly formatted for
423 the service's protocol. In paticular, if the protocol
424 requires CR-LF pairs for line termination, you must
425 supply them.
426 banner_fail Takes the name of a file to be splatted at the remote
428 host when a connection to that service is denied.
429 This banner is printed immediately upon denial of
430 access. This is useful for informing your users that
431 they are doing something bad and they shouldn't be
432 doing it anymore. xinetd outputs the file as-is, so
433 you must ensure the file is correctly formatted for
434 the service's protocol. In paticular, if the protocol
435 requires CR-LF pairs for line termination, you must
436 supply them.
437 per_source Takes an integer or "UNLIMITED" as an argument. This
439 specifies the maximum instances of this service per
440 source IP address. This can also be specified in the
441 defaults section.
442 cps Limits the rate of incoming connections. Takes two
444 arguments. The first argument is the number of con‐
445 nections per second to handle. If the rate of incom‐
446 ing connections is higher than this, the service will
447 be temporarily disabled. The second argument is the
448 number of seconds to wait before re-enabling the ser‐
449 vice after it has been disabled. The default for this
450 setting is 50 incoming connections and the interval is
451 10 seconds.
452 max_load Takes a floating point value as the load at which the
454 service will stop accepting connections. For example:
455 2 or 2.5. The service will stop accepting connections
456 at this load. This is the one minute load average.
457 This is an OS dependent feature, and currently only
458 Linux, Solaris, and FreeBSD are supported for this.
459 This feature is only avaliable if xinetd was config‐
460 ured with the -with-loadavg option.
461 groups Takes either "yes" or "no". If the groups attribute
463 is set to "yes", then the server is executed with
464 access to the groups that the server's effective UID
465 has access to. Alternatively, if the group attribute
466 is set, the server is executed with access to the
467 groups specified. If the groups attribute is set to
468 "no", then the server runs with no supplementary
469 groups. This attribute must be set to "yes" for many
470 BSD systems. This attribute can be set in the
471 defaults section as well.
472 mdns Takes either "yes" or "no". On systems that support
474 mdns registration of services (currently only Mac OS
475 X), this will enable or disable registration of the
476 service. This defaults to "yes".
477 umask Sets the inherited umask for the service. Expects an
479 octal value. This option may be set in the "defaults"
480 section to set a umask for all services. xinetd sets
481 its own umask to the previous umask OR'd with 022.
482 This is the umask that will be inherited by all child
483 processes if the umask option is not used.
484 enabled Takes a list of service ID's to enable. This will
486 enable only the services listed as arguments to this
487 attribute; the rest will be disabled. If you have 2
488 ftp services, you will need to list both of their ID's
489 and not just ftp. (ftp is the service name, not the
490 ID. It might accidentally be the ID, but you better
491 check.) Note that the service "disable" attribute and
492 "DISABLE" flag can prevent a service from being
493 enabled despite being listed in this attribute.
494 include Takes a filename in the form of "include
496 /etc/xinetd/service". The file is then parsed as a
497 new configuration file. It is not the same thing as
498 pasting the file into xinetd.conf where the include
499 directive is given. The included file must be in the
500 same form as xinetd.conf. This may not be specified
501 from within a service. It must be specified outside a
502 service declaration.
503 includedir Takes a directory name in the form of "includedir
505 /etc/xinetd.d". Every file inside that directory,
506 excluding files with names containing a dot ('.') or
507 ending with a tilde ('~'), will be parsed as xinetd
508 configuration files. The files will be parsed in
509 alphabetical order according to the C locale. This
510 allows you to specify services one per file within a
511 directory. The includedir directive may not be speci‐
512 fied from within a service declaration.
513 rlimit_as Sets the Address Space resource limit for the service.
515 One parameter is required, which is either a positive
516 integer representing the number of bytes to set the
517 limit to (K or M may be used to specify kilo‐
518 bytes/megabytes) or "UNLIMITED". Due to the way
519 Linux's libc malloc is implemented, it is more useful
520 to set this limit than rlimit_data, rlimit_rss and
521 rlimit_stack. This resource limit is only implemented
522 on Linux systems.
523 rlimit_cpu Sets the maximum number of CPU seconds that the ser‐
525 vice may use. One parameter is required, which is
526 either a positive integer representing the number of
527 CPU seconds limit to, or "UNLIMITED".
528 rlimit_data Sets the maximum data size resource limit for the ser‐
530 vice. One parameter is required, which is either a
531 positive integer representing the number of bytes or
532 "UNLIMITED".
533 rlimit_rss Sets the maximum resident set size limit for the ser‐
535 vice. Setting this value low will make the process a
536 likely candidate for swapping out to disk when memory
537 is low. One parameter is required, which is either a
538 positive integer representing the number of bytes or
539 "UNLIMITED".
540 rlimit_stack Set the maximum stack size limit for the service. One
542 parameter is required, which is either a positive
543 integer representing the number of bytes or "UNLIM‐
544 ITED".
545 deny_time Sets the time span that access to all services on all
547 IP addresses are denied to someone that sets off the
548 SENSOR. The unit of time is in minutes. Valid options
549 are: FOREVER, NEVER, and a numeric value. FOREVER
550 causes the IP address not to be purged until xinetd is
551 restarted. NEVER has the effect of just logging the
552 offending IP address. A typical time value would be 60
553 minutes. This should stop most DOS attacks while
554 allowing IP addresses that come from a pool to be
555 recycled for legitimate purposes. This option must be
556 used in conjunction with the SENSOR flag.
557 You don't need to specify all of the above attributes for each service.
559 The necessary attributes for a service are:
560 socket_type
562 user (non-internal services only)
563 server (non-internal services only)
564 wait
565 protocol (RPC and unlisted services only)
566 rpc_version (RPC services only)
567 rpc_number (unlisted RPC services only)
568 port (unlisted non-RPC services only)
569 The following attributes support all assignment operators:
571 only_from
573 no_access
574 log_on_success
575 log_on_failure
576 passenv
577 env (does not support the '-=' operator)
578 These attributes can also appear more than once in a service entry.
580 The remaining attributes support only the '=' operator and can appear
581 at most once in a service entry.
582 The configuration file may also contain a single defaults entry that
584 has the form
585 defaults
587 {
588 <attribute> = <value> <value> ...
589 ...
590 }
591 This entry provides default attribute values for service entries that
593 don't specify those attributes. Possible default attributes:
594 log_type (cumulative effect)
596 bind
597 per_source
598 umask
599 log_on_success (cumulative effect)
600 log_on_failure (cumulative effect)
601 only_from (cumulative effect)
602 no_access (cumulative effect)
603 passenv (cumulative effect)
604 instances
605 disabled (cumulative effect)
606 enabled (cumulative effect)
607 banner
608 banner_success
609 banner_fail
610 per_source
611 groups
612 cps
613 max_load
614 Attributes with a cumulative effect can be specified mul‐
616 tiple times
617 with the values specified each time accumulating (i.e. '=' does
618 the same thing as '+='). With the exception of disabled they
619 all have the same meaning as if they were specified in a service
620 entry. disabled determines services that are disabled even if
621 they have entries in the configuration file. This allows for
622 quick reconfiguration by specifying disabled services with the
623 disabled attribute instead of commenting them out. The value of
624 this attribute is a list of space separated service ids.
625 enabled has the same properties as disabled. The difference
626 being that enabled is a list of which services are to be
627 enabled. If enabled is specified, only the services specified
628 are available. If enabled is not specified, all services are
629 assumed to be enabled, except those listed in disabled.
630
633 xinetd provides the following services internally (both stream and
634 datagram based): echo, time, daytime, chargen, and discard. These ser‐
635 vices are under the same access restrictions as all other services
636 except for the ones that don't require xinetd to fork another process
637 for them. Those ones (time, daytime, and the datagram-based echo, char‐
638 gen, and discard) have no limitation in the number of instances.
639
641 xinetd supports TCPMUX services that conform to RFC 1078. These ser‐
642 vices may not have a well-known port associated with them, and can be
643 accessed via the TCPMUX well-known port.
644 For each service that is to be accessed via TCPMUX, a service entry in
646 /etc/xinetd.conf or in a configuration file in an includedir directory
647 must exist.
648 The service_name field (as defined above for each service in any xinetd
650 configuration file) must be identical to the string that is passed
651 (according to RFC 1078 protocol) to xinetd when the remote service
652 requestor first makes the connection on the TCPMUX well-known port.
653 Private protocols should use a service name that has a high probability
654 of being unique. One way is to prepend the service name with some form
655 of organization ID.
656 The type field can be either TCPMUX or TCPMUXPLUS. If the type is TCP‐
658 MUXPLUS, xinetd will handle the initial protocol handshake (as defined
659 in RFC 1078) with the calling process before initiating the service. If
660 the type is TCPMUX, the server that is started is responsible for per‐
661 forming the handshake.
662 The type field should also include UNLISTED if the service is not
664 listed in a standard system file (like /etc/rpc for RPC services, or
665 /etc/services for non-RPC services).
666 The socket_type for these services must be stream, and the protocol
668 must be tcp.
669 Following is a sample TCPMUX service configuration:
671 service myorg_server
673 {
674 disable = no
675 type = TCPMUX
676 socket_type = stream
677 protocol = tcp
678 wait = no
679 user = root
680 server = /usr/etc/my_server_exec
681 }
682 Besides a service entry for each service that can be accessed via the
684 TCPMUX well-known port, a service entry for TCPMUX itself must also be
685 included in the xinetd configuration. Consider the following sample:
686 service tcpmux
688 {
689 type = INTERNAL
690 id = tcpmux
691 socket_type = stream
692 protocol = tcp
693 user = root
694 wait = no
695 }
696
701 1. The following service attributes cannot be changed on reconfigura‐
702 tion: socket_type, wait, protocol, type.
703 2. When the attributes only_from and no_access are not specified for a
705 service (either directly or via defaults) the address check is con‐
706 sidered successful (i.e. access will not be denied).
707 3. The address check is based on the IP address of the remote host and
709 not on its domain address. We do this so that we can avoid remote
710 name lookups which may take a long time (since xinetd is single-
711 threaded, a name lookup will prevent the daemon from accepting any
712 other requests until the lookup is resolved). The down side of
713 this scheme is that if the IP address of a remote host changes,
714 then access to that host may be denied until xinetd is reconfig‐
715 ured. Whether access is actually denied or not will depend on
716 whether the new host IP address is among those allowed access. For
717 example, if the IP address of a host changes from 1.2.3.4 to
718 1.2.3.5 and only_from is specified as 1.2.3.0 then access will not
719 be denied.
720 4. If the USERID log option is specified and the remote host either
722 does not run an identification server or the server sends back a
723 bad reply, access will not be denied unless the IDONLY service flag
724 is used.
725 5. Interception works by forking a process which acts as a filter
727 between the remote host(s) and the local server. This obviously
728 has a performance impact so it is up to you to make the compromise
729 between security and performance for each service. The following
730 tables show the overhead of interception. The first table shows
731 the time overhead-per-datagram for a UDP-based service using vari‐
732 ous datagram sizes. For TCP-based services we measured the band‐
733 width reduction because of interception while sending a certain
734 amount of data from client to server (the time overhead should the
735 same as for UDP-based services but it is "paid" only by the first
736 packet of a continuous data transmission). The amount of data is
737 given in the table as system_callsxdata_sent_per_call, i.e. each
738 send(2) system call transferred so many bytes of data. The band‐
739 width reduction is given in terms of bytes per second and as a per‐
740 centage of the bandwidth when interception is not performed. All
741 measurements were done on a SparcStation IPC running SunOS 4.1.
742 Datagram size (bytes) Latency (msec)
744 --------------------- --------------
745 64 1.19
746 256 1.51
747 1024 1.51
748 4096 3.58
749 Bytes sent Bandwidth reduction
752 ---------- -------------------
753 10000x64 941 (1.2%)
754 10000x256 4,231 (1.8%)
755 10000x1024 319,300 (39.5%)
756 10000x4096 824,461 (62.1%)
757
759 #
760 # Sample configuration file for xinetd
761 #
762 defaults
764 {
765 log_type = FILE /var/log/servicelog
766 log_on_success = PID
767 log_on_failure = HOST
768 only_from = 128.138.193.0 128.138.204.0
769 only_from = 128.138.252.1
770 instances = 10
771 disabled = rstatd
772 }
773 #
775 # Note 1: the protocol attribute is not required
776 # Note 2: the instances attribute overrides the default
777 #
778 service login
779 {
780 socket_type = stream
781 protocol = tcp
782 wait = no
783 user = root
784 server = /usr/etc/in.rlogind
785 instances = UNLIMITED
786 }
787 #
789 # Note 1: the instances attribute overrides the default
790 # Note 2: the log_on_success flags are augmented
791 #
792 service shell
793 {
794 socket_type = stream
795 wait = no
796 user = root
797 instances = UNLIMITED
798 server = /usr/etc/in.rshd
799 log_on_success += HOST
800 }
801 service ftp
803 {
804 socket_type = stream
805 wait = no
806 nice = 10
807 user = root
808 server = /usr/etc/in.ftpd
809 server_args = -l
810 instances = 4
811 log_on_success += DURATION HOST USERID
812 access_times = 2:00-9:00 12:00-24:00
813 }
814 # Limit telnet sessions to 8 Mbytes of memory and a total
816 # 20 CPU seconds for child processes.
817 service telnet
818 {
819 socket_type = stream
820 wait = no
821 nice = 10
822 user = root
823 server = /usr/etc/in.telnetd
824 rlimit_as = 8M
825 rlimit_cpu = 20
826 }
827 #
829 # This entry and the next one specify internal services. Since
830 # this is the same service using a different socket type, the
831 # id attribute is used to uniquely identify each entry
832 #
833 service echo
834 {
835 id = echo-stream
836 type = INTERNAL
837 socket_type = stream
838 user = root
839 wait = no
840 }
841 service echo
843 {
844 id = echo-dgram
845 type = INTERNAL
846 socket_type = dgram
847 user = root
848 wait = no
849 }
850 #
852 # Sample RPC service
853 #
854 service rstatd
855 {
856 type = RPC
857 socket_type = dgram
858 protocol = udp
859 server = /usr/etc/rpc.rstatd
860 wait = yes
861 user = root
862 rpc_version = 2-4
863 env = LD_LIBRARY_PATH=/etc/securelib
864 }
865 #
867 # Sample unlisted service
868 #
869 service unlisted
870 {
871 type = UNLISTED
872 socket_type = stream
873 protocol = tcp
874 wait = no
875 server = /home/user/some_server
876 port = 20020
877 }
878
880 xinetd(1L),
881 xinetd.log(5)
883 Postel J., Echo Protocol, RFC 862, May 1983
885 Postel J., Discard Protocol, RFC 863, May 1983
887 Postel J., Character Generator Protocol, RFC 864, May 1983
889 Postel J., Daytime Protocol, RFC 867, May 1983
891 Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
893 M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078 Nov 1988
895 StJohns M., Identification Protocol, RFC 1413, February 1993
897
899 If the INTERCEPT flag is not used, access control on the address of the
900 remote host is not performed when wait is yes and socket_type is
901 stream.
902 The NOLIBWRAP flag is automatically turned on for RPC services whose
904 socket_type is stream because xinetd cannot determine the address of
905 the remote host.
906 If the INTERCEPT flag is not used, access control on the address of the
908 remote host for services where wait is yes and socket_type is dgram is
909 performed only on the first packet. The server may then accept packets
910 from hosts not in the access control list. This can happen with RPC
911 services.
912 There is no way to put a SPACE in an environment variable.
914 When wait is yes and socket_type is stream, the socket passed to the
916 server can only accept connections.
917 The INTERCEPT flag is not supported for internal services or multi-
919 threaded services.
920 14 June 2001 XINETD.CONF(5)