# The SARA User Interface

SARA was designed to have a very "user friendly" user interface. Since it is extremely difficult to create a good user interface from scratch, we stole everyone else's. All of the output (of the non-debugging sort) and nearly all of the interface uses HTML, so as a user you can utilize any number of incredible HTML display programs such as Netscape, Mosaic, lynx (for those stuck with text-only displays), etc.

Subsections in the User Interface section:

- The Basics
- Data Management
- Gathering Data
- Looking at and understanding the results
- Hints, Further tricky security implications, or Getting The Big Picture (tm)
- The Command-line Interface

### The Basics

An HTML browser is REQUIRED to do report queries. It is highly suggested that you use it to read the documentation, if nothing else to print it out and read it via hard-copy, since it's also all in HTML (later versions of SARA will almost certainly have non-HTML documentation, but the time pressures of the project eliminated this as a viable option for the first release of SARA.) (While all of the program interface and documentation uses hypertext extensively; it's beyond the scope of this document to explain how to use a HTML browser, but all of them come with fairly extensive documentation and are very easy to use.)

This part of the documentation covers some of the basic design concepts and how to move around the SARA user interface. However, with the exception of the target acquisition part of the program (we don't want you to learn how to probe hosts by trial and error!), the best way to learn how to use the program is to simply start pointing and clicking with your mouse or with the arrow keys on your keyboard.

### Data Management

SARA has a very simple way of opening or creating its databases (this is how SARA keeps all of its records, including the hosts that it's seen (in the all-hosts file), the current set of facts (in the facts file), and what should be run next (todo) - see the SARA database description if you'd like more information on those files.

All of SARA's data collection output will go to the current set of databases, which are kept in the results directory in a subdirectory that has the current database name. A default database, called sara-data will be automatically created if no other name is chosen.

If you choose the SARA Data Management from the SARA 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, SARA 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 (users log in from one site to another, or important data is being shared) sites are placed together, better information can be gotten for both sites. If you know friendly neighboring system administrators, instead of asking for permission to scan their site, exchange your latest SARA database with each other, and help each other out. It would be interesting to put together hundreds of thousands of hosts from the Internet and see what happens (although the memory and CPU speed required to process this amount of data would be formidable!)

### Gathering Data

Gathering information about hosts is very easy when using SARA - too easy sometimes, because it follows lines of trust that are often hidden from casual observation, and you'll soon find it scanning networks and hosts that you had no idea were connected to your net. As an intellectual or learning exercise this is wonderful, but many sites take a dim view of you probing (or "attacking", as they'll claim) their site without prior permission. So don't do it.

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 (and the subnet as well, if you wish) with the default settings: no host-to-subnet expansion, and a maximum proximity level of zero (see the config/sara.cf (SARA configuration) file for more on this.)

See the tutorial on how to scan a target for the first time.

### Looking at and understanding the results

Easy to use, hard to describe. That's how the SARA Reporting and Analysis works. There are three broad categories (vulnerabilities, information, and trust), each with fundamental differences in how they approach and analyze the data gathered from scanning. However, since so much information is tied together with the hypertext, you can start from any of these categories and find the same information but with a different emphasis or display on certain parts of the information. Most queries will present the user with an index that facilitates movement within that query type - the amount of information can get quite large - and a link that will lead the user back to the Table of Contents. In addition, vulnerabilities have links to a description of the problem, including what it is, what the implications are with respect to security, as well as how to fix it. If a CERT advisory applies to this particular problem then there is a link to that as well.

1. Vulnerabilities. This is what most people think of when they think of SARA - what/where are the weak points of the host/network.
2. Host Information. Very valuable information - this can show where the servers are, what the important hosts are, breakdown the network into subnets, organizational domains, etc. In addition, you can query about any individual host here.
3. Trust. SARA can follow the web of trust between systems - trust through remote logins, trust by sharing file systems.

Vulnerabilities

There are three basic ways of looking at the vulnerability results of your scan:

- Approximate Danger Level. All of the probes generate a basic level of danger if they find a potential problem; this sorts all the problems by severity level (e.g. the most serious level compromises root on the target host, the least allows an unprivileged file to be remotely read.)
- Type of Vulnerability. This simply shows all the types of vulnerabilities found in the probe, plus a corresponding list of hosts that fall under that vulnerability.
- Vulnerability Count. This shows which hosts have the most problems, by sheer number of vulnerabilities found by the probe.

Try looking at all of the different ways of looking at any vulnerabilities found by the probe to see which is most intuitive or informative to you; after using the tool for some time, it becomes easier to learn which type of query is the best for the current situation.

Host Information

An enormous amount of information can be gained by examining the various subcategories of this section - remember, the more intensive the SARA 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 on the fly). If there is a host listed with a red dot () next to it, that means the host has a vulnerability that could compromise it. Note that if SARA reports a problem, it means the problem is possibly present. The presence of Wietse's TCP wrapper, a packet filter, firewall, other security measures, or just incomplete information or assumptions may mean that what SARA "sees" is not the real picture. A black dot () means that no vulnerabilities have been found for that particular host yet. Note that a black dot next to the host does NOT mean that the host has no security holes. It only means that SARA didn't find any; scanning at a higher level or additional probes might find some further information, and examining the SARA database to see if probes were timing out rather than failing might mean the probes should be run a second time. Clicking on links will give you more information on that host, network, piece of information, or vulnerability, just as expected. Each service will be preceded by one of the following:

The service was not found to be vulnerable.

The service was serious vulnerabilities. Compromise of data and/or accounts is probable!

The service has vulnerabilities that could assist the hacker.

The service may be vulnerable to exploit but SARA can not determine with certainty.

The categories are:

- Class of Service. This shows the various network services that the collected group of probed hosts offer - anonymous FTP, WWW, etc. Gathered by examining information garnered by rpcinfo and by scanning TCP ports.
- System Type. 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 inferred by the various network banners of ftp, telnet, and sendmail.
- Internet Domain. 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 SARA 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. Allows a query of the current database of probe information about a specific host.

Trust

This is a way of finding out 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 more interesting it is to break-in from the outside, for once broken into an intruder could either break into or at least have a much better chance to break into the dependent hosts as well.

### Hints, Further Tricky Security Implications, or Getting the Big Picture

It's just as important to understand what the SARA reports don't show as well as what they show. It can be very comforting to see SARA 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 SARA; this requires a fairly good understanding of the config/sara.cf (SARA 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 SARA scan (Be VERY careful if you're running SARA 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 SARA is concerned), you can set this higher. There should be almost no reason to ever set this to anything beyond single digits.
- 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 SARA against all of them.
- If you have a host that a lot of other hosts trust or have critical hosts, make sure that you scan these 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.

### The Command-line Interface

For those without a good HTML browser, for those die-hard Un*x types that despise GUI's, or for simply firing off probes when you don't want to leave a several megabyte memory hog (your HTML viewer) doing essentially nothing, all of the probing functionality is accessible from your favorite Un*x shell prompt. However, you cannot examine the reports, do queries, or any of a number of other nifty things by simply using the command line. This is because the reporting programs were written to emit HTML code, and even the two hard-core Un*x hackers who wrote this program love (and hate, we must admit) what HTML can do.

SARA enters interactive mode when no target host is specified AND the -F option is not exercised.

In command line mode, target host(s) can be defined as a single host (e.g., www.foo.bar), a series of hosts (e.g., www.foo.bar, mail.foo.bar) or a sub/super net (e.g., www.foo.bar/23 [where 23 equates to a netmask of 255.255.254.0]).

Here are the command line options, what they do, and what SARA variables they correspond to. Further explanations of the variables that are mentioned here can be found in the config/sara.cf (SARA configuration) file.

-a
  Attack level (0=light, 1=normal, 2=heavy, 3=extreme, 4=custom). Variable: $attack_level.

-c 'name = value; name = value...'
  Change SARA variables. Use this to overrule configuration variables that do not have their own command-line option.

-d
  SARA database to read already collected data from, and to save new data to. Variable: $sara_data.

-f
  Instruct SARA to probe firewalled environments.

-F file
  Retrive hosts from file.

-i
  Ignore already collected data.

-l
  Maximal proximity level. Variable: $max_proximity_level.

-n
  Enable NMAP OS fingerprinting (if available)

-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.

-s
  Enable subnet expansions. Variable: $attack_proximate_subnets.

-S status_file
  SARA status file (default status_file). Variable: $status_file.

-t level
  Timeout length (0 = short, 1 = medium, 2 = long). Variable: $timeout

-T time
  Time to start parameter, days-hours:minutes (e.g., 1-16:33 will start SARA at 1633 local time tomorrow).

-v
  Turn on debugging output (to stdout). Variable: $debug.

-V
  Print version number and terminate.

-z
  Continue with attack level of zero when the level would become negative. The scan continues until the maximal proximity level is reached.

-Z
  Opposite of the -z option.

Back to the Reference TOC/Index