Help with xinetd schema?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Help with xinetd schema?

Jay Beale
I wanted to get Linux-interested people on this list thinking about our
xinetd table for the Red Hat schema.

The difficulty is that while only about 12 directives are in common use
in xinetd's configuration, there are many more that are possible.  The
real difficulty there is that all but about two can influence whether a
vulnerability is present or exploitable.  If we ignore the question of
exploitability, the number of fields that we can ignore grows.

What do y'all think?

For reference, I've quoted a message below that I wrote to Matt W. to
explain how xinetd is configured.

 - Jay

Here goes:

Basically xinetd checks /etc/xinetd.conf, which sets a few global
defaults and then uses an includedir directive to get the rest, like so:

        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
        only_from               =

includedir /etc/xinetd.d

That includedir directive tells xinetd to get more configuration files
from /etc/xinetd.d, which has files:

ls /etc/xinetd.d/
amanda       comsat       echo      imap    kotalk       ntalk   rsync
talk      vsftpd
amandaidx    cups-lpd     echo-udp  imaps   krb5-telnet  pop3s   servers
telnet    wu-ftpd
amidxtape    daytime      eklogin   ipop2   kshell       rexec
services  tftp
chargen      daytime-udp  finger    ipop3   ktalk        rlogin  sgi_fam
chargen-udp  dbskkd-cdb   gssftp    klogin  mail         rsh     swat

Each of these files contains the information that would normally be on
one line of inetd.conf.  Here's wu-ftpd:

# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#       normal, unencrypted usernames and passwords for authentication.
service ftp
        disable         =       yes
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a -d
        log_on_success          += DURATION
        nice                    = 10

The "service" line, not the filename, tells xinetd what port this
service is concerned with, as a reference into the /etc/services file.

The relevant options from this file are:

 -disable    -- whether this service is on or not ; not a required field
 -enabled    -- (rarely used) specifies a list of services to enable,
                though this is overruled by disable lines
 -server     -- what program listens on this port
 -server_args - arguments passed to <server>
 -user       -- user that xinetd should run <server> as
 -group     -- group that xinetd should run <server> as
 -groups     -- yes/no - specifies whether <server> runs with all the
                groups that the <user> normally has.
 -socket_type - mostly: TCP or UDP.  actually: stream, dgram, raw,
                seqpacket.  seqpacket = guaranteed ordering UDP
 -wait        - if yes, only allow one connection to the service
 -type     -- RPC, INTERNAL, or UNLISTED
                where RPC=remote procedure call ala NFS
                and INTERNAL = echo, chargen, and others whose
                          functionality is supplied by xinetd itself
                and UNLISTED = services that aren't listed in
                          /etc/protocols or /etc/rpc
 -rpc_number -- RPC version and number of the program being started.
 -rpc_service--     "                                        "
 -port       -- (rarely used); specifies a port number instead of the
                "service" name.  Necessary when we specify port by
 -umask      -- specifies a umask that <server> should run with.
 -only_from -- specifies n exclusive a set of IP addresses that may
                connect to this service
 -noaccess   -- specifies a set of IP addresses that may not connect to
                this service
 -env        -- a set of strings describing environment variables to set
                before running <server>
 -passenv    -- xinetd environment variables to pass to the <server>

 -flags      -- miscellaneous settings like TCP keepalives or libwrap
 -log_type   -- SYSLOG <facility> [level] or FILE <file> [soft [hard] ]
                where soft and hard are soft and hard filesize

                Both limits would be potentially used in limiting DoS
                attacks which consume filespace, but hard to specify in
 -log_on_success - logs information when a <server> starts and stops.
                This information can include <server> PID, remote client
                IP address, remote user identd name, exit status of the
                <server>, signal that forced <server> to terminate, and
                duration of the session.
 -log_on_failure - logs information when a <server> cannot be started
                due either to access restrictions or to resource
                lack/restrictions.  This can log the remote client IP,
                the remote user identd name or only the fact that a
                failed attempt was made.
 -redirect   -- transparently forwards this connection to another host
                and/or port number.  We'll need to build this in to our
                implementation to avoid false positives where someone
                has a service forwarded to someone else.

 -bind     -- restricts which interfaces xinetd listens for this port
                on.  Usually used to restrict something to

 -interface  -- <synonym for bind>

 -banner     -- file displayed whenever a connection is received
 -banner_success- displayed whenever a connection succeeds
 -banner_failure- displayed whenever a connection fails due to access

 -include    -- (rarely used); only accessible from /etc/xinetd.conf,
                this directive specifies another file to append/insert
                as a configuration file
 -includdir  -- (rarely used outside of default); only accessible from
                /etc/xinetd.conf, this directive specifies a directory
                whose files should be used as addtl config files

We can be far more comprehensive with this, so as to make sure that we
capture information that would assist with detecting configuration
work-arounds for vulnerabilties:

 -cps    -- controls connections/second, specified via two numbers.
               <first num> specifies a rate limit that causes
                deactivation of the service for <second number> seconds.
 -max_load  -- specifies a load average over which xinetd should accept
                no new connections for this service.
 -per_source -- restricts the number of connections from any one IP
                addresses to this service.
 -instances -- specifies how many connections (copies of the <server>)
               can run at the same time.
 -nice    -- "nice" number which specifies how much priority the
                scheduler should place on this process
 -rlimit_as  - address space resource limit for <server>, in Kb or Mb
 -rlimit_cpu - maximum number of CPU seconds that <server> may use
 -rlimit_data- data size resource limit for <server>, in bytes
 -rlimit_rss - maximum resident set size limit in bytes
 -rlimit_stack-maximum stack size in bytes

These fields seem less useful for our purposes:

 -access_times - specifies times during which the service may be used
 -id     -- (rarely used) specifies a unique identifier in case
                "service" is identical for two services.
 -deny_time  -- specifies a time span for the "flags SENSOR" lockout
                functionality.  When set, a user who probes a port that
                is running in SENSOR mode (serving as a portscan sensor
                rather than running a program), this number sets a
                timespan for which xinetd will take no more connections
                on any port from the offending IP address.

Of course, the problem with all this is what SQL will let us query
against and how much parsing we'd want to offload to the QNA client or
OVAL query interpreter.

Let's talk about these issues either by phone, OVAL mailling list, or
private e-mail?

> If there's anything else you can think of that we need to add in to
> the schema, let me know.

Sure will!

 - Jay

----- End forwarded message -----