SAINT Configuration

| # The SAINT configuration file Attack Level Dangerous Checks Which Probes Correspond to the Attack Level Custom Attack Levels Password Guessing The Target File The What's and Where's of the Current Probe Timeouts Timeout Signals Multitasking Proximity Variables - IMPORTANT Trusted or Untrusted Target Netmask Targeting Exceptions Workarounds: DNS, ICMP Firewall Variables Windows Domain Authentication The SAINT configuration file (config/saint.cf) is VERY important! Almost everything SAINT 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 are lines that are inserted into a program for informational purposes, and always 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 explaining what it does. ### Attack Level The first section that we will discuss deals with the "Attack Level", or how heavily SAINT will probe a targeted host. The code will look like the sample below:
        # Default attack level (0=light, 1=normal, 2=heavy,
        # 3=heavy+, 4=top20, 5=custom)
        $attack_level = 0;
This sets the attack level, which in turn tells SAINT which probes to use against a target host. The attack level is essentially the intensity of the attack. Lighter attacks will be faster and harder to detect, but will not gather as much information as heavier attacks. The intensity of the attack is set by changing the value of the `$attack_level` variable. The various intensity levels, as you will notice in the sample above, are represented by the numbers 0 through 5, with 0 representing the lowest level and 3 the highest, and 4 and 5 representing special scan levels. Thus, in the sample above, the SAINT probe is set to run with minimum intensity. Note that an attack level of 3 (heavy+) could cause target hosts to crash. The Top 20 attack level, represented by the number 4, runs a set of probes which are chosen specifically to detect vulnerabilities on the SANS List of the Top 20 Internet Security Vulnerabilities. The Custom attack level allows users to create their own attack levels. This feature will be discussed below. ### Dangerous Checks There is one other variable which can influence the attacks that SAINT runs. The `$extreme` variable controls whether to perform dangerous tests. If this variable is set to 1, then SAINT will run dangerous tests when applicable. These tests may help SAINT eliminate false alarms by verifying the existence of certain vulnerabilities, but can cause services on the target hosts to crash as a result. Another side-effect of dangerous tests is that successful detection of a vulnerability could cause other vulnerabilities to be missed. That is, if a test crashes a service on the target, then any further tests against that service will come up negative. Targets should be re-scanned after the known vulnerabilities have been fixed in case there are other vulnerabilities that were missed because the service crashed. If `$extreme` is set to 0, then SAINT will skip these dangerous tests, and will report a potential problem if there is a possibility that the vulnerability exists. In the following example, dangerous tests will not be run.
    #
    # Whether to perform dangerous scans
    # (0 = no, 1 = yes) Caution! "yes"
    # could crash services on targets
    $extreme = 0;
#### Which dangerous checks does SAINT include? At this time, the following dangerous checks are included in SAINT: BSD-derived telnetd buffer overflow Buffer overflows in IIS 5 iPlanet Web Publisher buffer overflow iPlanet HTTP method buffer overflow IMail Web Calendaring buffer overflow ### Which Probes Correspond to the Attack Level Each of the attack levels will use certain probes. In other words, the value of the `$attack_level` variable will determine which probes are run against a targeted host. As with any of the other variables in the program, these can be changed as desired. There is, however, a catch: not all probes listed under an attack level will run in certain instances. If a SAINT probe has a question mark ("?") appended to its name, it will run conditionally. What, you may be wondering, does that mean? To illustrate, one of the probes that may be run under a certain attack level is the NFS check. The important word in the previous sentence is "may". If the target machine is not running the NFS service, there is no need to run this particular probe; indeed, to do so would waste time and would only result in a timeout. If SAINT determines that NFS is not running, it will not run this particular probe. Let's examine a sample section of code that would be found in this section of the SAINT configuration file:
        # Probes by attack level.
        #
        # ? Means conditional, controlled by rules.todo.
        # * Matches anything.
        @light = (
                'dns.saint',
    	    'ostype.saint',
                'rpc.saint',
                'showmount.saint?',
                );
A careful inspection of the code above shows that SAINT will always run the "dns.saint", "ostype.saint", and "rpc.saint" scans in this particular attack level, and will only run the "showmount.saint" scan if it is needed. Notice the presence of a question mark next to the "showmount.saint" scan, and the lack of a question mark next to the other three probes. Now, let's look at another snippet of code that will be found in this section:
       @normal = (
    	@light,
    	'finger.saint',
    	'tcpscan.saint 70,80,ftp,telnet,smtp,nntp,uucp,6000',
    	'udpscan.saint 53,177',
    	'rusers.saint?',
    	'boot.saint?',
    	'yp-chk.saint?',
    	);

       @heavy= (
    	@light,
    	'finger.saint',
            'rusers.saint?',
            'boot.saint?',
            'yp-chk.saint?',
            $heavy_tcp_scan = 'tcpscan.saint 16660,27665,
    			   65000,1-1525,1527-9999',
            $heavy_udp_scan = 'udpscan.saint 27444,31335,
    			   1-1760,1763-2050,32767-33500',
            '*?',
            );
Note that there are a few things in the "normal" and "heavy" scan levels that were not seen in "light". Firstly, "@light" is the first probe listed in the "normal" and "heavy" scan levels, meaning that every probe included in the "light" scan is also included in the higher scan levels. Secondly, the tcpscan.saint and udpscan.saint probes include their arguments, that is, a list of numbers corresponding to the port numbers which are to be scanned. (In the "heavy" scan, SAINT also defines two new variables, `$heavy_tcp_scan` and `$heavy_udp_scan`. These are only for SAINT's own convenience, so you need not be concerned with them.) Finally, the "heavy" scan includes "*?", which means that all SAINT probes which are not already in the list are run conditionally at this scan level. ### Custom Attack Levels Attack level 5 corresponds to various custom attack levels which allow the user to create his or her own scan levels consisting of any combination of probes. The custom scans can be created by defining a new list in saint.cf similar to those seen above. A custom scan can also be created from the graphical user interface by choosing Set up custom scan in Configuration Management. Which custom scan definition to use is specified by the $custom_level variable. The list @custom_levels contains a list of the names of all currently defined custom attack levels. In the following example, the http attack level, which checks only for http vulnerabilities, will run.
        # Default attack level (0=light, 1=normal, 2=heavy,
        # 3=heavy+, 4=top20, 5=custom)
        $attack_level = 5;

        # Custom attack levels
        @http = (
    	'tcpscan.saint 80',
    	'http.saint?'
        );

        # List of the user-defined scan levels
        @custom_levels = ("custom", "http");

        # Currently selected custom scan level,
        # from the list above
        $custom_level = "http";
### Password Guessing SAINT attempts to identify login account names using finger and rusers on Unix systems, and netbios requests on Windows systems. For each login account name which SAINT identifies, it then checks each account to find out whether or not its password can be guessed. The number of guesses to try against each account is limited by the `$password_guesses` variable. The default is two guesses. A value of zero will disable password guessing. A value of one will check each account only for a null password. Other values will make the following guesses, in order, until the limit is reached: null password password same as login name the word "password" login name backwards login name followed by the digit "1" Note that some systems lock out accounts after a set number of failed login attempts, usually three or greater. Setting `$password_guesses` higher than the default value of 2 will cause account lockouts on such systems, which could be a major inconvenience for the administrators and users of those systems. In the following example, the number of passwords to guess against each account has been set to two, the default. For each account that SAINT is able to identify, it will try to log in using a null password and a password the same as the login name.
    # Number of passwords to guess for each account.
    # Greater than 2 will lock out accounts on
    # some systems.
    # 0 disables password guessing.
    $password_guesses = 2;
### The Target File By default, SAINT expects you to specify the primary target(s) for the scan either on the command line or in the Primary Target Selection box. However, SAINT also gives you the option of supplying the list of primary targets in a file. `$use_target_file` is the variable that controls whether or not the primary targets are specified in a file. `$target_file` contains the filename. For example:
        # Do we want to read in a list of
        # targets from a file? (0=no; 1=yes)
        $use_target_file = 1;

        # File name of target list
        # (used if previous variable is 1)
        $target_file = "target_file";
In this example, SAINT will attempt to read a list of target hosts from a file called "target_file". ### Status File SAINT tracks each probe run, and places the names of the probes in a file. The name of this file is stored in the `$status_file` variable and is updated before each new probe runs:
        # status file; keeps track of what SAINT is doing
        $status_file = "status_file";
Notice that the name of the file in this case is "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 SAINT recognizes:
        # timeout values
        $long_timeout = 60;
        $med_timeout = 20;
        $short_timeout = 10;
The timeout value tells each probe to terminate itself after the specified time period has elapsed. By default, all SAINT probes are launched with the same timeout value, which is either the short timeout, the medium timeout, or the long timeout, except for a few probes which require more time. (See below.) Which timeout to use is specified by the `$timeout` variable:
        # which timeout to use (0=short, 1=med, 2=long)
        $timeout = 1;
This would tell SAINT to use the medium timeout value, which is 20 seconds in this case. 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 can override the default timeout for specific tools. Examples:
        $nfs_chk_timeout = $long_timeout;
        $snmp_timeout = 120;
In this case, the timeout value for the nfs-chk probe is equal to the value of $long_timeout, and the timeout value for the snmp probe is 120 seconds. The timeout value for any probe can be overridden by defining a new variable which is probename_timeout, where probename is the name of the probe (with dashes, if any, replaced by underscores). ### Timeout Signals When a timeout value has been reached, a signal is sent to the probe. This signal is represented by a numerical value. The default stop signal is 9, which will immediately terminate the probe process. For more information on the signals, and what the numerical values mean, type "man kill" on any UNIX platform. The actual code regulating this behavior will look something like this:
        # what signal we send to nuke things when they timeout:
        $timeout_kill = 9;
### Multitasking To increase the speed of a scan, SAINT can run more than one probe at a time. The maximum number of probes that SAINT will run at a time is controlled by the `$maximum_threads` variable. This value should be low for machines which are overloaded or which do not have much memory, but can be set higher to achieve faster scans on machines which have the resources available. Be careful with this value, because a value which is too high could cause SAINT to quickly use up large amounts of memory. To disable multitasking entirely, set this value to 1. The code will look like this:
        # What is the maximum number of probes which
        # can be run concurrently? (1 disables multitasking)
        $maximum_threads = 5;
### Proximity Variables This is probably the most critical variable in the entire SAINT program. Under NO circumstances do you want to set this to anything over "3" unless you know EXACTLY what you are 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 SAINT probe. For instance, if you probe victim.com and SAINT finds out that nic.ddn.mil is its nameserver, then nic.ddn.mil's proximity level would be "1". SAINT would probe that host next if `$max_proximity_level` were set to "1" or higher. (Of course, this military domain might interpret your SAINT scan as a hostile action.) If that probe reveals that nic.ddn.mil exports filesystems to some.host.gov and another.host.gov, then both of those hosts would be assigned a proximity level of "2". SAINT would probe those hosts if `$max_proximity_level` were set to "2" or higher. (Again, these government sites might interpret your scan as a hostile action.) The number of hosts SAINT scans can grow exponentially if `$max_proximity_level`, is increased. Thus, the number of angry system administrators whose networks were targeted by your scan could grow exponentially as well. So again, be careful! If you do not know what changing the proximity level will do, then don't change it. SAINT defaults to 0, which means that it will only scan the primary targets selected.
        #
        # 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;
As a safety precaution, you may configure SAINT to lessen the strength of its attacks the farther away from the primary target it gets. In other words, with each successive jump away from the original target, the scans will get weaker and weaker. This allows you to attack your own site with as much force as desired, and also ensure that outlying sites will not be attacked as intensely. But, as stated earlier, since you may not know where SAINT will wind up, caution is the key. A sample of this code is found below:
        # Attack level drops by this much each
        # proximity level change
        $proximity_descent = 1;
The value contained in the variable in the example above, `$proximity_descent`, determines how much weaker the SAINT scans will become with each successive jump from the original host. In the example above, the value assigned to `$proximity_descent` is 1. To determine the strength of the attack, this value is subtracted from the current attack level. For example, if the attack level is currently set to 2, when the attack moves one level away from the current host, the attack level will be changed to 1. If the `$proximity_descent` is set to 0, the attack will not lose strength as it moves away from the host. Note that proximity descent is only meaningful with light, medium, heavy, or heavy plus scan levels. Special scan levels (such as SANS Top 20 or custom) stay the same with increasing proximity. Proximity descent raises the question of what to do when the attack level is lowered below zero, as might happen. The `$sub_zero_proximity` variable determines what SAINT will do if this happens. A value of "0" tells SAINT not to scan a host when its attack level drops below zero. A value of "1" tells SAINT to go ahead and scan the host anyway, as if its attack level were still zero. An example of this is below:
        # when we go below zero attack level,
        # do we stop (0) or go on (1)?
        $sub_zero_proximity = 0;
In this example, SAINT will not probe a host if its proximity is great enough to cause its attack level to drop below zero. SAINT 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 question; do we attack subnets when we nuke a target?
        # 0 = no; 1 = primary target subnet
        $attack_proximate_subnets = 0;
In this example, SAINT is configured not to scan all targets on a secondary target's subnet. ### Trusted or Untrusted By default, SAINT assumes that it is being run from "outside". This means that the probing host does not appear in the target hosts' rhosts, hosts.equiv or NFS export files. This assumption affects the way SAINT performs some probes, and determines whether or not other probes can be performed at all. You will notice in the code sample below that the `$untrusted_host` variable may contain one of two values: 0, which indicates that the probing host may indeed appear in one of the aforementioned files, or 1, which means that the host performing the SAINT scan will not appear in any of the files mentioned above.
        #
        # Does SAINT run on an untrusted host?
        # (0=no; 1=yes, this host does not appear
        # in the rhosts, hosts.equiv or NFS
        # export files of hosts that are being
        # probed).
        #
        $untrusted_host = 1;
### Target Netmask To test whether a host could be an amplifier for a smurf or fraggle attack, SAINT needs to know its network and broadcast addresses. On a Class C subnet, which is the most common type, the first three octets of these addresses are the same as the host's IP address, and the fourth octet is 0 and 255, respectively. In the general case, the network address is determined by setting all of the host bits (the bits not included in the netmask) to 0, and the broadcast address is determined by setting the host bits to 1. By default, 255.255.255.0, 255.255.255.128, and 255.255.255.192 are all used as netmasks in the smurf and fraggle checks. If you know that your target network uses a different netmask, change the $target_netmask variable to the target's netmask. As suggested in the configuration file, be sure you know what you are doing before choosing a netmask less than a Class C.
    #
    # Assume targets have the following netmask(s).
    # Change this if targets use unusual subnetting.
    # Used for smurf test.
    # Be very careful if you go below this
    # (e.g. 255.255.254.0), or you might scan
    # a different Class C network.
    $target_netmask = "255.255.255.0,255.255.255.128,255.255.255
### Targeting Exceptions In many cases, if precautions are not taken, your SAINT scan may probe sites that you did not intend to target. Targeting exceptions are an excellent way to prevent this from occurring. Basically, there are two ways to configure the targeting exception feature found in SAINT. Firstly, the `$only_attack_these` variable is a list of domains and/or networks that tells SAINT to only attack hosts that match one of those patterns. Similarly, there is a variable, `$dont_attack_these`, which you can set to a list of domains and/or networks that SAINT should never attack. For example:
        #
        # 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.
        #
        $only_attack_these = "podunk.edu, 192.9.9";

        #
        # Stay away from anyone that matches these patterns.
        #
        #  Example - leave government and military sites alone:
        #
        $dont_attack_these = "gov, mil";
In this example, SAINT would only scan targets that were either in the podunk.edu domain or whose IP addresses began with "192.9.9". Hosts in the gov or mil domain would not be scanned. ### Workarounds: DNS, ICMP #### DNS SAINT 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 SAINT should use the nslookup command to look up hostnames.
        # Set to one if nslookup does not work.
        # (0 = use nslookup, 1 = don't use nslookup)
        $dont_use_nslookup = 0;
#### ICMP Before probing a host, SAINT attempts to ping it. When the host does not respond, SAINT assumes the host is down and skips further probes. The `$dont_use_ping` variable controls whether SAINT should ping hosts before probing them. Set it to a non-zero value when ICMP does not work.
        # Set to one if ICMP does not work.
        # (0 = use ping, 1 = don't use ping)
        $dont_use_ping = 0;
If `$dont_use_ping` is set to 1 (or `$firewall_flag` is set to 1 -- see below), and the primary target contains an IP address range or a subnet, then SAINT needs an alternate method of finding live hosts in the given IP address range. The alternative method is to scan each potential target for a few standard TCP ports and check whether or not there is a response, either that the port is open or that the connection is refused. The ports which are scanned for this purpose are specified by the `$std_ports` variable.
        # TCP ports to scan to find live hosts
        # when $dont_use_ping or $firewall_flag
        # are set
        $std_ports = "25,53,80,139,143";
### Firewall Variables Firewalls present some complications that require special attention by SAINT. Therefore, a number of variables have been created to help SAINT effectively scan through firewalls. The most important one, and in many cases the only one that needs to be changed, is `$firewall_flag`. As the following code shows, this variable should be set to 1 if SAINT is scanning through a firewall.
        #
        # No firewall environment (0) or expect a firewall (1)
        #
        $firewall_flag = 0;
In this example, SAINT is configured not to expect a firewall. Three more variables are included to help fine-tune the SAINT scan for a particular firewall environment. All three variables are used primarily during port scans, and are only used when `$firewall_flag` has been set to 1. `$fw_timeout` specifies the number of seconds SAINT should wait for a reply from each connection request. This allows SAINT to give up on ports that are blocked by the firewall after a few seconds rather than hanging on them indefinitely. `$fw_loadlimit` specifies the number of connection requests that SAINT will open concurrently. This prevents SAINT from overloading the system with waiting connection requests. `$fw_tcp_scan` is used instead of the regular `$tcpscan_timeout` variable for the tcpscan probe in a firewall environment. It is used to give the tcpscan probe the time it needs to complete through a firewall.
        #  Three new parameters for working
        #  in firewall environment
        #  fw_timeout
        #	  No. of seconds before
        #	  dropping connection request
        #  fw_loadlimit
        #	  Max No. of concurrent connection requests
        #  fw__tcp_scan
        #	  ~ (10000 * fw_timeout)/fw_loadlimit
        #
        $fw_timeout = 5;
        $fw_loadlimit = 20;
        $fw_tcp_scan = 1000;
### Windows Domain Authentication While some vulnerabilities on Microsoft Windows systems can be detected by an unprivileged scan, others, such as missing hotfixes and service packs, require administrative privileges on the target. In order to conduct a thorough scan of Windows targets, SAINT gives you the option of authenticating to the domain in order to detect these types of vulnerabilities. If you wish to authenticate to the domain, set the `$domain_user` variable equal to the login name of an account with administrative privileges on the domain. For security reasons, the corresponding password will be set in Target Selection and will reside only in memory, not in the saint.cf file. If you choose not to provide a login name and password, SAINT will still conduct its full set of unprivileged Windows vulnerability checks, omitting only those few which require authentication. Warning: Although SAINT takes the precaution of filtering passwords from the status file and the browser output, it could still be possible for the clear-text password to be revealed by the operating system's process list, the HTTP POST data, or a network sniffer. If you are running SAINT on an untrusted host or you are scanning targets across untrusted networks, it would be advisable not to enter the domain administrator's password. Keep in mind that SAINT's detection of Windows updates should be used as a baseline assessment only. SAINT detects Windows updates using simple checks for the presence of registry keys, which cannot always account for updates which have been incorrectly installed, uninstalled, rendered ineffective due to incorrect order of installation, or other unusual situations. For more thorough evaluation of Windows updates, it would be advisable to use one of several available patch management tools. ### A Final Note While we have touched on the major configuration issues, there are others that you may wish to familiarize yourself with. Reading the perl code in the various SAINT modules will give you more hints on the various configuration options. Back to the Reference TOC/Index