Posted by: Mangesh_Linux_Administrator | September 3, 2010

Network Security “The xinetd TCP Super-Server Daemon”


——————————————————————————-
Network Security
The xinetd TCP Super-Server Daemon
——————————————————————————-

* xinetd.conf is the config file that determines the services provided by
xinetd.

* xinetd  starts programs that provide Internet services.

* Instead of having such servers  started  at system  initialization time, and
be dormant until a connection request arrives, xinetd is the only daemon
process started and it listens on all service ports for the services listed
in its configuration file, which have been enabled

* When a request comes in, xinetd starts the appropriate server. Because of
the way it operates, xinetd is also referred to as a Super-Server.

* The services listed in xinetd’s configuration  file can be  separated into two
groups. Services in the first group are called multi-threaded and they
require the forking of a new server process for each new  connection request.   The new server then handles that connection. For such services, xinetd keeps
listening for new requests so that it can spawn new servers.

* On the other hand, the second group includes services for which the service
daemon is responsible for handling all new connection requests.

* Such services are called single-threaded and xinetd will stop handling new
requests for them until the server dies. Services in this group are usually
datagram-based.

* So far, the only reason for the existence of a super-server was to conserve
system resources by avoiding to fork a lot of processes which might be dormant
for most of their lifetime.

* While fulfilling this function, xinetd takes advantage of the idea of a
super-server to provide features such as access control and logging.

Furthermore, xinetd is not limited to services listed in /etc/services.
Therefore, anybody can use xinetd to start special-purpose servers.

* Each entry defines a service identified by the service_name.

The following is a list of available attributes:

Note : Do not forget to check out the 10 examples at the end.

—————————————————–
List of attributes configurable in /etc/xinetd.conf
—————————————————–

Critical 21 to concentrate on !

1. Global
——
1 includedir

2. Daemons/Servers
—————
2 server
3 server_args
4 port

3. Load Balancing :
————–
5 disable
6 instances
7 cps
8 flags = NOLIBWRAP

4. Tuning/Optimization
——————-
9 nice

5. Access Control
————–
10 only_from
11 no_access
12 access_times
13 per_source
14 bind
15 interface [aka bind]

6. Logging
——-
16 log_type
17 log_on_success
18 log_on_failure
19 banner
20 banner_success
21 banner_fail

Want more ? Enjoy !
——————–
22 id
23 type
24 flags
25 socket_type
26 protocol
27 wait
28 user
29 group
30 rpc_version
31 rpc_number
32 env
33 passenv
34 redirect
35 max_load
36 groups
37 umask
38 enabled
39 include
40 rlimit_as
41 rlimit_cpu
42 rlimit_data
43 rlimit_rss
44 rlimit_stack
45 deny_time

——————————————————————————-
The config file for xinetd daemon :

=======================
Canned /etc/xinetd.conf
=======================

defaults
{
instances               = 60
log_type                = SYSLOG authpriv
log_on_success          = HOST PID
log_on_failure      = HOST
cps              = 25 30
}
includedir /etc/xinetd.d

————————-
DIRECTIVES OF XINETD.CONF
————————-

——
1. Global
——

——————————————————————————-
1      includedir    Takes  a  directory  name  in  the form of “includedir
/etc/xinetd.d”.     Every    file  inside  that  directory,
excluding  files  with names containing a dot (’.’) or
ending with a tilde (’~’), will be  parsed  as    xinetd
configuration  files.    The  files  will  be parsed in
alphabetical order according to     the  C     locale.  This
allows    you  to specify services one per file within a
directory.  The includedir directive may not be speci-
fied from within a service declaration.
——————————————————————————-

—————
2. Daemons/Servers
—————

——————————————————————————-
2. server        Determines the program to execute for this service.
——————————————————————————-
3. server_args            Determines the arguments passed to the server. In con-
trast to inetd, the server name should not be included
in server_args.
——————————————————————————-
4.  port        Determines the service    port.  If  this     attribute  is
specified  for    a  service listed in /etc/services, it
must be equal to the port number listed in that     file.

————–
3. Load Balancing :
————–

——————————————————————————-
5. disable        This  is  boolean  “yes” or “no”.  This will result in
the service being disabled and not starting.  See  the
DISABLE flag description.
————————————————————————-
6. instances            Determines  the number of servers that can be simulta-
neously active    for  a    service     (the  default    is  no
limit).     The  value  of this attribute can be either a
number or UNLIMITED  which  means  that     there    is  no
limit.
——————————————————————————-
7. cps                Limits the rate of incoming  connections.   Takes  two
arguments.   The  first argument is the number of con-
nections per second to handle.    If the rate of    incom-
ing  connections is higher than this, the service will
be temporarily disabled.  The second argument  is  the
number    of seconds to wait before re-enabling the ser-
vice after it has been disabled.  The default for this
setting is 50 incoming connections and the interval is
10 seconds.
——————————————————————————-
8. flags = NOLIBWRAP
——————————————————————————-

——————-
4. Tuning/Optimization
——————-

——————————————————————————-
9. nice                Determines the server priority. Its value is a (possi-
bly negative) number;
——————————————————————————-

————–
5. Access Control
————–

——————————————————————————-
10 only_from
determines  the     remote     hosts to which the particular
service is available.  Its  value  is  a  list    of  IP
addresses which can be specified in any combination of
the following ways:

a)   a numeric address in the form of %d.%d.%d.%d.  If
the  rightmost components are 0, they are treated
as wildcards (for example,     128.138.12.0  matches
all  hosts     on  the  128.138.12 subnet).  0.0.0.0
matches all Internet addresses.  IPv6  hosts  may
be specified in the form of abcd:ef01::2345:6789.
The rightmost rule for IPv4  addresses  does  not
apply to IPv6 addresses.

b)   a      factorized    address      in   the   form   of
%d.%d.%d.{%d,%d,…}.  There is no need for all 4
components (i.e. %d.%d.{%d,%d,…%d} is also ok).
However, the factorized part must be at  the  end
of the address.  This form does not work for IPv6
hosts.

c)   a network name (from  /etc/networks).  This  form
does not work for IPv6 hosts.

d)   a    host  name.   When  a  connection  is  made to
xinetd, a reverse lookup is  performed,  and  the
canonical name returned is compared to the speci-
fied host name.  You may also use domain names in
the  form    of .domain.com.     If the reverse lookup
of the client’s IP is within .domain.com, a match
occurs.

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

Specifying  this  attribute  without a value makes the
service available to no-one.
——————————————————————————-
11 no_access
Determines the remote hosts to    which  the  particular
service     is unavailable. Its value can be specified in
the same way as the value of the only_from  attribute.
These  two  attributes    determine  the location access
control enforced by xinetd. If    none  of  the  two  is
specified  for    a service, the service is available to
anyone. If both are specified for a service,  the  one
that is the better match for the address of the remote
host determines if the service is  available  to  that
host  (for  example,  if  the  only_from list contains
128.138.209.0  and   the   no_access   list   contains
128.138.209.10     then    the   host  with  the  address
128.138.209.10 can not access the service).
——————————————————————————-
12 access_times
Determines the time  intervals    when  the  service  is
available.  An interval has the form hour:min-hour:min
(connections will be accepted  at  the    bounds    of  an
interval).  Hours  can    range from 0 to 23 and minutes
from 0 to 59.

eg  access_times = 9:00-1300 1400-1700
——————————————————————————-
13 per_source
Takes  an integer or “UNLIMITED” as an argument.  This
specifies the maximum instances of  this  service  per
source    IP address.  This can also be specified in the
defaults section.
——————————————————————————-
14 bind
Allows    a  service to be bound to a specific interface
on the machine.     This means  you  can  have  a    telnet
server    listening  on  a local, secured interface, and
not on the external interface.    Or  one     port  on  one
interface  can    do something, while the same port on a
different interface can do something  completely  dif-
ferent.     Syntax: bind = (ip address of interface).
——————————————————————————-
15  interface    Synonym for bind.
——————————————————————————-

——–
6. Logging
——-
——————————————————————————-
16 log_type
Determines where the service log output is sent. There
are two formats:

SYSLOG    syslog_facility [syslog_level]
The  log output is sent to syslog at the specified facility.
Possible facility names include:
daemon,
auth,
authpriv,
user,
mail,
lpr,
news,
uucp,
ftp
local0-7.
Possible    level     names include:
emerg,
alert,
crit,
err,
warning,
notice,
info,
debug.
If  a  level is not present, the  messages will be recorded at the
info level.

FILE  file [soft_limit [hard_limit]]
The log output is appended to file  which  will be  created if it does
not exist.  Two limits on  the size of the log  file  can    be  optionally
specified.
The first    limit  is  a soft one;
xinetd will log a message the first  time  this limit  is  exceeded
(if xinetd logs to syslog, the message will be sent at the alert
prioritylevel).
The  second  limit  is a hard limit;
xinetd will stop logging for the affected  service  (if  the  log
file is a common log file, then more than one service may be affected)
and will  log  a message about this (if xinetd logs to syslog, the
message  will  be sent  at the alert  priority level).
If a hard limit is not    specified, it  defaults to  the  soft limit.

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

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

HOST        logs the remote host address

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

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

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

HOST        logs the remote host address.

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

ATTEMPT        logs  the  fact  that a failed attempt was
made (this option is implied by  all  oth-
ers).
——————————————————————————-
19  banner        Takes  the name of a file to be splatted at the remote
host when a connection to that service is established.
This  banner  is printed regardless of access control.
It should *always* be printed when  a  connection  has
been made.
——————————————————————————-
20 banner_success    Takes  the name of a file to be splatted at the remote
host when a connection to  that     service  is  granted.
This  banner  is  printed as soon as access is granted
for the service.
——————————————————————————-
21 banner_fail            Takes the name of a file to be splatted at the    remote
host  when  a  connection  to  that service is denied.
This banner is    printed     immediately  upon  denial  of
access.      This is useful for informing your users that
they are doing something bad  and  they     shouldn’t  be
doing it anymore.
——————————————————————————-

Miscellaneous

——————————————————————————-
22  id                    This attribute is used to uniquely identify a service.
This is useful because there exist services  that  can
use  different protocols and need to be described with
different  entries  in    the  configuration  file.   By
default,  the  service    id  is the same as the service
name.
——————————————————————————-
23  type        Any combination of the following values may be used:

RPC        if this is an RPC service
INTERNAL    if this is a service provided by xinetd.
TCPMUX/TCPMUXPLUS
if this is a service that will be  started
according  to the RFC 1078 protocol on the
TCPMUX well-known port.  See  the  section
describing TCPMUX services below.
UNLISTED    if this is a service not listed in a stan-
dard system file (like  /etc/rpc  for  RPC
services,  or  /etc/services  for  non-RPC
services).
——————————————————————————-
24 flags        Any combination of the following flags may be used:

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

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

IDONLY        Accept  connections     only  when the remote
end identifies the remote user  (i.e.  the
remote  host  must    run  an identification
server).  This flag applies only  to  con-
nection-based   services.    This  flag  is
ineffective if the USERID  log  option  is
not used.

NAMEINARGS  This  will    cause  the  first  argument in
“server_args” to be argv[0] when executing
the     server,  as  specified     in  “server”.
This allows you to    use  tcpd  by  putting
tcpd  in  “server”    and  the  name    of the
server in  “server_args”  like  in    normal
inetd.

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

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

NOLIBWRAP   This disables internal calling of the tcp-
wrap library to determine  access  to  the
service.   This  may be needed in order to
use libwrap functionality not available to
long-running  processes such as xinetd; in
this case, the tcpd program can be    called
explicitly (see also the NAMEINARGS flag).

SENSOR        This replaces the service  with  a    sensor
that  detects  accesses  to     the specified
port. NOTE: It  will  NOT  detect  stealth
scans.  This  flag    should be used only on
services that you  know  you  don’t     need.
When  an  access is made to this service’s
port, the IP Address is added to a    global
no_access list. This causes all subsequent
accesses from the originating  IP  address
to    be  denied  access until the deny_time
setting expires. The amount of time     spent
on     this  list  is     configurable  as  the
deny_time attribute. The SENSOR flag  will
also  cause     xinetd to consider the server
attribute to be INTERNAL no matter what is
typed  on the same line. Another important
thing  to  remember      is   that   if   the
socket_type     is  set  to  stream, then the
wait attribute should be set to no.

IPv4        Sets the service to     be  an     IPv4  service
(AF_INET).

IPv6        Sets  the  service    to  be an IPv6 service
(AF_INET6), if IPv6 is  available  on  the
system.
——————————————————————————-
25 socket_type            Possible values for this attribute include:

stream        stream-based service
dgram        datagram-based service
raw        service that requires direct access to IP
seqpacket   service  that requires reliable sequential
datagram transmission
——————————————————————————-
26 protocol        Determines the protocol that is employed by  the  ser-
vice.    The protocol must exist in /etc/protocols.  If
this attribute is not defined,    the  default  protocol
employed by the service will be used.
——————————————————————————-
27  wait        This  attribute     determines  if the service is single-
threaded or multi-threaded. If its value  is  yes  the
service     is  single-threaded;  this  means that xinetd
will start the server and then it will    stop  handling
requests  for  the  service until the server dies.  If
the attribute value  is     no,  the  service  is    multi-
threaded  and  xinetd  will  keep handling new service
requests.
——————————————————————————-
28 user                 Determines the uid for the server  process.  The  user
name  must  exist  in  /etc/passwd.  This attribute is
ineffective if the effective user ID of xinetd is  not
super-user.
——————————————————————————-
29 group        determines  the     gid for the server process. The group
name must exist in /etc/group.     If  a    group  is  not
specified,  the     group    of  user  will    be  used (from
/etc/passwd).  This attribute is  ineffective  if  the
effective user ID of xinetd is not super-user.
——————————————————————————-
30     rpc_version    Determines the RPC version for a RPC service. The ver-
sion can be a single number or a  range     in  the  form
number-number.

——————————————————————————-
31     rpc_number    determines  the     number     for  an  UNLISTED RPC service
(this attribute is  ignored  if     the  service  is  not
unlisted).
——————————————————————————-
32      env        The  value  of    this attribute is a list of strings of
the form ’name=value’.    These strings will be added to
the  environment  before  starting a server (therefore
the server’s environment will include  xinetd’s     envi-
ronment plus the specified strings).
——————————————————————————-
33      passenv        The  value  of this attribute is a list of environment
variables  from     xinetd’s  environment    that  will  be
passed    to  the server.     An empty list implies passing
no variables to the server except for those explicitly
defined using the env attribute.  (notice that you can
use  this  attribute  in  conjunction  with  the   env
attribute  to  specify    exactly     what argument will be
passed to the server).
——————————————————————————-
34      redirect    Allows a tcp service to be redirected to another host.
When xinetd receives a tcp connection on this port  it
spawns    a process that establishes a connection to the
host and port number specified, and forwards all  data
between     the  two  hosts.   This option is useful when
your internal machines are not visible to the  outside
world.     Syntax     is:  redirect    = (ip address) (port).
You can also use a hostname instead of the IP  address
in  this field.     The hostname lookup is performed only
once, when xinetd is started, and the first IP address
returned  is  the  one    that  is  used until xinetd is
restarted.  The “server”  attribute  is     not  required
when  this  option  is    specified.   If     the  “server”
attribute is specified, this attribute takes priority.
——————————————————————————-
35     max_load        Takes a floating point value as the load at which  the
service will stop accepting connections.  For example:
2 or 2.5.  The service will stop accepting connections
at  this  load.      This is the one minute load average.
This is an OS dependent feature,  and  currently  only
Linux and Solaris are supported for this.
——————————————————————————-
36     groups        Takes  either  “yes” or “no”.  If the groups attribute
is set to “yes”, then  the  server  is    executed  with
access    to  the groups that the server’s effective UID
has access to.    If the    groups    attribute  is  set  to
“no”,  then  the  server  runs    with  no supplementary
groups.     This attribute must be set to “yes” for  many
BSD  systems.    This  attribute     can  be  set  in  the
defaults section as well.
——————————————————————————-
37     umask        Sets the inherited umask for the service.  Expects  an
octal value.  This option may be set in the “defaults”
section to set a umask for all services.  xinetd  sets
its  own  umask     to  the previous umask OR’d with 022.
This is the umask that will be inherited by all     child
processes if the umask option is not used.
——————————————————————————-
38     enabled        Takes  a  list    of service names to enable.  This will
enable only the services listed as arguments  to  this
attribute;  the     rest  will be disabled.  Not that the
service “disable” attribute  and  “DISABLE”  flag  can
prevent     a  service  from  being enabled despite being
listed in this attribute.
——————————————————————————-
39     include        Takes    a   filename   in   the      form     of   “include
/etc/xinetd/service”.    The  file  is then parsed as a
new configuration file.     It is not the same  thing  as
pasting     the  file  into xinetd.conf where the include
directive is given.  The included file must be in  the
same  form  as xinetd.conf.  This may not be specified
from within a service.    It must be specified outside a
service declaration.
——————————————————————————-
40     rlimit_as    Sets the Address Space resource limit for the service.
One parameter is required, which is either a  positive
integer     representing  the  number of bytes to set the
limit to  (K  or  M  may  be  used  to    specify     kilo-
bytes/megabytes)  or  “UNLIMITED”.   Due  to  the  way
Linux’s libc malloc is implemented, it is more    useful
to  set     this  limit  than rlimit_data, rlimit_rss and
rlimit_stack. This resource limit is only  implemented
on Linux systems.
——————————————————————————-
41     rlimit_cpu    Sets  the  maximum number of CPU seconds that the ser-
vice may use.  One parameter  is  required,  which  is
either    a  positive integer representing the number of
CPU seconds limit to, or “UNLIMITED”.
——————————————————————————-
42     rlimit_data    Sets the maximum data size resource limit for the ser-
vice.    One  parameter    is required, which is either a
positive integer representing the number of  bytes  or
“UNLIMITED”.
——————————————————————————-
43     rlimit_rss    Sets  the maximum resident set size limit for the ser-
vice.  Setting this value low will make the process  a
likely    candidate for swapping out to disk when memory
is low.     One parameter is required, which is either  a
positive  integer  representing the number of bytes or
“UNLIMITED”.
——————————————————————————-
44     rlimit_stack    Set the maximum stack size limit for the service.  One
parameter  is  required,  which     is  either a positive
integer representing the number of  bytes  or  “UNLIM-
ITED”.
——————————————————————————-
45     deny_time    Sets  the time span that access to all services on all
IP addresses are denied to someone that sets  off  the
SENSOR. The unit of time is in minutes.     Valid options
are: FOREVER, NEVER,  and  a  numeric  value.  FOREVER
causes the IP address not to be purged until xinetd is
restarted. NEVER has the effect of  just  logging  the
offending IP address. A typical time value would be 60
minutes. This  should  stop  most  DOS    attacks     while
allowing  IP  addresses     that  come  from a pool to be
recycled for legitimate purposes. This option must  be
used in conjunction with the SENSOR flag.
——————————————————————————-

You don’t need to specify all of the above attributes for each service.
The necessary attributes for a service are:

socket_type
user        (non-internal services only)
server        (non-internal services only)
wait
protocol        (RPC and unlisted services only)
rpc_version    (RPC services only)
rpc_number    (unlisted RPC services only)
port        (unlisted non-RPC services only)

The following attributes support all assignment operators:

only_from
no_access
log_on_success
log_on_failure
passenv
env        (does not support the ’-=’ operator)

These attributes can also appear more than once    in  a  service    entry.
The  remaining  attributes support only the ’=’ operator and can appear
at most once in a service entry.

The configuration file may also contain a single     defaults  entry  that
has the form

defaults
{
<attribute> = <value> <value> …

}

This  entry  provides default attribute values for service entries that
don’t specify those attributes. Possible default attributes:

log_type
bind
per_source
umask
log_on_success    (cumulative effect)
log_on_failure    (cumulative effect)
only_from        (cumulative effect)
no_access        (cumulative effect)
passenv        (cumulative effect)
instances
disabled        (cumulative effect)
enabled        (cumulative effect)

Attributes with a cumulative effect can    be  specified  multiple     times
with  the  values  specified  each time accumulating (i.e. ’=’ does the
same thing as ’+=’).  With the exception of disabled they all have  the
same  meaning  as  if they were specified in a service entry.  disabled
determines services that are disabled even if they have entries in  the
configuration file. This allows for quick reconfiguration by specifying
disabled services with the disabled  attribute  instead    of  commenting
them  out.   The     value    of this attribute is a list of space separated
service ids.  enabled has the same properties as disabled.  The differ-
ence  being that enabled is a list of which services are to be enabled.
If enabled is specified, only the services specified are available.  If
enabled    is  not     specified,  all  services  are assumed to be enabled,
except those listed in disabled.

INTERNAL SERVICES
xinetd provides the following  services    internally  (both  stream  and
datagram based): echo, time, daytime, chargen, and discard.  These ser-
vices are under the same access    restrictions  as  all  other  services
except  for  the ones that don’t require xinetd to fork another process
for them. Those ones (time, daytime, and the datagram-based echo, char-
gen, and discard) have no limitation in the number of instances.

xinetd  also  provides  two  UNLISTED  internal    stream-based services:
servers and services.   The  former  lists  information    about  running
servers    while the latter provides a list of currently active services.
There is one service per line and each line contains the service     name,
protocol (e.g. “tcp”) and port number.

There  is also now an administrative interface that is an internal ser-
vice.  The service name “xadmin” is reserved, and  will    always    be  an
internal     service.   You should specify a port number for this service,
and probably also some IP based access control, since at     the  time  of
this  writing it does not have any password protection.    You can telnet
to this port and query xinetd for some information.
NOTES
1.  The    following service attributes cannot be changed on reconfigura-
tion: socket_type, wait, protocol, type.

2.  When the attributes only_from and no_access are not specified for a
service (either directly or via defaults) the address check is con-
sidered successful (i.e. access will not be denied).

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

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

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

Datagram size (bytes)       Latency (msec)
———————       ————–
64               1.19
256               1.51
1024               1.51
4096               3.58

Bytes sent           Bandwidth reduction
———-           ——————-
10000×64           941 (1.2%)
10000×256           4,231 (1.8%)
10000×1024           319,300 (39.5%)
10000×4096           824,461 (62.1%)
=========
EXAMPLE 1
=========
#
# Sample configuration file for xinetd
#

defaults
{
log_type         = FILE /var/log/servicelog
log_on_success     = PID
log_on_failure     = HOST RECORD
only_from         = 128.138.193.0 128.138.204.0
only_from         = 128.138.252.1
instances         = 10
disabled         = rstatd
}
=========
EXAMPLE 2
=========

#
# Note 1: the protocol attribute is not required
# Note 2: the instances attribute overrides the default
#
service login
{
socket_type     = stream
protocol         = tcp
wait         = no
user         = root
server         = /usr/etc/in.rlogind
instances         = UNLIMITED
}

#
# Note 1: the instances attribute overrides the default
# Note 2: the log_on_success flags are augmented
#
=========
EXAMPLE 3
=========
service shell
{
socket_type     = stream
wait         = no
user         = root
instances         = UNLIMITED
server         = /usr/etc/in.rshd
log_on_success     += HOST RECORD
}
=========
EXAMPLE 4
=========

service ftp
{
socket_type     = stream
wait         = no
nice         = 10
user         = root
server         = /usr/etc/in.ftpd
server_args     = -l
instances         = 4
log_on_success     += DURATION HOST USERID
access_times     = 2:00-9:00 12:00-24:00
}
=========
EXAMPLE 5
=========

# Limit telnet sessions to 8 Mbytes of memory and a total
# 20 CPU seconds for child processes.
service telnet
{
socket_type     = stream
wait         = no
nice         = 10
user         = root
server         = /usr/etc/in.telnetd
rlimit_as         = 8M
rlimit_cpu         = 20
}
=========
EXAMPLE 6
=========

#
# This entry and the next one specify internal services. Since
# this is the same service using a different socket type, the
# id attribute is used to uniquely identify each entry
#
service echo
{
id             = echo-stream
type         = INTERNAL
socket_type     = stream
user         = root
wait         = no
}
=========
EXAMPLE 7
=========

service echo
{
id             = echo-dgram
type         = INTERNAL
socket_type     = dgram
user         = root
wait         = no
}
=========
EXAMPLE 8
=========

service servers
{
type         = INTERNAL UNLISTED
protocol         = tcp
port         = 9099
socket_type     = stream
wait         = no
}
=========
EXAMPLE 9
=========

#
# Sample RPC service
#
service rstatd
{
type         = RPC
socket_type     = dgram
protocol         = udp
server         = /usr/etc/rpc.rstatd
wait         = yes
user         = root
rpc_version     = 2-4
env         = LD_LIBRARY_PATH=/etc/securelib
}
==========
EXAMPLE 10
==========

#
# Sample unlisted service
#
service unlisted
{
type         = UNLISTED
socket_type     = stream
protocol         = tcp
wait         = no
server         = /home/user/some_server
port         = 20020
}

* * * * ** * * * * * * * * * * * * * * * * * * * * *  * * * * * *
END of xinetd
* * * * ** * * * * * * * * * * * * * * * * * * * * *  * * * * * *

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Categories

%d bloggers like this: