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.
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 = 192.168.1.0/24
That includedir directive tells xinetd to get more configuration files
from /etc/xinetd.d, which has files:
amanda comsat echo imap kotalk ntalk rsync
amandaidx cups-lpd echo-udp imaps krb5-telnet pop3s servers
amidxtape daytime eklogin ipop2 kshell rexec
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.
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
-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
> If there's anything else you can think of that we need to add in to
> the schema, let me know.
----- End forwarded message -----
|Free forum by Nabble||Edit this page|