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_files Sets the maximum number of open files that the service
525 may use. One parameter is required, which is a posi‐
526 tive integer representing the number of open file
527 descriptors. Practical limit of this number is around
528 1024000.
529 rlimit_cpu Sets the maximum number of CPU seconds that the ser‐
531 vice may use. One parameter is required, which is
532 either a positive integer representing the number of
533 CPU seconds limit to, or "UNLIMITED".
534 rlimit_data Sets the maximum data size resource limit for the ser‐
536 vice. One parameter is required, which is either a
537 positive integer representing the number of bytes or
538 "UNLIMITED".
539 rlimit_rss Sets the maximum resident set size limit for the ser‐
541 vice. Setting this value low will make the process a
542 likely candidate for swapping out to disk when memory
543 is low. One parameter is required, which is either a
544 positive integer representing the number of bytes or
545 "UNLIMITED".
546 rlimit_stack Set the maximum stack size limit for the service. One
548 parameter is required, which is either a positive
549 integer representing the number of bytes or "UNLIM‐
550 ITED".
551 deny_time Sets the time span that access to all services on all
553 IP addresses are denied to someone that sets off the
554 SENSOR. The unit of time is in minutes. Valid options
555 are: FOREVER, NEVER, and a numeric value. FOREVER
556 causes the IP address not to be purged until xinetd is
557 restarted. NEVER has the effect of just logging the
558 offending IP address. A typical time value would be 60
559 minutes. This should stop most DOS attacks while
560 allowing IP addresses that come from a pool to be
561 recycled for legitimate purposes. This option must be
562 used in conjunction with the SENSOR flag.
563 You don't need to specify all of the above attributes for each service.
565 The necessary attributes for a service are:
566 socket_type
568 user (non-internal services only)
569 server (non-internal services only)
570 wait
571 protocol (RPC and unlisted services only)
572 rpc_version (RPC services only)
573 rpc_number (unlisted RPC services only)
574 port (unlisted non-RPC services only)
575 The following attributes support all assignment operators:
577 only_from
579 no_access
580 log_on_success
581 log_on_failure
582 passenv
583 env (does not support the '-=' operator)
584 These attributes can also appear more than once in a service entry.
586 The remaining attributes support only the '=' operator and can appear
587 at most once in a service entry.
588 The configuration file may also contain a single defaults entry that
590 has the form
591 defaults
593 {
594 <attribute> = <value> <value> ...
595 ...
596 }
597 This entry provides default attribute values for service entries that
599 don't specify those attributes. Possible default attributes:
600 log_type (cumulative effect)
602 bind
603 per_source
604 umask
605 log_on_success (cumulative effect)
606 log_on_failure (cumulative effect)
607 only_from (cumulative effect)
608 no_access (cumulative effect)
609 passenv (cumulative effect)
610 instances
611 disabled (cumulative effect)
612 enabled (cumulative effect)
613 banner
614 banner_success
615 banner_fail
616 per_source
617 groups
618 cps
619 max_load
620 Attributes with a cumulative effect can be specified mul‐
622 tiple times
623 with the values specified each time accumulating (i.e. '=' does
624 the same thing as '+='). With the exception of disabled they
625 all have the same meaning as if they were specified in a service
626 entry. disabled determines services that are disabled even if
627 they have entries in the configuration file. This allows for
628 quick reconfiguration by specifying disabled services with the
629 disabled attribute instead of commenting them out. The value of
630 this attribute is a list of space separated service ids.
631 enabled has the same properties as disabled. The difference
632 being that enabled is a list of which services are to be
633 enabled. If enabled is specified, only the services specified
634 are available. If enabled is not specified, all services are
635 assumed to be enabled, except those listed in disabled.
636
639 xinetd provides the following services internally (both stream and
640 datagram based): echo, time, daytime, chargen, and discard. These ser‐
641 vices are under the same access restrictions as all other services
642 except for the ones that don't require xinetd to fork another process
643 for them. Those ones (time, daytime, and the datagram-based echo, char‐
644 gen, and discard) have no limitation in the number of instances.
645
647 xinetd supports TCPMUX services that conform to RFC 1078. These ser‐
648 vices may not have a well-known port associated with them, and can be
649 accessed via the TCPMUX well-known port.
650 For each service that is to be accessed via TCPMUX, a service entry in
652 /etc/xinetd.conf or in a configuration file in an includedir directory
653 must exist.
654 The service_name field (as defined above for each service in any xinetd
656 configuration file) must be identical to the string that is passed
657 (according to RFC 1078 protocol) to xinetd when the remote service
658 requestor first makes the connection on the TCPMUX well-known port.
659 Private protocols should use a service name that has a high probability
660 of being unique. One way is to prepend the service name with some form
661 of organization ID.
662 The type field can be either TCPMUX or TCPMUXPLUS. If the type is TCP‐
664 MUXPLUS, xinetd will handle the initial protocol handshake (as defined
665 in RFC 1078) with the calling process before initiating the service. If
666 the type is TCPMUX, the server that is started is responsible for per‐
667 forming the handshake.
668 The type field should also include UNLISTED if the service is not
670 listed in a standard system file (like /etc/rpc for RPC services, or
671 /etc/services for non-RPC services).
672 The socket_type for these services must be stream, and the protocol
674 must be tcp.
675 Following is a sample TCPMUX service configuration:
677 service myorg_server
679 {
680 disable = no
681 type = TCPMUX
682 socket_type = stream
683 protocol = tcp
684 wait = no
685 user = root
686 server = /usr/etc/my_server_exec
687 }
688 Besides a service entry for each service that can be accessed via the
690 TCPMUX well-known port, a service entry for TCPMUX itself must also be
691 included in the xinetd configuration. Consider the following sample:
692 service tcpmux
694 {
695 type = INTERNAL
696 id = tcpmux
697 socket_type = stream
698 protocol = tcp
699 user = root
700 wait = no
701 }
702
707 1. The following service attributes cannot be changed on reconfigura‐
708 tion: socket_type, wait, protocol, type.
709 2. When the attributes only_from and no_access are not specified for a
711 service (either directly or via defaults) the address check is con‐
712 sidered successful (i.e. access will not be denied).
713 3. The address check is based on the IP address of the remote host and
715 not on its domain address. We do this so that we can avoid remote
716 name lookups which may take a long time (since xinetd is single-
717 threaded, a name lookup will prevent the daemon from accepting any
718 other requests until the lookup is resolved). The down side of
719 this scheme is that if the IP address of a remote host changes,
720 then access to that host may be denied until xinetd is reconfig‐
721 ured. Whether access is actually denied or not will depend on
722 whether the new host IP address is among those allowed access. For
723 example, if the IP address of a host changes from 1.2.3.4 to
724 1.2.3.5 and only_from is specified as 1.2.3.0 then access will not
725 be denied.
726 4. If the USERID log option is specified and the remote host either
728 does not run an identification server or the server sends back a
729 bad reply, access will not be denied unless the IDONLY service flag
730 is used.
731 5. Interception works by forking a process which acts as a filter
733 between the remote host(s) and the local server. This obviously
734 has a performance impact so it is up to you to make the compromise
735 between security and performance for each service. The following
736 tables show the overhead of interception. The first table shows
737 the time overhead-per-datagram for a UDP-based service using vari‐
738 ous datagram sizes. For TCP-based services we measured the band‐
739 width reduction because of interception while sending a certain
740 amount of data from client to server (the time overhead should the
741 same as for UDP-based services but it is "paid" only by the first
742 packet of a continuous data transmission). The amount of data is
743 given in the table as system_callsxdata_sent_per_call, i.e. each
744 send(2) system call transferred so many bytes of data. The band‐
745 width reduction is given in terms of bytes per second and as a per‐
746 centage of the bandwidth when interception is not performed. All
747 measurements were done on a SparcStation IPC running SunOS 4.1.
748 Datagram size (bytes) Latency (msec)
750 --------------------- --------------
751 64 1.19
752 256 1.51
753 1024 1.51
754 4096 3.58
755 Bytes sent Bandwidth reduction
758 ---------- -------------------
759 10000x64 941 (1.2%)
760 10000x256 4,231 (1.8%)
761 10000x1024 319,300 (39.5%)
762 10000x4096 824,461 (62.1%)
763
765 #
766 # Sample configuration file for xinetd
767 #
768 defaults
770 {
771 log_type = FILE /var/log/servicelog
772 log_on_success = PID
773 log_on_failure = HOST
774 only_from = 128.138.193.0 128.138.204.0
775 only_from = 128.138.252.1
776 instances = 10
777 disabled = rstatd
778 }
779 #
781 # Note 1: the protocol attribute is not required
782 # Note 2: the instances attribute overrides the default
783 #
784 service login
785 {
786 socket_type = stream
787 protocol = tcp
788 wait = no
789 user = root
790 server = /usr/etc/in.rlogind
791 instances = UNLIMITED
792 }
793 #
795 # Note 1: the instances attribute overrides the default
796 # Note 2: the log_on_success flags are augmented
797 #
798 service shell
799 {
800 socket_type = stream
801 wait = no
802 user = root
803 instances = UNLIMITED
804 server = /usr/etc/in.rshd
805 log_on_success += HOST
806 }
807 service ftp
809 {
810 socket_type = stream
811 wait = no
812 nice = 10
813 user = root
814 server = /usr/etc/in.ftpd
815 server_args = -l
816 instances = 4
817 log_on_success += DURATION HOST USERID
818 access_times = 2:00-9:00 12:00-24:00
819 }
820 # Limit telnet sessions to 8 Mbytes of memory and a total
822 # 20 CPU seconds for child processes.
823 service telnet
824 {
825 socket_type = stream
826 wait = no
827 nice = 10
828 user = root
829 server = /usr/etc/in.telnetd
830 rlimit_as = 8M
831 rlimit_cpu = 20
832 }
833 #
835 # This entry and the next one specify internal services. Since
836 # this is the same service using a different socket type, the
837 # id attribute is used to uniquely identify each entry
838 #
839 service echo
840 {
841 id = echo-stream
842 type = INTERNAL
843 socket_type = stream
844 user = root
845 wait = no
846 }
847 service echo
849 {
850 id = echo-dgram
851 type = INTERNAL
852 socket_type = dgram
853 user = root
854 wait = no
855 }
856 #
858 # Sample RPC service
859 #
860 service rstatd
861 {
862 type = RPC
863 socket_type = dgram
864 protocol = udp
865 server = /usr/etc/rpc.rstatd
866 wait = yes
867 user = root
868 rpc_version = 2-4
869 env = LD_LIBRARY_PATH=/etc/securelib
870 }
871 #
873 # Sample unlisted service
874 #
875 service unlisted
876 {
877 type = UNLISTED
878 socket_type = stream
879 protocol = tcp
880 wait = no
881 server = /home/user/some_server
882 port = 20020
883 }
884
886 xinetd(1L),
887 xinetd.log(5)
889 Postel J., Echo Protocol, RFC 862, May 1983
891 Postel J., Discard Protocol, RFC 863, May 1983
893 Postel J., Character Generator Protocol, RFC 864, May 1983
895 Postel J., Daytime Protocol, RFC 867, May 1983
897 Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
899 M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078 Nov 1988
901 StJohns M., Identification Protocol, RFC 1413, February 1993
903
905 If the INTERCEPT flag is not used, access control on the address of the
906 remote host is not performed when wait is yes and socket_type is
907 stream.
908 The NOLIBWRAP flag is automatically turned on for RPC services whose
910 socket_type is stream because xinetd cannot determine the address of
911 the remote host.
912 If the INTERCEPT flag is not used, access control on the address of the
914 remote host for services where wait is yes and socket_type is dgram is
915 performed only on the first packet. The server may then accept packets
916 from hosts not in the access control list. This can happen with RPC
917 services.
918 There is no way to put a SPACE in an environment variable.
920 When wait is yes and socket_type is stream, the socket passed to the
922 server can only accept connections.
923 The INTERCEPT flag is not supported for internal services or multi-
925 threaded services.
926 14 June 2001 XINETD.CONF(5)