Chapter 1: Introduction

1.1: What's new in Stealth V.1.47.1

Since the MD5 hash is no longer considered to be cryptographically secure, stealth(1) should now use an alternative way to compute hash-values. In this manual it is suggested to switch to SHA1 hash computations.
The --max-size option was implement to restrict the maximum sizes of files that are downloaded from clients. By default it is 10M.

1.2: Stealth

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 controller) are different computers.
The client should accept incoming ssh-connections from the initiating computer. The controller 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 controller to use an ssh-connection to perform commands on it. The client therefore locally trusts the controller. Hence, locally trusted host.

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

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

The controller 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, a policy file is read. This determines actions to be performed, and values of several variables used by stealth.
If the command-line option --keep-alive or --repeat <seconds> is given, stealth will run as a backgrond process, displaying the process ID of the background process. With --repeat <seconds> the scan will be rerun every <seconds> seconds. The number of seconds until the next rerun will be at least 60. However, using the --rerun option a background stealth process may always be goated into its next scan. When --keep-alive is specified the scan will be performed just once, whereafter stealth will wait until it is reactivated by another run of stealth, called using the --rerun <pid> command-line option.
Then, the controller opens a command shell on the client using ssh(1), and a command shell on the controller itself using sh(1).
Next, 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. Non-zero return values will terminate stealth prematurely.
In most cases, integrity tests can be controlled by the find(1) program, 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 an internal routine of stealth to detect changes in the generated output, which could indicate some harmful intent, like an installed root-kit.
When changes are detected, they are logged on a report file, to which information is always appended. stealth never reduces or rewrites the report file. When information is added to the report file the newly written information is emailed to a configurable email address for further (human) processing. Usually this will be the systems manager of the tested client. stealth follows the `dark cockpit' approach in that no mail is sent when no changes were detected.

Alternatively, the command-line options --rerun and --terminate may be provided to communicate with a stealth process started earlier using either the --keep-alive or --repeat option. In this case,

When started using the --terminate <pid> command-line option, the stealth process running at process-ID <pid> is terminated. Note that no check is performed as to whether the process associated with <pid> is truly a stealth process. It is the responsibility of the user to make sure that the process-ID of the intended process is specified.
When started using the --rerun <pid> command-line option, the stealth process running at process-ID <pid> will perform another scan. Again, no check is performed as to whether the process associated with <pid> is truly a stealth process. It is the responsibility of the user to make sure that the process-ID of the intended process is specified.

The options --suppress and --rerun (see section 5.8) were implemented to allow safe rotations of stealth's report file.

1.2.1: The integrity of the stealth distribution

The integrity of the archive stealth-1.47.1.tar.gz can be verified as follows:

At the location where you found this archive, you should also find a file named stealth-1.47.1.dsc. This file contains a PGP signed sha1sum(1) signature of the tar.gz archive. The PGP sigature was provided by me using gpg(1) (pgp(1)).
Compute the SHA1 checksum of the stealth-1.47.1.tar.gz archive. Its value should match the SHA1 checksum that is mentioned in the stealth-1.47.1.dsc file. If not, the stealth-1.47.1.tar.gz archive has been compromised, and should not be used.
In order to verify the validity of the electronic signature, do as follows:
- Obtain my public key from a public PGP keyserver, e.g.
```
    http://pgp.surfnet.nl:11371/
            
```
- Make sure you have the right key. Its fingerprint is
```
    8E36 9FC4 1DAA FCDF 1A0D  B19F DAC4 BE50 38C6 6170
            
```
  and it has been electronically signed by, e.g., the University of Groningen's PGP-certificate authority. If in doubt, contact me to verify you have the right key.
- Once you're sufficiently satisfied that you indeed have obtained my public PGP key, verify the validity of the signature used for signing stealth-1.47.1.dsc. With gpg(1) this can be done by the command
```
    gpg --verify stealth-1.47.1.dsc
            
```

This should produce output comparable to:


gpg: Signature made Mon Aug  1 10:57:41 2005 CEST using DSA key ID 38C66170
gpg: Good signature from "Frank B. Brokken <f.b.brokken@rug.nl>"
gpg:                 aka "Frank B. Brokken <f.b.brokken@rc.rug.nl>"