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.
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.
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.
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!
With regard to the new code, I, Tom Payerle, license all my original code in this package under standard Sara/SATAN license.
The code changes consist of:
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:
html/process_html2.pl: a replacement for the default Sara
process_html routine, which hopefully will be quickly added to
the Sara main distribution, as all it really does is allows Sara to recognize
PNG files.
html/sara.pl: mainly a couple of hooks added to replace the
process_html routine with ours and so basic initialization for the exclusions.
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.