SAINT User Interface

3. > | # The SAINT User Interface SAINT was designed to have a very "user friendly" user interface. All of the SAINT output (except debugging output) and almost all of the SAINT user interface is written into HTML. This means, of course, that a user may use any standard Web-browser, such as Netscape or lynx, to view it. Subsections in the User Interface section: The Basics Data Management Gathering Data Looking at and understanding the results Excluding vulnerabilities from results Hints, Further tricky security implications, or Getting The Big Picture (tm) Using SAINT Remotely Using SAINT With Apache (or another web server) The Command-line Interface Scheduling Scans Using cron ### The Basics An HTML browser is required to do report queries. As all of the SAINT documentation is written in HTML, it is highly suggested that an HTML browser be used to read it. Or, if you would prefer, it may also be printed out and read as hard-copy documents. If you have any questions about the use of your Web browser, please refer to your browser's documentation. This section of the SAINT documentation details some of the basic SAINT design concepts and also how to navigate through the SAINT user interface. Having said this, though, perhaps the best way to learn the workings of the program is to simply start pointing and clicking on the different sections of the HTML user interface with your mouse. The only exception is the Target Selection screen, where trial and error might not be the best method because you could inadvertently start a scan. ### Data Management SAINT employs a very simple method for opening and/or creating any databases that it might need. These databases are where SAINT stores all of its records, such as hosts identified in a scan (in the all-hosts file), the current set of facts generated in a scan (in the facts file) and the actions to be performed next (in the todo file). See the SAINT database description if you'd like more information on those files. All of SAINT's data collection output will be written to the current set of databases, which are kept in `results/<directory name>`. The directory name can be chosen from the Configuration Management screen, the config/saint.cf file, or from the command line. A directory called saint-data will be automatically created if no other name is chosen. If you choose the SAINT Data Management from the SAINT Control Panel, you have three choices; open an existing set of data, start a new database, or to merge the contents of an on-disk database with the in-core data. Note! Opening or creating a new database will destroy all other in-core information from other databases or scans. For this reason it is a good idea to choose a database before collecting data. All queries will go to the in-core database. New data collection results, etc. will go into the currently selected on-disk database. Merging a database concatenates the contents of the chosen on-disk database to the in-core information. Although care must be taken to have enough physical memory to contain all the databases, SAINT becomes more and more interesting as more information is combined, because more correlation, trust, and patterns can be detected. In addition, when large databases from different but connected sites (i.e., users logging in from one site to another or important data sharing relationships) are combined, better information may be gleaned from both sites. For instance, a group of system administrators could exchange SAINT database information with one another in an attempt to establish a mutually beneficial security collective. In theory, it would be interesting to combine information from hundreds of thousands of hosts found on the Internet and then analyze that information (though the memory and CPU speed required to do so would be great indeed!) ### Gathering Data Using SAINT to gather information about hosts and/or networks is fairly easy. Indeed, it may be too easy, as SAINT follows lines of trust that are often hidden from casual observation. This means, of course, that you might start a SAINT scan and soon find it probing networks and hosts that you had no intention of scanning. It goes without saying that many site administrators take a dim view of any unauthorized probing of their systems, and will probably view your probe as an attack of one kind or another. As such, it pays to take precautions when performing a scan, and SAINT has several built-in features that help you in this regard. The easiest and safest way to gather it is by simply selecting a target host that you'd like to know more about and then probe that host with the default settings: no host-to-subnet expansion, and a maximum proximity level of zero. (These and other settings are discussed in greater detail in the config/saint.cf documentation.) For more information on scanning a target for the first time, see the tutorial. ### Looking at and understanding the results The SAINT Reporting & Analysis feature has often been described as "easy to use, hard to describe". Using SAINT in a sane and wise manner is up to you, but we will attempt to describe this feature in a clear and concise manner here. There are three broad categories found in the SAINT Reporting & Analysis feature (vulnerabilities, information and trust), each with fundamental differences in their approach and analysis of any data gathered during a scan. Much of the data gathered and found in each category, though, is tied together and cross-referenced in the form of hyperlinks. The categories differ in that each will emphasize and display different portions of the data. Most queries will present you with an index that facilitates movement within that query type, as the amount of information may be quite voluminous. A link will also be provided back to the table of contents. In addition, any vulnerabilities found will have either external or internal links to information describing what it is, what the existence of the vulnerability means with respect to security and information on how to fix the vulnerability. The external links might include information found on such security sites as CERT or CIAC. Now, let's take a look at the categories of information that may be viewed: Vulnerabilities. What and where are the weak points of a scanned host or network? Host Information. The host information is very important. The host information can show where the servers are on a network, identify the "important" hosts on a network, and break the network down into subnets and organizational domains. In addition, individual hosts may be queried here. Trust. SAINT is able to follow and identify the web of trust between systems, such as trust established through remote logins and trust established through shared file systems. A colored dot will appear next to every host or vulnerability listed under the above categories. The color of the dot will correspond to the severity level of the host or vulnerability. Vulnerabilities There are three basic methods for viewing the vulnerability results found after performing a scan: Approximate Danger Level: All of the probes generate a basic level of danger if they find a potential problem. This method sorts all of the problems by severity level (e.g. the most serious level compromises the "root" account on the target host, the least is a warning to check out a possibly unneeded service.) Type of Vulnerability: This method simply shows all of the vulnerability types found during the probe, plus a corresponding list of hosts that fall under the vulnerability types. Vulnerability Count: This method displays which hosts have the most problems, as indicated by the sheer number of critical problems, areas of concern, and potential problems found during the probe. It is a good idea to experiment with all of these methods when first learning SAINT. This will help you determine which is the most intuitive and informative for you, and which best suits your needs. After using SAINT for some time, it will become easier to determine which type of query will be ideal for your needs, as determined by the probe that you are conducting at the time. Host Information An enormous amount of information can be gained by examining the various subcategories of this section - remember, the more intensive the SAINT probe, the more information will be gathered. Typically this will show either the numbers of hosts that fall under the specific category with hypertext links to more specific information about the hosts, or the actual list of hosts, which can be sorted into different orders dynamically. The color of the dot next to each host corresponds to the severity level of the host. Clicking on links will give you more information on that host, network, piece of information, or vulnerability, just as expected. The categories are: Class of Service. This category shows the various network services that the collected group of probed hosts offer - anonymous FTP, WWW, etc. It is gathered by examining information garnered by rpcinfo and by scanning TCP ports. System Type. This category breaks down the probed hosts by the hardware type (Sun, SGI, Ultrix, etc.); this is further subdivided by the OS version, if possible to ascertain. This is determined by NMAP if available, or inferred by the various network banners of ftp, telnet, and sendmail. Internet Domain. This category shows the various hosts broken down into DNS domains. This is very useful when trying to understand which domains are administered well or are more important (either by sheer numbers or by examining the numbers of servers or key hosts, etc.) Subnet. A subnet (as far as SAINT is concerned) is a block of up to 256 adjacent network addresses, all within the last octet of the IP address. This is the most common way of breaking up small organizations, and can be useful for showing the physical location or concentration of hosts in larger systems. Host name. This category allows a query of the current database of probe information about a specific host. Trust This category is a way of finding out which are the most important hosts on the network. The more hosts that trust a host (e.g. depend on some service, have logged in from the host, etc.), the greater the damage that could result if it is compromised. Keep in mind that a trusted host is an attractive target for attackers; once this type of host has been broken into, the intruder has a good chance of breaking into all of its dependent hosts as well. Severity Levels All hosts and vulnerabilities reported by SAINT will be listed next to a colored dot which corresponds to the severity level. The severity level of a vulnerability indicates the potential for damage if the vulnerability is indeed exploited by an intruder, and SAINT's level of confidence that the vulnerability truly exists. The severity level of a host is the severity level of the most severe vulnerability found on the host. The following severity levels are used by SAINT: Critical Problems (Red ): Services that are vulnerable to attack. Attackers exploiting these services may cause substantial harm. Areas of Concern (Yellow ): Services that may directly or indirectly assist an attacker in determining passwords or other information that could be used in an attack. Potential Problems (Brown ): Services that may or may not be vulnerable, depending on the version and configuration. Further investigation on the part of the administrator may be necessary. Services (Green ): Any service which is running, regardless of whether or not it is vulnerable. Other Information (Black ): No services were found, or other information was found. An arrow labeled TOP 20 may also be present beside some vulnerabilities. These are the vulnerabilities which are among the SANS Top 20 Internet Security Vulnerabilities. Since these vulnerabilities account for the majority of break-ins, they are of particular concern. If SAINT does report a problem or vulnerability, it means that the problem is possibly present. For instance, the presence of TCP wrapper, a packet filter, firewall or other security measures on a target host could cause SAINT to return a false alarm. Unconfirmed vulnerabilities usually fall into the brown level, but it is also possible for a red or yellow vulnerability to be a false alarm. In that same vein, the presence of a green dot next to a host does not mean that the host has no security holes. It means only that SAINT did not find any vulnerabilities in the current scan. Re-scanning at a higher level, or running additional probes, might uncover vulnerabilities missed during the previous scan. Also, examining the SAINT database might also provide clues as to why certain security holes were, or were not, found. For example, a check of the SAINT database may show that certain probes were timing out as opposed to actually failing. If this is the case, the probes should be run again, probably with a higher timeout value. As always, clicking on the provided links will provide information on a particular host, piece of information, or vulnerability. ### Excluding vulnerabilities from results For some vulnerability checks, SAINT cannot determine with certainty whether or not the vulnerability in fact exists merely by probing it remotely. In these cases, SAINT issues a warning (usually at the brown severity level) to alert you that a possible problem exists and it should be investigated further. If, after further investigation, it is determined that the vulnerability does not exist, then the warning is a false alarm and can be ignored. #### Creating an exclusion In order to more effectively handle false alarms, SAINT gives you the option of ignoring any vulnerability with a single click of the mouse. To ignore a vulnerability, click on the Ignore link beside the vulnerability description. This action will cause the vulnerability to be removed from the current screen and from subsequent results screens #### Viewing excluded vulnerabilities Although a vulnerability may be excluded from the displayed results, it is still present in the database, so it may be viewed or unexcluded at a later time. To include excluded vulnerabilities in the displayed results, choose show excluded vulnerabilities from any of the Data Analysis screens. After that, all vulnerabilities, both excluded and non-excluded, will be displayed on the current screen and on all subsequent screens until hide excluded vulnerabilities is chosen. Excluded vulnerabilities will be indicated by a ghost icon instead of the usual colored dot. The various ghost icons are: An ignored critical vulnerability An ignored area of concern An ignored potential problem #### Removing an exclusion If circumstances change such that a vulnerability which was previously ignored should no longer be ignored, the exclusion can be removed. First, choose show excluded vulnerabilities to view the excluded vulnerability as described in the previous section. Then, choose the Don't Ignore link beside the vulnerability description. This will cause the exclusion to be removed. #### Exclusion management Besides the links mentioned above for creating and deleting exclusions, SAINT's Data Analysis section also includes two separate screens specifically for managing exclusions. The Manage Exclusions page allows you to: Choose whether to show or hide excluded vulnerabilities Choose whether to automatically save changes to the exclusion table. If this option is not selected, then exclusions created or deleted from the graphical user interface will reside in memory only. They will not be saved to disk until you choose to save them manually. Save the exclusion table to a file. The default file is `exclusions`, located in the directory indicated by `$saint_data`. Load a new exclusion table into memory. The new exclusions can either be merged with the ones already in memory, or can be used to replace the existing table. The List Exclusions page displays a list of all the exclusions which are in the current exclusion table. For each exclusion, there are three options: Don't Ignore. Remove the exclusion. Details. Expand the exclusion into its fields. The first eight fields in the exclusion record correspond to the eight fields in a fact record. (The ninth field, Version, is unused at this time.) A vulnerability is excluded if all of the fields in the fact record match the corresponding fields in the exclusion record. Edit. This option allows you to edit any of the fields in the exclusion record. This screen is where you can replace any field with an asterisk (*) which matches anything in the corresponding field in the fact record. This can be used to create a single exclusion which tells SAINT to ignore multiple vulnerabilities. For example, changing the Target field to an asterisk would tell SAINT to ignore that vulnerability on any host. Changing all fields except Severity to an asterisk would tell SAINT to ignore all vulnerabilities at that severity level. ### Hints, Further Tricky Security Implications, or Getting the Big Picture It's just as important to understand what the SAINT reports don't show as well as what they show. It can be very comforting to see SAINT returning a clean bill of health (i.e. no vulnerabilities found), but that will often merely mean that more probing should be done. Here are some general suggestions on how to get the most out of SAINT; this requires a fairly good understanding of the config/saint.cf (SAINT configuration) file: Probe your own hosts from an EXTERNAL site! This is a necessity for firewalls, and a very good idea for sites in general. Probe your hosts as heavily as possible, and use a high $proximity_descent value (2 or 3 are good.) Use a very low $max_proximity_level - it is almost never necessary to use more than 2. However, if you're behind a firewall (e.g. have no direct IP connectivity from the host that is running the SAINT scan), you can set this higher. It is very hard to envision any situation in which you will need to set this value to anything beyond single digits. Note: Be very careful if you're running SAINT behind a firewall that allows inside users to have direct IP connectivity to hosts on the Internet! You are essentially on the Internet as far as SAINT is concerned. Start with light probes and probe more heavily when you see potential danger spots. Keep tight control over what you scan - don't scan other people's hosts without permission! Use the $only_attack_these and $dont_attack_these variables to control where your attacks are going. Collect all of your user's .rhosts files and make a list of all external hosts found there. Get permission from the system administrators of those remote sites and run SAINT against all of them. If you have a host which is trusted by many other hosts, or you have a host which is critical to your organization's operations, scan them hosts with a "heavy" scan to help ensure that no one can gain access to these. Unless politically impossible, scan the entire subnet of these key hosts as well, because once on a subnet, it's very easy to break into other hosts on the same subnet. ### Using SAINT Remotely There may be situations in which you need to make SAINT's user interface available to machines other than the one on which it is running. In these situations, SAINT's remote mode may be preferred. Remote mode is ideal when you need to share results with co-workers, when you wish to run SAINT from a machine without a graphical environment, or when you wish to run SAINT from a machine whose location makes physical access inconvenient. SAINT's remote mode is administered using the following features: Host-based access control. The $allow_hosts variable in config/saint.cf (or the -h command line option) tells SAINT which hosts are allowed remote access to SAINT's user interface. The hosts are specified in the form of a space-separated list of IP addresses. An entire Class C network can be specified by putting an asterisk (*) in place of the last octet of the IP address. An asterisk all by itself will match any IP address, effectively disabling host-based access control. This is not recommended. User authentication. In remote mode, SAINT requires users to provide a login and password before being granted access to the graphical user interface. By default, there are two login names: admin and saint. The accounts are disabled by default, but they become enabled when you provide a password for them. (You are prompted to set the password when you start SAINT in remote mode.) The admin user is allowed to use any part of SAINT. Therefore, the password for admin should only be given to network administrators, or others who are authorized to configure and run SAINT scans. The saint user is only allowed to view reports, tutorials, and documentation. The password for saint may be given to anyone who is authorized to view the results of the SAINT scan. Additional users can be added by editing config/passwd. (See below.) Server port. The $server_port variable in config/saint.cf (or the -p command line option) tells SAINT which TCP port to listen on. Remote users connect to this port with their web browsers to access SAINT. The default port is 1414, but it is a good idea to change it to avoid detection by attackers who might scan the network for the default port. Use the following steps as a guide to using SAINT remotely: In config/saint.cf, set $allow_hosts equal to the IP address(es) of the remote hosts which are allowed to connect (or use the -h command-line option) Also in config/saint.cf, set $server_port equal to the port you want SAINT to listen on (or use the -p command-line option) Type `./saint -r` Set the admin and saint passwords at the prompt. If you have already set the passwords, you may hit enter to leave them unchanged or use the `-R` option to suppress the password prompt. But be aware that passwords travel over the network unencrypted whenever someone logs in, so it is a good idea to change them each time you start SAINT in remote mode. From your browser, go to `http://host.domain:port`, where host.domain is the fully-qualified host name of the machine on which SAINT is running, and port is the port number you specified earlier. Log in as either admin or saint using the passwords you set previously. If login is successful, you can use SAINT remotely at this point. When you are finished using SAINT from that client, click on the SAINT home button, and then on the log out button at the bottom of the page. Note: Simply closing the browser does not log you out. Anyone who opens a new browser on the same host will still be authenticated until either the client logs out or the SAINT server process is killed. When remote access to SAINT is no longer needed, type `./saint -k` from the Unix prompt on the server to kill the server process. Note to users using proxy firewalls: SAINT in remote mode associates each user's authentication with his or her apparent client host. That means that if SAINT is being run outside the firewall, then any user who authenticates from behind the firewall at any privilege level (e.g. admin) will effectively authenticate every host behind the firewall at that privilege level. Furthermore, any user who logs out from behind the firewall will log out every user behind the firewall. The config/passwd file SAINT's user account information and passwords are stored in the config/passwd file. Each line corresponds to one login name, and the information is kept in four fields separated by colons (:). A typical config/passwd file looks like the following: `admin:7dhc12Ux/W8Oi:0:SAINT Administrator saint:x:1:SAINT User` The first field is the login name. The second field is the password, which is encrypted using the same algorithm as a standard UNIX password file. An "x" in the password field indicates that a password has not been set, or equivalently, that the account is disabled. The third field is the user ID. A user ID of zero indicates a privileged account (i.e. the admin account). Any other user ID indicates a non-privileged account (i.e. the saint account). The fourth field is a comment field and is not used by SAINT. Additional accounts can be added by adding a line to config/passwd containing all four fields. Initially, the password field should be set to "x". The next time you start SAINT in remote mode, you will be prompted for a password for this account. The "x" will be replaced with the encrypted password. ### Using SAINT With Apache (or another web server) In some cases, it may be desirable to use Apache or another web server instead of SAINT's native server for remote usage. Third party web servers offer features which would otherwise be unavailable in SAINT, such as encrypted sessions using SSL, .htaccess access control, and logging. Fortunately, SAINT is able to interface with other web servers to take advantage of these features. Using SAINT with another web server is similar to using SAINT in remote mode. To get started, follow the steps below. (Note: The SAINT development team is unable to provide support for Apache or any other third-party software. For questions or problems related to other web servers, SSL, certificates, etc. please contact the developers of the product in question.) If the web server is not already running, then install, configure, and enable the web server in accordance with the web server's instructions. Move the `saint.cgi` script from the `scripts` directory into your web server's `cgi-bin` directory. Make sure to do this step after configuring SAINT. If your web server is not running as root (which is usually the case for a properly configured web server), enable set-userid-root mode on the `saint.cgi` script. This is done as follows:
   >     chown root saint.cgi
   >     chmod 4755 saint.cgi
Follow the instructions for using SAINT in remote mode, with the following exceptions: Type `./saint -w` instead of `./saint -r` You do not need to set `$server_port` (-p) Access SAINT from your browser by going to `http://host.domain/cgi-bin/saint.cgi` Don't forget to click the log out button when you are finished, and type `./saint -k` when access to SAINT is no longer needed. ### The Command-line Interface The command-line interface is ideal for those without a good HTML browser, for those who wish to schedule scans using cron, or for those who would rather not run the HTML browser, as it may consume several megabytes of valuable memory. All of the probing functionality is accessible via the UNIX shell prompt. The results will be sent to standard output in a fixed text format. If graphical data analysis is desired, then invoke SAINT in the usual manner after the command-line scan is finished, and go directly to Data Analysis. The syntax for running SAINT is:
       ./saint [options] [target1] [target2]...
SAINT runs a scan using the command-line interface if one or more targets are specified on the command line, or if the -F option is used to specify a target file. Otherwise, SAINT invokes the HTML browser and enters interactive mode. target1, target2, etc. can be host names, IP addresses, IP subnets, or IP address ranges. As many targets as desired can be specified on the command line, separated by spaces. Following is a list of the command line options, what they do, and what SAINT variables they correspond to. Further explanations of the variables that are mentioned here can be found in the config/saint.cf (SAINT configuration) file. -a level Attack level (0=light, 1=normal, 2=heavy, 3=heavyplus, 4=top20, 5=custom). Variable: $attack_level. -A proximity Proximity Descent. Variable: $proximity_descent. -c 'name = value; name = value...' Change SAINT variables. Use this to overrule configuration variables that do not have their own command-line option. -C custom level Custom attack level. Argument specifies which custom attack level definition to use. (Overrides -a option.) Variable: $custom_level. -d directory SAINT database (data directory) to read already collected data from, and to save new data to. Variable: $saint_data. -f Enable firewall analysis. Variable: $firewall_flag -F filename Read list of primary targets from file. Variable: $use_target_file, $target_file -g guesses Number of passwords to guess against each account. Variable: $password_guesses -h "host1 host2 ..." IP addresses which are allowed to use SAINT remotely. (Used with -r, -R, or -w option.) Variable: $allow_hosts -i Ignore already collected data. -k Kill the SAINT process running in remote mode and exit. If more than one server is running, the -p option can be used to kill only the server running on the specified port. If -p is not present, all SAINT processes are killed. -l proximity Maximal proximity level. Variable: $max_proximity_level. -L login%password Login and password of a Windows domain administrator. Variable: $domain_user -m threads Maximum number of probes which can be run concurrently. 1 disables multitasking. Variable: $maximum_threads -n netmask Netmask(s) of target hosts. Variable: $target_netmask -o list Scan only these hosts, domains or networks. Variable: $only_attack_these. -O list Don't scan these hosts, domains or networks. Variable: $dont_attack_these. -p port TCP port to listen on. (Used with -r, -R, or -k option.) Variable: $server_port. -q Quiet mode. Do not display results of scan. -r Remote mode. Variable: $remote_mode -R Remote mode without password prompt. Variables: $remote_mode and $skip_passwd. -s Enable subnet expansions. Variable: $attack_proximate_subnets. -S status_file SAINT status file (default status_file). Variable: $status_file. -t level Timeout length (0 = short, 1 = medium, 2 = long). Variable: $timeout. -u Running from an untrusted host. Variable: $untrusted_host = 1 -U Running from a trusted host. Variable: $untrusted_host = 0 -v Turn on debugging output (to stdout). Variable: $debug. -V Print version number and terminate. -w Use an existing web server. This option implies remote mode and assumes that the `saint.cgi` script is present in the web server's `cgi-bin` directory. Variable: $web_server -x Extreme mode. Run dangerous tests. (Caution!) Variable: $extreme = 1 -X Don't run dangerous tests. $extreme = 0 -z Continue with attack level of zero when the level would become negative. The scan continues until the maximal proximity level is reached. Variable: $sub_zero_proximity = 1 -Z Opposite of the -z option. $sub_zero_proximity = 0 ### Scheduling Scans Using cron The features of the command-line interface can be used by your system's cron process to schedule scans to run unattended at a pre-determined date and time. To schedule a scan, add a line to your crontab. The path to the crontab file varies on different operating systems. It can either be edited directly, or by entering `crontab -e`. The basic format of a line in the crontab is:
    minute hour date month day command
The first five fields specify the date and time at which the command should be executed. Each field is represented numerically as a single value, a range, a comma-separated list, or an asterisk which stands for any. Numbers have the following meanings: minute The minute of the hour (0 through 59) hour The hour of the day (0 through 23). Numbers lower than 12 are A.M. Numbers 12 and above are P.M. date The date of the month (0 through 31). month The month of the year (1 through 12, corresponding to January through December). day The day of the week (0 through 6, corresponding to Sunday through Saturday). The sixth field is one or more shell commands, separated by semi-colons. Note that SAINT must be started from its own directory, so the command to run SAINT should always be preceded by a `cd` command when run from the crontab. Any desired configuration options can be set using either the command-line flags or by editing the `saint.cf` file. #### Examples These examples are included to help clarify the above discussion. They are not intended to be used exactly as they appear. It is likely that you will need to change the dates, times, paths, and configuration options to suit your own needs.
    30 14 * * 6  cd /root/saint; ./saint -m 1 -q 192.168.0.1
Scan 192.168.0.1 every Saturday at 2:30 P.M. Disable multitasking (-m 1) Suppress output
    40 1 5,20 * *  cd /usr/local/saint; ./saint -F my_targets
Run SAINT at 1:40 A.M. on the 5th and 20th of every month Scan the target list in the my_targets file
    5 0 * 12 1-5  cd /root/saint; ./saint -d "my_data" 172.16.4.1-172.16.4.10
Scan the address range 172.16.4.1 through 172.16.4.10 at 12:05 A.M. every weekday (Monday through Friday) in December Save the data in the my_data directory Back to the Reference TOC/Index