Wednesday, May 15, 2013

Xinetd TCP Super-Server Daemon


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, i.e once server starts another one,
  xinetd is also referred to as a Super-Server.
 
* And since all these connections are TCP, is also called TCP Super-Server
  daemon

                                                                 xinetd services
                                                                            |                    
     --------------------------------------------------------------------------------------------------------
     |                                                                                                                              |
  single-threaded                                                                                        multi-threaded

  * xinetd starts Server-A                                            * xinetd forks a new server on every
  * Server-A services client requests                          request
  * xinetd listens on Port-A and                                 * This new child server handles the
    starts new Server-As if reqd                                    connection
                                                                                           * xinetd just listens for requests
                                                                                              and keeps on forking servers



* 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 forking 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 19 to concentrate on !

1. Global
   ------
       1 includedir   /etc/xinetd.d/

2. Daemons/Servers
   ---------------
       2 server   
       3 port      [swat]

3. Load Balancing :
   --------------
       4 disable       yes / no
       5 instances     5
       6 cps           30 30
       7 flags =       NOLIBWRAP
      
4. Access Control
   --------------
       8 only_from     IP/NW, host/domain
       9 no_access     IP/NW, host/domain
      10 access_times  9:00-1300 1400-1700
      11 per_source    1 or UNLIMITED
      12 bind          192.168.0.20     
      13 interface [aka bind]

5. Logging
   -------
      14 log_type       SYSLOG  facility.level

facility
 
daemon     system daemons w/o separate facility value auth       deprecated
                   authpriv   security/authorization messages (private)
                   user       (default) generic user-level messages
                   mail       mail subsystem
                   lpr        line printer subsystem
                   news       USENET news subsystem
                   uucp       UUCP subsystem
                   ftp         ftp daemon
                   local0-7.   reserved for local use
              
               Eg 1. Put *.* /dev/tty12 in /etc/syslog.conf
                  2. Restart syslog
                  and access your /var/log/messages on tty12
               Eg Put local5.*  /var/log/greetings or /dev/tty6
                  # logger -p local5.info "Hi from me"
                    will create/log this msg to this file or tty6
                Useful if called from shell prgs
                         
              level
                          =====
                          This  determines  the  importance  of  the message. 
                      The levels are, in order of decreasing importance:

                          Possible level names include:     
         
                      emerg    system is unusable
                  alert    action must be taken immediately
                  crit     critical conditions
                  err      error conditions
                  warning  warning conditions
                      notice   normal, but significant, condition   
                  info     informational message
                  debug    debug-level message


      15 log_on_success            PID HOST USERID EXIT DURATION
      16 log_on_failure            HOST USERID ATTEMPT

      17 banner file_name          file - shows always on connection
      18 banner_success file_name  file - shown on successful connect
      19 banner_fail file_name     file - shown if access if DENIED

-------------------------------------------------------------------------------
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.  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 :
                            --------------

-------------------------------------------------------------------------------
4. disable        This  is  boolean  "yes" or "no".  This will result in
            the service being disabled and not starting.  See  the
            DISABLE flag description.
-------------------------------------------------------------------------
5. 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.
-------------------------------------------------------------------------------
6. 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.
-------------------------------------------------------------------------------
7. flags = NOLIBWRAP
-------------------------------------------------------------------------------

                       --------------
                    4. Access Control
                       --------------

-------------------------------------------------------------------------------
08 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.
-------------------------------------------------------------------------------
09 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).
-------------------------------------------------------------------------------
10 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
-------------------------------------------------------------------------------
11 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.
-------------------------------------------------------------------------------
12 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).
-------------------------------------------------------------------------------
13  interface    Synonym for bind.
-------------------------------------------------------------------------------

                             --------
                          5. Logging
                             -------
-------------------------------------------------------------------------------
14 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.
        The facility arg is used to specify what type of prg is logging
        the  message. 
           This lets the config file specify that messages from different
           facilities will be handled differently
       
        Possible facility names include:
                 ========
       facility
       ========
          daemon,     system daemons without separate facility value
          auth,
          authpriv,   security/authorization messages (private)
          user,       (default) generic user-level messages
          mail,       mail subsystem
          lpr,        line printer subsystem
          news,       USENET news subsystem
          uucp,       UUCP subsystem
          ftp         ftp daemon
          local0-7.   reserved for local use

            level
        =====
            This  determines  the  importance  of  the message. 
        The levels are, in order of decreasing importance:

              Possible level names include:   
         
              emerg,    system is unusable
          alert,    action must be taken immediately
          crit,        critical conditions
          err,      error conditions
          warning,  warning conditions
              notice,   normal, but significant, condition   
          info,     informational message
          debug.    debug-level message

        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.

-------------------------------------------------------------------------------
15. 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
-------------------------------------------------------------------------------
16. 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).
-------------------------------------------------------------------------------
17  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.
-------------------------------------------------------------------------------
18 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.
-------------------------------------------------------------------------------
19 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.
-------------------------------------------------------------------------------
                                

0 comments:

Post a Comment