Chapter 1: Introduction

Welcome to stealth. The program stealth implements a file integrity scanner. The acronym stealth can be expanded to

SSH-based Trust Enforcement Acquired through a Locally Trusted Host.

This expansion contains the following key terms:

SSH-based: The file integrity scan is (usually) performed over an ssh-connection. Usually the computer being scanned (called the client) and the computer initiating the scan (called the monitor) are different computers.
The client should accept incoming ssh-connections from the monitor. The monitor doesn't have to (and shouldn't, probably).
Trust Enforcement: following the scan, `trust' is enforced in the client, due to the integrity of its files.
Locally Trusted Host: the client apparently trusts the monitor to use an ssh-connection to perform commands on it. The client therefore locally trusts the monitor. Hence, locally trusted host.

stealth is based on an idea by Hans Gankema and Kees Visser, both at the Center for Information Technology of the University of Groningen.

stealth's main task is to perform file integrity tests. However, the testing will leave virtually no sediments on the tested computer. Therefore, stealth has stealthy characteristics. I consider this an important security improving feature of stealth.

The monitor itself only needs two kinds of outgoing services: ssh(1) to reach its clients, and some mail transport agent (e.g., sendmail(1)) to forward its outgoing mail to some mail-hub.

Here is what happens when stealth is run:

First, the policy file is read. For each client a policy file is defined, specifying the actions to be performed, and specifying the values of several variables used by stealth.
If the command-line option --daemon <uds> is specified, stealth runs as a daemon process, using the Unix Domain Socket (<uds>) for communication with stealth processes running in IPC mode.
If access to the Unix Domain Socket defined by Stealth running in daemon mode should be restricted, it can be defined in a directory with is only accessible to the user running Stealth (this will often be the root-user).
When running in daemon mode, --repeat <seconds> may be specified to rerun the integrity scan every <seconds> seconds. If an integrity scan is being performed when, according to the repeat interval the next integrity scan is due, then the current scan is first completed. Once completed, the next integrity scan will be performed after seconds seconds.
Next, the monitor opens a command shell on the client using ssh(1), and a command shell on the monitor computer itself using sh(1).
Once the command shells are available, commands defined in the policy file are executed in their order of appearance. Examples are given below. Normally, return values of the programs are tested. When return values are to be tested stealth terminates when a non-zero return value is sensed. If this happens, a message stating the reason why stealth terminated is written to the report file (and into the mail sent by stealth). In some cases (e.g., when the report file could not be written), the message is written to the standard error stream.
Very often integrity tests can be controlled using find(1), calling programs like ls(1), sha1sum(1) or its own -printf method to produce file-integrity related statistics. Most of these programs write file names at the end of generated lines. This characteristic is used by one of stealth's internal routines to detect changes in the generated output. Such changes could indicate some harmful intent, like an installed root-kit.
When changes are detected, they are logged in a report file, to which information is always appended. Stealth never reduces the report file's size or rewrites its contents. When information is added to the report file (beyond a plain time stamp) the newly added information is e-mailed to a configurable e-mail address for further (human) processing. Usually the e-mail is sent to the systems manager of the tested client. Stealth follows the `dark cockpit' approach in the sense that no mail is sent when no changes were detected.
Report and other log-files may safely be rotated between a pair of --suspend and --resume commands (see below at the section 5.7).

Instead of running in daemon mode, stealth may also run in `foreground' mode. In foreground mode the option --daemon is not specified. When running in foreground mode stealth either performs one integrity scan (and terminates) or, if the --repeat option has been specified, it repeatedly performs integrity scans, at intervals determined by the --repeat and --random-interval options. When --repeat is specified with stealth running in foreground mode a prompt is shown (i.e., `? ') with stealth terminating after pressing the Enter-key.

Alternatively, stealth may run in `inter process communication' mode (IPC mode). IPC mode is characterized by using one of the command-line options --reload, --rerun, --suspend, --resume or --terminate. In IPC-mode stealth communicates with an existing stealth daemon, using the Unix Domain Socket defined by the stealth daemon. These options require but one argument: the location of the Unix Domain Socket defined by a running stealth daemon.

When started using the --reload <uds> command-line option, the stealth daemon that created the Unix Domain Socket reloads its policy file (and skip-file), immediately followed by another integrity scan;
When started using the --rerun <uds> command-line option, the stealth daemon that created the Unix Domain Socket performs another integrity scan;
When started using the --terminate <usd> command-line option, the stealth daemon that created the Unix Domain Socket terminates.

The options --suspend and --resume (see section 5.7) were implemented to allow safe rotations of stealth's log-files.

1.1: What's new in Stealth V.4.01.10

With 4.00.00:

Version 3.00.00 was only short-lived. The inter-process communication using signals never ran smoothly. Version 4.00.00 re-implements stealth's inter-process communication using Unix Domain Sockets.
Previously required absolute file paths are no longer required. When relative file paths are used with the stealth daemon or with stealth performing an integrity scan as foreground process they are interpreted relatively to the current working directory. Relative file locations for options specified in the second section of the policy file are interpreted relative to the location of the policy file, and relative path specifications used in the first section of the policy file are interpreted relative to the policy file's USE BASE.
The README.flow file is provided with several separately provided illustrative images in the distribution-provided directory documentation/images.
Specifications for the logrotate specifications should use 'copytruncate' and 'sharedscripts' (see section 5.7 for an example)
Examples in the manual still use sha1sum when checking hash values. Stronger hash functions (like sha256sum) might be preferred in practice. When updating existing policy files to use sha256sum rather than sha1sum realize that sha256sum's hash values are longer than sha1sum's hash values, and that therefore log files obtained when sha1sum was used are incompatible with log files obtained when sha256sum was used. In practice this means that new log files need to be generated, disregarding any previously geneerated log files.