Exclusion module for SARA


SARA is a network security tool with a similar heritage to SAINT and SATAN programs. Sara and Saint are still undergoing active development, at least in terms of adding additional vulnerability tests, with Sara still having open access to the latest version.

One problem I find when using Sara/Saint/Satan is that these programs can generate a fair number of false alarms, and every time I re-run these programs I spend a lot of time dismissing the same false alarms over and over again, particularly after an upgrade. Because some of the hosts on the network trust my host, but not all do, and even in the cases where there is trust is should have limits, I generally run Sara with my host NOT considered a trusted host. This alone gives a lot of false alarms, since some of the vulnerabilities are simply known trust relationships. (However, I am much more concerned about the user who reconfigures their PC to be open to the world, and if I told Sara that my host was trusted, I would not see some of those.) There are also vulnerabilities which Sara cannot definitively scan for, e.g. open mail relays, or daemons for which vulnerable and patched versions give the same signature. These problems are in many cases not a deficiency in the packages, but represent a deliberate choice to err on the side of false positives rather than false negatives, and from a security monitor's standpoint, that is generally the proper choice. (And for the most part, one can configure them to err the other way if so desired.)

However, even understanding why the false positives exist, they can be a nuisance, and perhaps even a security issue if the onus of disentangling real alerts from false alerts cause the software not to be used. Although there is little which can currently replace human involvement in sorting out this mess, I was my record keeping to be somewhat lax, causing me to repeatedly investigate the same false alarms from run to run. And so, in the interest of keeping some of this record keeping in the Sara database, I have made a tarball which adds exclusion records to Sara. This is a file of severity records which the user has decided to ignore (presumably because the perceived threat is not real) which can be saved from run to run of the program. Most all of the pages dealing with analysis of data will optionally hide any severities which you told the system to exclude/ignore, and allow easy toggling of a severity from non-excluded to excluded or back.


This package was created for version 3.3.4 of Sara, and has not been tested with any other version or other packages. In theory, it should not be difficult to port to the others, and it may even work out of the box with other versions of Sara.

The first step in installation is to get the package. It is available as a compressed tarball via ftp or via http.

Once downloaded, move the compressed tarball to the top directory of your Sara distribution (the directory containing subdirectories html, rules, results, etc.). Uncompress it (gunzip exclusions.tar.gz), and extract the files (tar -xf exclusions.tar).

NOTE: the above procedure will overwrite some of the standard Sara files, and so is not reversible, although it does not bother any files that do not come with the standard Sara distribution. If you wish to keep backup copies of the files which will be overwritten, you should first extract the file filelist.txt which lists all files included with the distribution, and backup any which you wish to keep.

Using the exclusions module

You should start Sara just as you normally would. The exclusions module has no affect on data collection, only in the analysis portion of Sara, and you should see no difference until then (you may get a warning message about not being able to read the exclusions file, which is OK since you don't have any exclusions yet).

When you start looking at the analysis pages, you will start seeing some differences. First of all, almost all analysis pages now have a link which says Show excluded records. This link, and its counterpart, Hide excluded records, determine whether or not any information regarding excluded records should appear in the analysis pages. This sets or unsets a global flag, so the setting will be retained across pages until manually set or reset. If you click on this now, the page will be reloaded, and look the same for now (since you have no exclusions defined), except the link will now say Hide excluded records.

If the page you are looking at lists specific host vulnerabilities, like for example the show vulnerabilities by danger level, you will also note that each vulnerability is followed by a link Ignore. This link is what you would follow to add that vulnerability record (for that specific vulnerability and host) to the exclusion list. If you click on it for some vulnerability, the page will reload, and if excluded records are hidden, that record would have "vanished". If excluded records are not hidden, the record would still be there, but the dot will be changed into a ghost to show that it has been excluded. (Yeah, it is a ghost. Drawing was never one of my strong points:). The color of the outline of the ghost should indicate something about the danger of the severity if it is real. If excluded records are shown, the excluded record will also have a link after it labelled Don't Ignore. Following this link will also reload the page, after removing the exclusion on the selected record (as if it were never excluded to begin with).

If you use wildcards in fields of exclusion records (not recommend in general), or somehow have multiple exclusion records applying to a single record, clicking on the Don't Ignore link following a specific vulnerability will warn you that it might delete multiple exclusion records or unexclude records for other hosts/vulnerabilities. It is generally recommended that you just don't use wild cards.

For pages which give counts of severities, usually by color, only vulnerabilities that have not been excluded will be shown unless excluded records are not hidden. In the latter case, the first number will still be the number of non-excluded vulnerabilities, but in square brackets will be the number of excluded vulnerabilities of that color (if any exist). The color of dots will also change, as excluded vulnerabilities do not count when looking for the color of the most serious vulnerability.

The table of contents for the Reporting and Analysis section also has two new pages, one to Manage exclusions and one to List exclusions. The exclusion management page is a form which enables the user to control several aspects of how the system uses exclusions. The top section sets some global options, including an alternate way of setting the visibility of excluded records, and some options related to the saving of exclusions. When Sara starts up, it reads a list of exclusions from previous runs from the file exclusions in the same directory where the facts file lies (the results directory for that data base). By default, this file must be saved manually before exitting Sara if you want any changes made that session to persist. Alternatively, you can in this section set Sara to save the exclusions file whenever an exclusion is added, deleted, or modified. You can also specify an alternate file to save to (still within the results directory for that database). Note: At this time, changing the file to save to does not affect the file from which the exclusions are initially read.

The second section of the management page allows one to manually save the list of defined exclusions to a specified file in the results directory for that database. The final section of the management page allows one to load exclusions in from a file. You can either overwrite the existing exclusions list, or merge the exclusions in the file with the ones in memory.

The list exclusions page lists exclusions by the host to which the exclusion applies. Following each exclusion are three links, enabling the exclusion to be dropped, or enabling one to see a detailed listing of that exclusion, or to edit it. This is discussed more in the section on exclusion records.

Having explained the changes in the user interface, how does one use the module? This of course, is a matter of personal taste, but I find it best to complete a scan, then go to the analysis section and start investigating the vulnerabilities it reports. If in the course of investigating a suspected vulnerability it turns out that Sara was wrong, I mark the record as excluded, and it will vanish from future runs (Sara will still check for the vulnerability, but it will not show up in the analysis pages). This can also be used for pseudo-vulnerabilities, in which the vulnerability is real in some sense, but the danger is considered too minimal to be concerned with at this time. E.g., Sara reports some of our printers as having world writable anonymous ftp; while this is actually true, the printers are physically inaccessible, so no one could use this to get free printing, and the only real threat is a DOS against our printers, and I do not consider that threat something to worry about at this time.

I would not recommend using exclusions to delete severities that have been fixed from list, as they will be deleted normally on the next scan of the host in question, and excluding it may cause you to not see it if it returns (e.g. an user putting up a rogue web server, or a PC with BackOrifice).

The exclusion record format does allow for wild-carding, even of host and vulnerability type. This is not recommended, especially unless you really know what you are doing. If done improperly, you can greatly reduce the effectiveness of scanning in the first place.

Whatever your strategy, I would also recommend that periodically review the excluded records to ensure that your logic was correct when you excluded them in the first place, and that it remains valid.

More on exclusions records

Exclusion records are essentially the same as severity records, with the addition of a field at the end called version, which is currently unused. Note however, that there can be an exclusion record for something for which there is no severity record.

The way it works is that before a vulnerability is outputted on one of the analysis pages, it is compared to the exclusion list to see if it matches any exclusion. If so, it is either not output or output as an excluded record, depending on the visibility of excluded records. The presence of an exclusion does not affect whether Sara will scan for the vulnerability, nor does it change the contents of the facts file.

A severity record matches an exclusion record if every field of the two records match, with fields matching if they are identical (string comparison) or if the field in the exclusion record is a lone asterisk (wild card, matching everything). There is a exception for the version field, in which the version fields match if either of the above hold, or if the field in the exclusion record is greater than (using the perl string comparison gt operator) the corresponding field in the severity. Currently, the version field is not used in severity records, and defaults to a null string.

The exclusion records generated by clicking on Ignore links are simply a copy of the severity record being excluded, and so are quite specific. This seems to work well, and does not appear to cause problems with an excluded severity not being recognized after another scan (i.e., I have not yet encountered a severity record that includes some information such as a timestamp which varies from scan to scan). Should such a case be encountered, it would be worthwhile to edit the severity and make the inconstant field a wild card field. Otherwise, the use of wild cards in exclusions should be handled with care --- it is possible, for example, to create an exclusion wild carding all fields, which would then cause every vulnerability (current and future) to get excluded, and thereby completely nullifying the use of the program. Of greater concern is the fact that it is possible to create wild carded records which are not so obviously misbehaving but eliminate from view vulnerabilities you wish to see.

The version field was added with the hope that it might be added to the severity/fact definition, and used by the various scanning modules. The intended purpose is that whenever a scanning module is updated in such a way that a vulnerability record it produces looks the same as one produced in a previous version but contains additional checks, the version field should be modified to indicate the change (and the modification should be such that records produced by newer versions should have a version field which is greater than (according to Perl's gt operator) than that of the older versions). This way, if the new version of the code picks up something which was not checked for in the old version (which presumably gave a false alarm), the records would no longer be excluded and the user should realize that the evaluation of the situation may need to be reconsidered.


Please note that the apparent lack of transparency around the "ghost" images (i.e. the big black square in which they sit), is not a bug in this package. The ghost images are PNG format, and everything but the ghost and outline actually are transparent, but it seems that most web browsers don't handle transparency in PNG files correctly. As the ghost images were created with Free Software Foundation tools, and parts of the GIF format are protected by patent, I am unable to convert these to GIF, which the browsers like better. Complain to the writer of your browser. Down with software patents!


Much of the code in this package comes from the Sara package, which itself is derived from the Satan code. Both appear to be covered by the Satan license. For more information regarding Sara licensing, please contact Advanced Research Corporation.

With regard to the new code, I, Tom Payerle, license all my original code in this package under standard Sara/SATAN license.

Code/File Summary

The following describes the package at a more detailed level as a guide to further development (and in case I need to go back to it at sometime in the future). There should be a reasonable amount of documentation inside the code as well.

The code changes consist of:

To avoid problems with name clobbering, the new global variables used in this package are all in the Exclusions namespace. The code also tries to make more use of lexcial variables, and use strict where convenient to try to clean up the code.

The utility scripts/readme's consist of the following:

The modifications of existing routines in the main body of Sara has been kept somewhat minimal. The only real modifications of this type are:

The new routines for processing exclusions which are not directly user interface related are found in the file html/exclusions.pl. New routines related to the user interface scripts (and not necessarily related to the exclusions part) are found in html/morehtml.pl. Some routines which might be useful for other purposes include:

The new and modified user interface scripts should be fairly self-explanatory. One should examine the contents of filelist.txt for a complete list of modified files.