SAINT Rules

| # SAINT Rulesets While not as potentially dangerous as the SAINT configuration file, the collection of files that make up SAINT's internal rules are also an important part of the SAINT system. All inferencing is done here. This is how SAINT 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 or potentially harmful. What is not dangerous. What network services are being run. In addition, the rules also inform SAINT to run other probes based on past input. For instance, if the host is found to run rexd, then the rexd.saint probe might be run, based on a rule contained here. The rules are written using standard SAINT operators and regular expressions. See a PERL manual or the examples below if you are unfamiliar with PERL. There are seven rule files, each governing a separate part of SAINT's behavior: rules/cve - maps vulnerability facts to CVE numbers. Also includes information on the Top 20 vulnerabilities. rules/drop - determines what facts should be ignored. rules/facts - deduces new facts from existing data. rules/hosttype - tries to recognize host types from telnet, ftp, and smtp banners. rules/services - classifies hosts by service type. rules/todo - specifies what probes to try next, given information gathered so far. rules/trust - classifies trust relationships. The easiest way to explain all of this is to just go over each file in turn. ### rules/cve The rules/cve file contains rules that map vulnerability records to the corresponding CVE numbers. Each rule is applied once for each SAINT record that contains a vulnerability. (See the SAINT Data Base Format section.) The rule format is:
        condition TAB [yes|no] TAB number(s)
Each condition is applied to the text field of each vulnerability record. If there is a match, then the corresponding CVE number or numbers, if present, are assigned to the vulnerability. If a record does not match any of the conditions in rules/cve, then no CVE number is associated with the vulnerability. The second field indicates whether or not the vulnerability is one of the SANS Top 20 Internet Security Vulnerabilities. The word "yes" in this field indicates that the vulnerability is on the list. For instance, CVE 1999-0002 corresponds to the vulnerability in `mountd`, which is on the Top 20 list. SAINT outputs the string "mountd may be vulnerable" when it finds this vulnerability. Therefore, the rule is:
        /mountd may be vulnerable/i   yes   1999-0002
### rules/drop The rules/drop file contains rules that determine what facts should be ignored. Each rule is applied once for each SAINT record that has an "a" in the status field, meaning the host is available. (See the SAINT Data Base Format section.) For instance, SAINT may detect what it thinks is an RDS vulnerability on myhost.com, even though you know for a fact that the patch has already been applied. In this case, we would tell SAINT not to report the RDS vulnerability for myhost.com:
        $target eq "myhost.com" && $text =~ /RDS/
The $target variable holds the name of the target host (or the IP address if the name couldn't be resolved), and the $text variable holds the output of the SAINT probe, which in this case was http.saint. Any of the global SAINT variables can be used. Note that eq with quotes around the expression looks for an exact match, while the `=~` operator with slashes around the expression will catch any string containing the expression. Other options are ne (not equal to) and `!~` (does not contain). ### rules/facts The rules/facts file contains rules that deduce new facts from existing data. Each rule is executed once for each SAINT record that has an "a" in the status field, meaning that the host is available. (See the SAINT database format section.) The rule format is:
        condition TAB fact
(Note: 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 is insecure without trying to probe it further, we would put:
    /runs rexd/
        $target|rexd|a|us|ANY@$target|ANY@ANY|REXD access|rexd vulnerable
The most difficult thing with the rules/facts file is that you have to understand the SAINT data base format. A good way to understand that better is to merely look at any of the .saint files in the bin directory and look to see what the probe does and what it outputs. ### rules/hosttype The rules/hosttype file contains rules that recognize host types from service 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 the code above may look fairly complex, it isn't really. Simply study the examples, and then modify the code in the examples to create your own rules. ### rules/services Very similar to the host type ruleset, the rules/services file contains rules that translate the cryptic SAINT record data to something that is more suitable for reports. Again, each rule is executed once for each SAINT record that has an "a" in the status field. The format of this file is:
        class_name
        condition TAB service_name TAB host
If host is omitted, the host in the target field of the fact is implied. The class_name is one of the following: SERVERS: The host offers a service, such as telnet, FTP, or NFS. OTHER_SERVERS: The same as above, except that OTHER_SERVERS are not listed individually in reports if there are more than five of them running on the host (unless, of course, show all services is selected). Services which are unknown or unimportant from a security perspective would fall into this class. CLIENTS: The host is a client of a service. For example, a host which mounts filesystems from an NFS server would fall into this class. 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 The rules/todo file contains rules that specify what probes to try next. Each rule is executed once for each SAINT record that has an "a" in the status field. (See the SAINT database format section.) The 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 SAINT variables, that has to be satisfied in order for SAINT to run the probe specified. When the condition is satisfied, and the tool is allowed to be run conditionally at the current attack level (see SAINT Configuration), the tool is executed as:
        tool tool-arguments target
SAINT keeps track of which tools have already been executed against which targets. For instance, if a host is running ypserv, we would typically run the ypbind.saint probe against it. This would be done as follows:
        $service eq "ypserv"              $target "ypbind.saint"
It's easy to put in a probe that 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.saint" "-u guest"
This rule would tell SAINT to run rsh.saint against every IRIX target. The "-u guest" argument tells rsh.saint to do an rsh as user guest to see if commands can be executed remotely. SAINT would then record this fact in the results. ### rules/trust Similar to the host and service type rules, SAINT uses the trust rules to translate the cryptic SAINT record data to something that is more suitable for reports. Again, each rule is executed once for each SAINT record that has an "a" in the status field. (See the SAINT database format section.) The format of this file is:
        condition TAB name of relationship
With the currrent rules/trust file, SAINT 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