[SARA IMAGE]The SARA configuration file


  1. Attack Level
  2. Which Probes Correspond to the Attack Level
  3. The What's and Where's of the Current Probe
  4. Timeouts
  5. Timeout Signals
  6. Proximity Variables - IMPORTANT
  7. Trusted or Untrusted
  8. Targeting Exceptions
  9. Workarounds: DNS, ICMP
  10. SARA Unique

The SARA configuration file (config/sara.cf) is VERY important! Almost everything SARA does when scanning hosts and networks is controlled through this file; how hard to probe the targets, how far the probes will spread from the original host, what tests will be run, etc. While a limited number of configuration options can be controlled via the HTML user interface, the very low-level variables must be configured by manually editing this file.

This file is 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.

The easiest way to explain all of the options is by simply going over each line in the file and explain what it does:

Attack Level

    # Default attack level (0=light, 1=normal, 2=heavy)
    $attack_level = 0;
This sets the attack level, which in turn tells SARA which probes to use ( see below) against a target host.

Which Probes Correspond to the Attack Level

This section is a bit tricky; the 3 types of probes (light, normal, heavy) each have a set of programs that they use when probing a remote system. As with any of the other variables in the program used, these can be changed as desired. the programs that are

However, there is one twist; not all probes are run, even though they might be listed under an attack level. If a SARA probe has a question mark ("?") appended to its name, it will run conditionally. What does this mean? Take, for instance, the NFS SARA checker. There is no reason to run it if the remote system isn't running NFS (indeed, you shouldn't run it, because the program will waste time timing out on the remote host), so SARA will only run this if it determines that NFS is being run.

So, examining the first few lines in this section reveals:

    # Probes by attack level.
    #
    # ? Means conditional, controlled by rules.todo. * Matches anything.
    @light = (
            'dns.sara',
            'rpc.sara',
            'showmount.sara?',
            );

This means that a light scan will run the dns.sara and the rpc.sara scans, and the showmount.sara if SARA determines that the target is running NFS.

A bit further down shows:

    @normal = (
            @light, 
            'finger.sara', 
            'tcpscan.sara 70,80,ftp,telnet,smtp,nntp,uucp', 
            'udpscan.sara 53,177',
            'rusers.sara?', 
            'boot.sara?',
            );

    @heavy = (
            @normal,
            $heavy_tcp_scan = 'tcpscan.sara 1-9999',
            $heavy_udp_scan = 'udpscan.sara 1-2050,32767-33500',
            '*?',
            );
Nothing unusual here, except for the tcp and udp scan numbers; these refer to the port numbers that SARA examines for signs of activity.

Status File

SARA keeps track of what the latest attack is in a file. This filename is stored in $status_file and is updated before each new probe runs:
    # status file; keeps track of what probe is currently running and at what time it started
    $status_file = "status_file";

Timeouts

Certain network probes will "hang", or continue to try to contact the remote host for a very long time. To prevent this from slowing down the overall scan, there are three timeout values (in seconds) that SARA recognizes:
    # timeout values
    $slow_timeout = 60;
    $med_timeout = 20;
    $fast_timeout = 10;
By default, all SARA probes are launched with the same timeout value, which can be set from the command line or from the HTML interface. SARA defaults to a medium timeout value.

Some tools need more time, such as the nfs checker, or the port scanner when many ports are to be scanned. For this reason you override the default timeout for specific tools. Examples:

    %timeouts = (
            'nfs-chk', $slow_timeout,
            $heavy_tcp_scan, $slow_timeout,
            );

Timeout Signals

When a timeout occurs, a signal is sent to the process running to stop it. This defaults to "9", which basically means that the process is toast:
    # what signal we send to nuke things when they timeout:
    $timeout_kill = 9;

Proximity Variables

This is probably the most critical variable in the entire SARA program. Under NO circumstances do you want to set this to anything over "3" unless you know EXACTLY what you're doing! Anything over "0" can affect sites other than your own.

Proximity refers to how close the current target is from the original target of the SARA probe. For instance, if you probe victim.com and find that nic.ddn.mil is its nameserver, then nic.ddn.mil's proximity level would be "1", and SARA might probe that host next, depending on the rules you choose.

The number of hosts SARA scans can grow exponentially, so again, be careful!

    #
    # Proximity variables; how far out do we attack, does severity go down, etc.
    #
    # how far out from the original target do we attack?
    $max_proximity_level = 0;
SARA defaults to 0, which means that it will only scan the primary targets selected.

As SARA gets farther away from the primary target, the attacks will get weaker - this presumes that you can attack your own sites as much as desired, but since you might not know where SARA will end up, you'd like to be cautious the farther away the probes are going from your own host.

    # Attack level drops by this much each proximity level change
    $proximity_descent = 1;
This value is subtracted from the current attack level - a value of zero means that attacks do not diminish in strength.

If the attack level goes below zero, do you stop or go on? The "$sub_zero_proximity" variable determines this:

    # when we go below zero attack severity, do we stop (0) or go on (1)?
    $sub_zero_proximity = 0;
SARA will, by default, examine only one target at a time. If the "$attack_proximate_subnets" variable is set to "1", then ALL targets on the secondary target's subnet will be scanned. Be VERY careful when changing this!a
    # a question; do we attack subnets when we nuke a target?
    # 0 = no; 1 = primary target subnet
    $attack_proximate_subnets = 0;

Trusted or Untrusted

By default, SARA assumes that it is being run from "inside". This means that the probing host may appear in other hosts rhosts, hosts.equiv or NFS export files.
    #
    # Does SARA run on an untrusted host? (0=no; 1=yes, this host may appear
    # in the rhosts, hosts.equiv or NFS export files of hosts that are being
    # probed).
    #
    $untrusted_host = 0;

Targeting Exceptions

Without precautions, SARA can probe sites that you might not want it to. Exceptions are a way to prevent SARA from going astray. There are two ways of setting this up, and each is controlled by a variable name. The $only_attack_these variable is a list of domains and/or networks that tells SARA to only attack hosts that match one of those patterns. For example, if you wanted SARA to only attack educational sites, you could say:
    $only_attack_these = "edu";
Similarly, there is a variable, $dont_attack_these, which you can set to a list of domains and/or networks that SARA should never attack. Looking at the last part of the configuration file gives further examples of this:
    #
    # If $only_attack_these is non-null, *only* hit sites if they are of this
    # type.  You can specify a domain (podunk.edu) or network number
    # (192.9.9). You can specify any combination of domains and or networks
    # as long as you separate them by whitespace and/or commas.
    #
    # Examples:
    #
    # $only_attack_these = "podunk.edu";
    # $only_attack_these = "192.9.9";
    # $only_attack_these = "podunk.edu, 192.9.9";
    #
    $only_attack_these = "";

    #
    # Stay away from anyone that matches these patterns.
    #
    #  Example - leave government and military sites alone:
    #
    # $dont_attack_these = "gov, mil";
    $dont_attack_these = "";

Workarounds: DNS, ICMP

DNS

SARA wants to use fully-qualified host names (host.domain) so that it can fix truncated hostnames, as found, for example, in finger output. The $dont_use_nslookup flag controls whether SARA should use the nslookup command to look up hostnames.
    # Set to nonzero if nslookup does not work.
    $dont_use_nslookup = 0;

ICMP

Before probing a host, SARA attempts to ping it. When the host does not respond, SARA assumes the host is down and skips further probes. The $dont_use_ping controls whether SARA should ping hosts before probing them. Set it to a non-zero value when ICMP does not work.
    # Set to nonzero if ICMP does not work.
    $dont_use_ping = 0;

SARA Unique Features

SARA provides the following additional configuration options
Of course, reading the perl code in the various modules can give more hints on all of these configuration file options. Also, SARA maintains a current man page at sara.8. Lastly, check out the documentation in sara.cf.
Back to the Reference TOC/Index