# SARA Rulesets

While not as potentially dangerous as the SARA configuration file, the collection of files that make up SARA's internal rules are probably the most important part of the entire SARA system. All inferencing is done here; this is how SARA determines, for instance, what the target's OS and hardware type is from the other data collected in the system. Generally speaking, the rule files determine:

- What is dangerous/potentially harmful.
- What is not dangerous.
- What network services are being run.

In addition, the rules also inform SARA to run other probes based on past input; for instance, if the host is found to run rexd, then the rexd.sara probe might be run, based on a rule contained here.

The files are nothing more than perl code that gets run when the program initializes; don't be intimidated by that, however - it is fairly easy to read and is heavily commented (if you don't know perl, comments (lines that don't do anything) are lines that start with a sharp/pound sign ("#")). Variables are tokens that start with a dollar sign; values of 0 or null ("") typically mean false, unless otherwise noted.

There are currently six (6) rule files, each governing a separate part of SARA's behavior (note: facts contain information that individual SARA data collection modules (e.g. the ".sara" files) collect.)

1. rules/drop - determines what facts should be ignored.
2. rules/facts - deduces new facts from existing data.
3. rules/hosttype - tries to recognize host types from telnet/ftp/smtp banners.
4. rules/services - classifies hosts by service type.
5. rules/todo - specifies what probes to try next, given information gathered so far.
6. rules/trust - classifies trust relationships.

The easiest way to explain all of this is to just go over each file in turn.

### rules/drop

This contains rules that determine what facts should be ignored. Each rule is applied once for each SARA record that has an "a" in the status field (this means the host is available; see the SARA Data Base Format section.)

For instance, SARA assumes that CD-ROM drives are not harmful for export purposes; if we see a target host that exports /cdrom or /CDROM, we assume it's harmless by telling SARA to ignore this fact:

        $text =~ /exports \/cdrom/i

(The $text variable holds the output of the SARA probe, showmount.sara in this case; any of the global SARA variables could be used.)

### rules/facts

This file contains rules that deduce new facts from existing data. Each rule is executed once for each SARA record that has an "a" in the status field. (this means the host is available; see the SARA database format section.)

The rule format is:

        condition TAB fact

(Note - the TAB is the tab character, not the three letters "T", "A", and "B"!)

For example, if we want to assume that if a host is running rexd it's insecure without trying to probe it further, we would put:

        /runs rexd/     $target|assert|a|us|ANY@$target|ANY@ANY|REXD access|rexd is vulnerable

The most difficult thing with the rules/facts file is that you have to understand the SARA data base format; a good way to understand that better is to merely look at any of the .sara files in the main SARA directory and look to see what the probe does and what it outputs.

### rules/hosttype

This file contains rules that recognize host types from telnet/ftp/smtp banners; these are applied to every record that has a telnet, ftp, or sendmail banner.

The format of this file is:

        CLASS class_name
        condition TAB hosttype

(Note - the TAB is the tab character, not the three letters "T", "A", and "B"!)

The class_name is used for the first rough breakdown by host type in reports. It should be a major software category, such as SUN, APOLLO, etc. For example, here is the code for recognizing a SUN and its major OS revision:

        CLASS SUN
        UNKNOWN && /SunOS/               "SunOS 4"
        /4.1\/SMI-4.1/                   "SunOS 4"
        /SMI-SVR4/                       "SunOS 5"

While it looks fairly impenetrable, look at the examples given if you'd like to create your own rules and steal and modify the code we use to do this.

### rules/services

Very similar to the host type ruleset, this file contains rules that translate the cryptic SARA record data to something that is more suitable for reports. Again, each rule is executed once for each SARA record that has an "a" in the status field. (this means the host is available; see the SARA database format section.)

Format of this file is:

        class_name
        condition TAB service_name TAB host

Where the class_name is SERVERS or CLIENTS. For instance, to classify a host as an NNTP server, you'd simply do this (in the SERVERS section):

        $service eq "nntp"               NNTP (Usenet news)

### rules/todo

These are rules that specify what probes to try next. Each rule is executed once for each SARA record that has an "a" in the status field. (this means the host is available; see the SARA database format section.)

Format of this file is:

        condition TAB target tool tool-arguments

(Note - the TAB is the tab character, not the three letters "T", "A", and "B"!)

The condition is a logical expression (with the usual internal SARA variables) that has to be satisfied in order for SARA to run the probe specified; when the condition is satisfied, the tool is executed as:

        tool tool-arguments target

SARA keeps track of already executed tool invocations.

For instance, if a host is running ypserv, we would typically run the ypbind.sara probe against it. This would be done as follows:

        $service eq "ypserv"              $target "ypbind.sara"

It's easy to put in a probe that, say, depends on the type of system that you're looking at. For instance, SGI/IRIX hosts have guest, lp, and other accounts with no password when taken out-of-the-box from SGI. Here's how you could check to see if this is a problem:

        /IRIX/                            $target "rsh.sara" "-u guest"

That would do an rsh as user guest to see if a command could be executed remotely; SARA would then record this fact in the results.

### rules/trust

Similar to the host and service type rules, SARA uses the trust rules to translate the cryptic SARA record data to something that is more suitable for reports. Again, each rule is executed once for each SARA record that has an "a" in the status field. (this means the host is available; see the SARA database format section.)

Format of this file is:

        condition TAB name of relationship

With the currrent rules/trust file, SARA only begins to scratch the surface. It handles only the most easily detected forms of trust:

        $severity eq "l"                        remote login
        $text =~ /exports \S+ to/               file sharing
        $text =~ / mounts \S+/                  file sharing

Back to the Reference TOC/Index