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