SAINT Documentation
WWDSI
SAINT Home
--------

SAINT Frequently Asked Questions (FAQ)

Table of Contents

(Last-modified: June 2000)


General questions Troubleshooting

(Getting it to work/run at all)

(Problems when running it)

Comparisons, Hype, etc. Tech stuff Really important things

How can I contact the authors?

Send mail to saint@wwdsi.com (or click on the e-mail address); this will be sent to the authors.

What is CVE?

CVE stands for Common Vulnerabilities and Exposures. According to the CVE website, the CVE list is "a list of standardized names for vulnerabilities and other information security exposures. CVE aims to standardize the names for all publicly known vulnerabilities and security exposures... The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools." For more information, see the CVE web site.

SAINT includes CVE numbers in its vulnerability reports and tutorials for easy reference to related tools and resources. See the cross-reference to find out which CVEs SAINT can detect.

What are the "Top 10 Vulnerabilities"?

The SANS Institute maintains a list of the Top 10 Internet Security Threats, which are the 10 vulnerabilities which account for the majority of all Internet break-ins. Since these vulnerabilities are of particular concern to security administrators, they are indicated by a special icon in SAINT reports. There is also a separate scanning level which can be used to quickly check for the top 10 vulnerabilities.

See the cross-reference to find out which vulnerabilities are included in the top 10.

When I try to run SAINT, it says (something like): "missing right bracket at perl/getfqdn.pl line 48, at end of line"

You need to upgrade your version of PERL - you're probably using the alpha version of PERL5.

What do I need to uncompress the SAINT tar file?

To uncompress the archives, you'll need to use the UNIX uncompress program if it ends in ".Z", or the GNU unzip if it ends in ".gz".

Where do I get a version of PERL that will work?

PERL5 is available from www.perl.com.

When I try to run saint I get "Xlib:connection to ":0.0" refused by server"

You can do a "xhost +hostname", where "hostname" is the host you're running it on, and try again. Also, look at the problems with X, networks, and SAINT.

SAINT doesn't find any hosts at all - it starts and stops with "(0 host(s) visited)".

You probably can't use ICMP to detect if a host is alive or not. Try setting "$dont_use_ping=1" in config/saint.cf (it's near the bottom.)

SAINT crashed, hung, or did very odd things to a system that it was run against.

We've received reports of various OS's that seem to have significant trouble with SAINT scans, particularily the UDP and TCP scans that span lots of ports. Among the afflicted:
  • DEC Alphas running OSF/1 1.3 - generates a kernal memory fault when the UDP scan is done, rolls over and dies. The file system is sufficiently hosed such that the system remains in single user mode upon reboot.
  • A few Mac's had ethernet problems, spewing packets back at the SAINT machine when fping-ed, causing the SAINT host to slow down tremendously trying to handle the traffic.
  • OS/2, version 3.0 of the networking code. A report that it locked up the telnet and ftp daemons. A restart of inetd is required to get things going again.
  • Ultrix systems running 4.2A - the elcsd process start to loop, consuming all available CPU cycles.
  • SunOS 5.4 - an extra inetd process is forked off, adding 1.0 to the system load.
  • Windows NT - there are a number of Windows applications which do not properly handle TCP probes from SAINT, in some cases leading to crashes. (More on this below.)
SAINT has been modified to avoid the ports used by some of the common Windows applications that are known to crash (unless you use the "heavy plus" scan level) but there are others that may still be susceptible to crashes by SAINT. If you discover that SAINT crashes a Windows application, then modify saint.cf to avoid the port(s) used by the application. For example, old versions of APC PowerChute Plus, which run on TCP port 6667, have been reported to crash due to SAINT scans. To fix this, you could edit config/saint.cf and change part of the range for tcpscan.saint, under the "@heavy" array, from 1527-9999 to 1527-6666,6668-9999.

I ran SAINT to analyze my results and the machine slows grinds down to a standstill (and possibly crashes), but I don't get any answers.

It could be, with a large amount of data, that SAINT is using too much memory to fit in your machine. An enormous amount of memory is consumed by the program (see memory requirements for more on this.) Try checking the memory used by SAINT on your machine; if it needs more, get more memory - adding swap space is a very painful way of trying to deal with this.

Given that SAINT starts its own http server on the local host, why doesn't it use 'localhost' instead of the FQDN of the local host when trying to contact it?

This breaks some HTML browsers. Try running with $dont_use_nslookup (found in config/saint.cf) when your naming service is crippled.

Whenever I click on a hyper link it doesn't work.

Be careful if you use proxy services (typically if you're behind a firewall you do) to access the WWW - you should unset environment variables (such as $http_proxy $file_proxy, $socks_ns, etc.) and/or change your browser's configuration not to use your SOCKS host or HTTP Proxy host (in your HTML browser's option section.)

Also check that your IP address is mapped correctly to your host name in /etc/hosts. If all else fails, try setting the $my_address variable to your IP address in config/saint.cf.

Also, Solaris 2.6 systems with certain versions of Netscape have been reported to have trouble with SAINT's html interface. If you find that hyperlinks do not work and none of the solutions above fix the problem, try upgrading to Netscape Communicator 4.7 or higher. If that is not possible, then install the html.pl patch as follows:

cd perl
patch < html.pl.patch

Whenever I click on a hyper link, it comes up with a window asking me to save the file.

You need to set your browser to handle URLs with the .pl extension as regular HTML. In Netscape, this can usually be done by selecting Preferences under the Edit menu, and then selecting Applications. PERL programs (.pl) should have MIME type text/html and should be handled by the browser itself.

I merged some databases together with the "merge" function in the SAINT Data Management, but when I exited SAINT, they weren't saved.

The database merging only works in memory. Currently there is no way to save this to disk.

I get "bin/tcp_scan: socket: Too many open files" in the window from which I start SAINT.

The machine's open file table is getting exhausted. Tcp_scan backs off and succeeds after a few attempts. You'll need to build a bigger kernel or run fewer processes.

I'm trying to get SAINT running on my Linux box.

There are two different targets for compiling SAINT on Linux, linux-old and linux-new. Users of Red Hat 6.x and above, and other recent versions of Linux, should compile using make linux-new. Users of older versions of Linux should use make linux-old. If one target doesn't work on your system, then try the other.

Why does it scan sites other than your own?

All the hosts scanned with SAINT are scanned because it gives a clearer picture of what the network security of your site is, by examining the webs of trust and the possible avenues of approach or attack. Since there is no way that SAINT could, a priori, know where it is going to scan, we decided that instead of placing artificial constraints on the program, we would allow the system administrator to place his or her own constraints on where SAINT would run, via the configuration file. See targeting exceptions.

Why doesn't it warn remote hosts that it is probing them?

This could be built into SAINT; the most reliable general solution would be to send mail to the probed system (say, to "root" or "postmaster"). A beta-tester suggested that an entry could be written to the target's syslog. Neither of the solutions are incredibly reliable. The former relies on someone reading the mail and the account existing, as well as having to deal with hundreds if not thousands of pieces of mail that might go to machines that the user of SAINT controls. The latter has several problems, first and foremost in that it depends on people actually looking at the syslog records, and secondly that if an intruder uses SAINT to break in, they will typically "flatten", modify, or simply destroy such records. Finally, many systems don't run or have non-standard syslog programs and quite a few filter out requests with packet filters, so they would never see the warning.

What's the difference between it and COPS?

COPS is a host-based UNIX security auditing tool; that means you run it on the host you wish to examine the security of. SAINT is a remote network security auditing tool, which means it can report on the security of any host OR network that has IP connectivity to where you run the tool; you don't need an account or privileges on the remote targets to report on them.

What's the difference between it and ISS and other remote scanners?

ISS, and any other remote auditing tool that we're aware of, scans a network or remote host and then reports on any problems that it may find. While SAINT does that as well, the inferencing, the web of trust that it uncovers, the automatic probing of secondary targets, the rich reporting schema with context sensitive hypertext links to the documentation, the rich configurability, etc. all make SAINT different to what is currently available.

What's a remote security auditing tool/probe/scanner?

This means it can report on the security of any host OR network that has IP connectivity to where you run the tool; you don't need an account or privileges on the remote targets to report on them.

I'm using a B/W monitor, and it's hard to see the difference between different colored dots. What can I do?

Use a text browser, such as lynx. Instead of dots, you will see the words "red", "yellow", "brown", "green", and "black".

How can I change from one HTML browser (e.g. Mosaic, Netscape, whatever) to another, without running reconfig or something?

Simply edit the file config/paths.pl. You'll see a line that looks like:
    $MOSAIC = "/usr/local/bin/netscape";
Change the path inside the parenthesis to point to wherever your preferred browser is; for instance, if you want to use Mosaic, and it's in /usr/bin/X11, you'd change the above line to:
    $MOSAIC = "/usr/bin/X11/Mosaic";

Why does SAINT keep fingering the same host(s) over and over again?

SAINT will finger a host repeatedly if it gets new information about the host; for instance, if it finds out that a user might exist on a host, it will finger to try and find out remote login information.

SAINT died (or the machine crashed, or whatever) in the middle of a run - do I have to start everything over again?

SAINT saves data at regular intervals to its database files; the easiest thing to do is to simply start it up again, with the same target and probe levels. If SAINT has remembered anything, it will grind away for awhile, finding out what it has seen before, and then resume on the targets that it hasn't scanned.

How can I tell if anyone is running SAINT against me?

CIAC wrote and is distrbuting something called Courtney, but it is far from foolproof. It is very difficult to detect the lighter SAINT scans; the heavier ones, however, are typically best detected by running Wietse's tcpd wrappers and examining the logs - a good tipoff is if many of your machines in the same area log connections from the same remote site. Some of the SAINT probes output a message to the console - if users report odd messages on their console screen, take them seriously.

{When is the port of/can you help me port/do you have any information on porting} SAINT to MacOS/DOS/VMS/MVS/Whatever?

SAINT, at least on the server side, is heavily linked to UNIX and PERL5. While it might be possible to port SAINT to one of these other OS's, it would be fairly difficult and the development team feels its efforts would be better spent continuing the development of SAINT for UNIX.

I see a lot of odd files that are appearing on my system after running SAINT, such as /tmp/sh11318, tmp_file.1288, etc.

SAINT uses PERL extensively in it's tests; the .saint probes use such commands as:
    open(FOO, "|program <<_EOF
    some input
    more input
    _EOF");
This will leave a temporary file behind when SAINT determines that they have run out of time and kill off the probe. Almost all temporary files that are created at various times within SAINT are deleted automatically, but since the << files are created internally by the shell, it is impossible for SAINT to know how to delete the files that remain. Simply delete them, or create a cron job to automatically sweep the /tmp directory for you.

Why doesn't SAINT check for [insert your favorite bug here]?

There are several reasons why SAINT does not probe for all known bugs:
  • Pointing out bugs is one thing, but fixing them is not always possible. SAINT focuses on problems that can be fixed or worked around by the system administrator, at least when the operating system version is reasonably up to date.
  • Many bugs are *extremely* difficult to check for, especially when you're dealing with code that has to return a yes or no in a very short time over potentially thousands of hosts.

Why does SAINT continue to report vulnerabilities even after I've implemented the fixes?

Some vulnerabilities are difficult to confirm with a network scan, especially since SAINT does not use exploits which could penetrate or harm your systems. When SAINT detects a possible vulnerability which it cannot confirm, it reports the vulnerability so that you can read the tutorial and determine whether or not your system is vulnerable. These vulnerabilities are usually "brown" (potential) vulnerabilities. If you know that the fixes have been implemented, you can disregard the warning, or better yet, instruct SAINT not to report them. See how can I teach SAINT to ignore what it thinks is a vulnerability?

Back to the Documentation TOC