|
SAINT Architecture
SAINT has an extensible architecture. At the center is a relatively
small generic kernel that knows little to nothing about system types,
network service names, vulnerabilities, or other details. Knowledge
about the details of network services, system types, etc. is built into
small, dedicated, data collection tools and rule bases. The behaviour
of SAINT is controlled from a configuration file. Settings may be
overruled via command-line options or via a hypertext user interface.
The SAINT kernel consists of the following main parts:
- Magic cookie generator
- Each
time SAINT is started up in interactive mode, the magic cookie generator
generates a pseudorandom string that the HTML browser must send to the
SAINT custom http server as part of all commands.
- Policy engine.
- Given the
constraints specified in the SAINT
configuration file, this subsystem determines whether a host may be
scanned, and what scanning level is
appropriate for that host.
- Target acquisition.
- Given
a list of target hosts, this SAINT subsystem generates a list of probes
to be run on those hosts. The list of probes serves as input to the data acquisition subsystem.
The target acquisition module also keeps track of a host's proximity level, and handles the
so-called subnet expansions.
- Data acquisition.
- Given a
list of probes, this SAINT subsystem runs the corresponding data
collection tools and generates new facts. These facts serve as input to
the inference engine.
- Inference engine.
- Given a
list of facts, this subsystem generates new target hosts, new probes,
and new facts.
New target hosts serve as input to the
target acquisition subsystem; new probes are handled by the data acquisition subsystem, and new facts
are processed by the inference engine.
- Report and analysis.
- This
subsystem takes the collected data and builds a virtual hyperspace that
you can explore with your favourite HTML browser.
Once SAINT is given an initial target host, the target acquisition,
data acquisition and inference engine subsystems keep feeding each
other new data until nothing new comes up. Technically speaking, the
system does a breadth-first search.
When you start SAINT in interactive mode, i.e., using the HTML user
interface, SAINT performs the following actions before starting up
the HTML browser:
- Start the SAINT httpd daemon. This is a very limited subset of the
typical httpd daemon, sufficient to support all activities that SAINT
can perform.
- Generate a (hopefully "good") 32 byte cryptographic magic cookie for
the upcoming SAINT run. SAINT runs several system utilities in
parallel and compresses their quasi-random output with the MD5 hashing
function. The HTML browser must specify this magic cookie as part of
the URLs that it sends to the custom SAINT httpd daemon. If this key
is ever compromised, intruders could potentially execute any programs
that the SAINT program can run, with the same privileges as the user
that started the SAINT program. SAINT generates a new magic cookie for
each session. SAINT and the HTML browser always run on the same host,
so there is no need to send the magic cookie over the network.
- Read in any previously collected scan data. By default, SAINT will
read data in the $saint_data database. In the mean time HTML
browser comes up, but it will not be able to communicate with SAINT
until the database has been read in. This can take anywhere from a few
seconds to several minutes, depending on the size of the database, the
speed of the machine you're using to run SAINT on, the amount of
available RAM, etc.
The policy engine controls what hosts SAINT may probe. The probing
intensity depends on the host's proximity
level, which is basically a measure for the distance from the
initial target host(s). Probing intensities and probing constraints are
specified in the configuration file. This
file can direct SAINT to stay within certain internet domains, or to
stay away from specific internet domains.
While SAINT gathers information from the so-called primary
target(s) that you specified, the program may learn about the existence
of other hosts. Examples of such non-primary systems are:
- hosts found in remote login information from the finger
service,
- hosts that import file systems from the target, according to the
showmount command.
For each host, SAINT maintains a proximity count. The proximity of a
primary host is zero; for hosts that SAINT finds while probing a
primary host, the proximity is one, and so on. By default, SAINT stays
away from hosts with non-zero proximity, but you can override this
policy by editing the configuration file,
via command-line switches, or from the hypertext user interface.
SAINT can gather data about just the specified host(s), or it can gather data about
all hosts within an IP address range or a subnet (a block of 256 adjacent
network addresses).
The latter processes are called range scans
and subnet scans.
Target hosts may be specified by the user, or may be generated
by the inference engine when it
processes facts that were generated by the
data acquisition module.
Once a list of targets is available, the target acquisition module
generates a list of probes, according to the scanning level derived by the policy engine. The actual data collection is
done under control of the data
acquisition module.
When requested to scan all hosts in an IP address range or a subnet
(a block of 256 internet
addresses), SAINT uses the fping utility to find out what
hosts in that range or subnet are actually available. This is to avoid wasting
time talking to hosts that no longer exist or that happen to be down at
the time of the measurement. The fping scan also may discover
unregistered systems that have been attached to the network without
permission from the network administrator.
The data acquisition engine takes a list of probes and executes each
probe, after it has verified that the probe may be run at the target's
scanning level. What tool may be run at
a given scanning level is specified in the configuration file. The software keeps a
record of what probes it has already executed, to avoid doing
unnecessary work. The result of data acquisition is a list of new facts
that is processed by the inference engine.
SAINT comes with a multitude of little tools. Each tool implements one
type of network probe. By convention, the name of a data collection
tool ends in .saint. Often these tools are just a few lines of
PERL or shell script language. All tools produce output according to
the same common tool record format.
SAINT derives a great deal of power from this toolbox approach. When a
new network feature becomes of interest, it is relatively easy to add your own probe.
SAINT can probe hosts at various levels of intensity. The scanning
level is controlled with the configuration
file, but can be overruled with command-line switches or via the
graphical user interface.
- light
- This is the least intrusive scan. SAINT collects information from
the DNS (Domain Name System), tries to identify the operating system,
and tries to establish what RPC (Remote
Procedure Call) services the host offers and what file systems it
shares via the network. With this information, SAINT finds out the
general character of a host (file server, diskless workstation).
- normal (includes light scan probes)
- At this level, SAINT probes for the presence of common network
services such as finger, remote login, ftp, WWW, Gopher, email and a
few others. With this information, SAINT establishes the operating
system type and, where possible, the software release version.
- heavy (includes normal scan probes)
- After it has found out what services the target offers, SAINT looks
at them in more depth, and does a more exhaustive scan for network
services offered by the target. At this scanning level SAINT finds out
if the anonymous FTP directory is writable, if the X Windows server has
its access control disabled, if there is a wildcard in the
/etc/hosts.equiv file, and so on. Ports that are known to cause
Windows systems to crash are not scanned at this level.
- heavy plus (include heavy scan probes)
- This scanning level is the same as heavy except that it does
not attempt to avoid ports that are known to cause Windows systems to
crash.
- top 20
- This is a special scanning level designed specifically
to detect vulnerabilities
which are among the SANS
Top 20 Most Critical Internet Security Vulnerabilities.
- custom
- This scanning level allows the user to run any combination
of SAINT probes. The custom scan can be set up either by
editing the @custom array in saint.cf
or by choosing Set up custom scan from Configuration Management.
At each level SAINT may discover that critical access controls are
missing or defective, or that the host is running a particular software
version that is known to have problems. SAINT takes a conservative
approach and does not exploit the problem.
The heart of SAINT is a collection of little inference engines. Each
engine is controlled by its own rule base. The rules are applied in
real time, while data is being collected. The result of these
inferences are lists of new facts for the inference engine, new probes
for the data acquisition engine, or new
targets for the target acquisition
engine.
- rules/todo
- Rules that decide what probe to perform next. For example, when
the target host offers the FTP service, and when the target is being
scanned at a sufficient level, SAINT will attempt to determine if the
host runs anonymous FTP, and if the FTP home directory is writable for
anonymous users.
- rules/hosttype
- Rules that deduce the system class (example: DEC HP SUN) and, where
possible, the operating system release version, from telnet, ftp and
other banners.
- rules/facts
- Rules that deduce potential vulnerabilities. For example, several
versions of the FTP or sendmail daemons are known to have problems.
Daemon versions can be recognized by their greeting banners.
- rules/services
- Rules that translate cryptic daemon banners and/or network port
numbers to more user-friendly names such as WWW server, or
diskless NFS client.
- rules/trust
- Like the services rules, these rules help SAINT to classify the
data that was collected by the tools on NFS service, DNS, NIS, and
other cases of trust.
- rules/drop
- What data-collection tool output SAINT should ignore. This can be
used to shut up SAINT about things that you do not care about.
Implemented by the drop_fact.pl module.
- rules/cve
- These rules tell SAINT which CVE numbers correspond to
each vulnerability on the Common
Vulnerabilities and Exposures list.
Implemented by the cve.pl module.
Application of these rules in real time, to each tool output record,
and within the context of all information that has been collected
so far, offers an amazing potential that we are only beginning to
understand.
When SAINT scans a network with hundreds or thousands of hosts, it can
collect a tremendous amount of information. As we have found, it does
not make much sense to simply present all that information as huge
tables. You need the power of hypertext technology, combined with some
unusual implementation techniques to generate a dynamic hyperspace on
the fly.
With a minimal amount of effort (at least, by you; your computer may
disagree), SAINT allows you to navigate though your networks. You can
break down the information according to:
- Domain or subnet,
- Network service,
- System type or operating system release,
- Trust relationships,
- Vulnerability type, danger level, or count.
Breakdowns by combinations of these properties are also possible.
SAINT's reporting capabilities makes it relatively easy to find out,
for example:
- What subnets have diskless workstations,
- What hosts offer anonymous FTP,
- Who runs Linux or FreeBSD on their PC,
- What unregistered (no DNS hostname) hosts are attached to your network.
Questions like these can be answered with only a few mouse clicks.
Printing a report is a matter of pressing the print button of
your favourite hypertext viewer.
Back to the Reference TOC/Index
|