General questions
Troubleshooting
(Getting it to work/run at all)
(Problems when running it)
- SAINT doesn't find any hosts at all - it starts
and stops with "(0 host(s) visited)".
- SAINT crashed, hung, or did very odd things to a system
that it was run against.
- I'm using a B/W monitor, and it's
hard to see the difference between red and black dots. What can I do?
- How can I change from one HTML browser (e.g. Mosaic,
Netscape, whatever) to another, without running reconfig or something?
- Why does SAINT keep fingering the
same host(s) over and over again?
- 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.
- 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?
- Whenever I click on a hyper link it doesn't work.
- Whenever I click on a hyper link, it comes up with a window
asking me to save the file.
- I merged some databases together with the "merge"
function in the SAINT Data Management, but when I exited SAINT,
they weren't saved. What gives?
- I get "bin/tcp_scan: socket: Too many open files"
in the window from which I start SAINT.
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?
How do I adjust SAINT's SNMP probe for my network?
Although SAINT's SNMP module provides good scanning capabilities in
its default configuration, some options are available to modify the SNMP
tests to improve its usefulness for your site.
The guessing of read and write community strings is currently done with
a simple, brute force algorithm, repeated trying a few guesses. See the
code in bin/snmp.saint
for details. In order to guess write
community strings, it actually attempts to change the sysLocation oid
(and then changes it back if succeeded); by leaving off the -w
flag in rules/todo you can bypass the
write community string check.
SAINT currently avails itself of system identification strings it gets from
SNMP when trying to determine the system type. This is extremely useful,
particularly for segregating out network printers and other
odds and ends that are difficult to identify through the traditional SAINT
methods (ie examing telnet, ftp, and smtp headers). Of course, in order for
SAINT to read this information from the device, it needs to know the SNMP
read community string, or to guess it.
Since guessable community strings are usually not recommended,
there is an additional configuration file for providing SAINT with
read community strings for a given host. In the file
config/SNMP_communities.pl
you can list an SNMP read community
string for specific hosts, and SAINT will use that to get system information.
It will also check if the given string is guessable, unless you tell it not
to (also on a host by host basis in that same file).
Back to the Documentation TOC