table of contents
stealth(1) | Security Enhancement | stealth(1) |
NAME¶
stealth - Stealthy File Integrity ScannerSYNOPSIS¶
stealth -dcnoq -i <interval> -r <nr> -s skip-filesDESCRIPTION¶
The name of the stealth program is an acronym of:SSH-based Trust Enforcement Acquired
through a 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. Hopko Meijering provided valuable suggestions for
improvement.
stealth’s main task is to perform file integrity tests. However,
the testing itself will leave no sediments on the tested computer. Therefore,
stealth has stealthy characteristics. This is considered an
important security improving feature.
On the other hand, one should realize that stealth intends to be just
another security tool: other security measures like firewalls, portscanners,
intrusion detection systems, abolishment of unencrypted protocols, etc. are
usually required to improve or promote the security of a group of computers
that are connected to the Internet.
stealth uses a policy file to determine the actions to perform. Each
policy file is uniquely associated with a host to be tested. This remote host
(called the client below) trusts the computer on which stealth
runs (hence: a Locally Trusted Host), called the controller. The
controller performs tasks (normally file integrity tests) that Enforce
the Trust we have in the client computer. Since almost all integrity
tests can be run on the client, one controller can control many clients, even
if the controller itself uses aged hardware components.
As the controller and the client normally are different computers, the
controller must communicate with the client in a secure fashion. This is
realized using SSH. So, there’s another element of `local trust’
involved here: the client should permit the controller to set up a secure SSH
connection allowing the controller to access sensitive files and private parts
of the client’s file system.
It is important to ensure that there is no public access to the
controller. All inbound services should be denied. The only access to
the controller should be via its console and the controller should be
placed in a physically secure location. Sensitive information of
clients are stored in the controller, and passwordless access to
clients can be obtained from the controller by anyone who gains
(root)-access.
The controller itself only needs two kinds of outgoing services: SSH 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 using the first synopsis:
- o
- First, the policy file is read. This determines the actions to be performed, and the values of several variables that are used by stealth.
- o
- If the command-line option --keep-alive pidfile is specified, stealth will run as a backgrond process, writing its process id in the file pifile. 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 pidfile option a background stealth process may always be forced into its next scan. When --keep-alive is specified the scan will be performed just once, whereafter PROGRAM will wait until it is reactivated by another run of stealth, called using the --rerun pidfile command-line option (note that integrity scans are suppressed between a --suppress and a --resume command, see below). Consider specifying --quiet (see below) when --keep-alive is used.
- o
- Then, the controller opens a command shell on the client using ssh(1), and a command shell on the controller itself using sh(1).
- o
- 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 this case, a message about the reason why stealth terminated is written to the report file (and into the mail message 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.
- o
- 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.
- o
- 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. Whenever information is added to the report file (exceeding a plain time stamp) the appended 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.
- o
- When the --repeat or --rerun options are issued, the report
file should not be rotated by, e.g., a log-rotating process, but the
report file may safely be rotated between a pair of --suppress and
--resume commands.
REPORT FILE ROTATION¶
Since stealth only appends information to the report file, it will eventually grow to a large file, and log-rotation may be desirable. It is of course possible to issue a --terminate command, rotate the logfiles, and restart stealth, but stealth also offers a facility to temporarily suppress further scans:- o
- Starting stealth using the option --suppress pidfile will suppress a currently active stealth process. If stealth is actually performing a series of integrity scans when --suppress is issued, the currently executing command is first completed before the --suppress command completes. Once --suppress is active, all scheduled scans are skipped and --rerun is ignored. However, the --resume and --terminate options are still handled.
- o
- Once `stealth --suppress pidfile’ has returned, the report file may safely be rotated (using, e.g., logrotate(1)), and a new (empty) report file may optionally be created by the logrotation process.
- o
- Finally, when the log-rotation has been completed, the
log-rotation process should issue the command ` stealth --resume
pidfile’. This will resume a suppressed stealth process,
immediately performing the next integrity scan (thus implying --rerun),
whereafter stealth will be back in its normal integrity scanning
mode (so, resuming repeated scans if originally requested so).
RERUN AND TERMINATE¶
Here is what happens when stealth is run using other synopses:- o
- When started using the --rerun pidfile command-line option, the stealth process associated with process id file pidfile will perform another scan. This command has no effect following a --suppress command.
- o
- When started using the --terminate pidfile command-line
option, the stealth process associated with process id file pidfile
is terminated.
OPEN SSH LINK TO CLIENTS¶
The --keep-alive, --repeat, --rerun, --resume and --suppress options were implemented in such a way that the ssh link to the client remains open, thus minimizing the number of sshd entries caused by PROGRAM in the client’s log files.THE POLICY FILE¶
The policy file consists of two sets of data: use directives (starting with the keyword USE) and commands. Blank lines and information beyond hash-marks (#) are ignored, while lines following lines terminating in backslashes (\) will be concatenated ( en passant removing the backslashes). Initial white space on lines of the policy file is ignored.DEFINE DIRECTIVES¶
DEFINE directives may be used to associate longer strings of text with certain symbols. E.g., after DEFINE FINDARGS -xdev -type f -exec /usr/bin/sha1sum {} \; the text ${FINDARGS} may be used in USE DIRECTIVES and commands (see below) to use the text associated with the FINDARGS symbol. Note that DEFINE symbols may be used in the definition of other DEFINE symbols as well. Direct or indirect circular definitions should be avoided, as they are either not or incompletely expanded.USE DIRECTIVES¶
The following USE directives may be specified (directives are written in capitals, and should appear exactly as written below: letter casing is preserved). Specifications in angular brackets (like <this>) represent specifications to be given by users of stealth:- o
- USE BASE <basedirectory>
- o
- USE DD <dd>
- o
- USE DIFF <diff>
- o
- USE EMAIL <address>
- o
- USE MAILER <mailer>
- As an alternative, the script stealthmail is provided. It offers a convenient filter sorting stealth’s output and keeping only lines containing ADDED, MODIFIED, REMOVED and STEALTH. Usually these lines are are the ones system managers are interested in. The report and log files can always be consulted to determine the actual nature of the changes.
- o
- USE MAILARGS <args>
- o
- USE REPORT <reportfile>
- o
- USE SH <sh>
- o
- USE SSH <user>
- In practice, connecting to a account using the sh(1)
shell is preferred. When another shell is already used by that account,
one should make sure that that shell doesn’t setup its own
redirections for standard input and standard output. One way to accomplish
that is for force the execution of /bin/sh in the USE SSH
specification. Examples:
# root’s shell is /bin/sh: USE SSH root@client -T -q # root uses another shell USE SSH root@client -T -q exec /bin/bash # an alternative: USE SSH root@client -T -q exec /bin/bash --noprofile
# For stealth inspecting localhost: USE SSH /bin/bash --noprofile
COMMANDS¶
Following the USE specifications, commands can be specified. The commands are executed in their order of appearance in the policy file. Processing continues until the last command has been processed or until a tested command (see below) returns a non-zero return value.LABEL COMMANDS¶
The following LABEL commands are available:- o
- LABEL <text>
- The text may contain \n characters (two characters) which are transformed to a newline character.
- Example:
LOCAL COMMANDS¶
The following LOCAL commands are available to be executed on the controller:- o
- LOCAL <command>
- o
- LOCAL NOTEST <command>
- o
- LOCAL CHECK [LOG =] <logfile>
<command>
- Note that eventually many logfile.YYMMDD-HHMMSS files could be created: It is up to the controller’s systems manager to decide what to do with old datetime-stamped logfiles.
- The logfile specifications may use relative and absolute paths. When relative paths are used, these paths are relative to BASE. When the directories implied by the logfile specifications do not yet exist, they are created first.
- Example:
- o
- LOCAL NOTEST CHECK <logfile> <command>
- Example:
REMOTE COMMANDS¶
Remote commands are commands executed on the client using the SSH shell. These commands are executed using the standard PATH set for the SSH shell. However, it is advised to specify the full pathname to the programs to be executed, to prevent ``trojan approaches’’ where a trojan horse is installed in an `earlier’ directory of the PATH-specification than the intended program. Two special remote commands are GET and PUT, which can be used to copy files between the client and the controller. Internally, GET and PUT use the DD use-specification. If a non-default specification is used, one should ensure that the alternate program accepts dd(1)’s if=, of=, bs= and count= options. With GET the options bs=, count= and of= are used, with PUT the options bs=, count= and if= are used. Normally there should be no need to alter the default DD specification. The GET command may be used as follows:- o
- GET <client-path> <local-path>
- Example:
- o
- GET NOTEST <client-path> <local-path>
- Example:
- o
- PUT <local-path> <remote-path>
- Example:
- o
- PUT NOTEST <local-path> <remote-path>
- Example:
- o
- <command>
- o
- NOTEST <command>
- o
- CHECK [LOG =] <logfile> <command>
- Note that the command is executed on the client, but the logfile is kept on the controller. This command represents the core of the method implemented by stealth: there will be no residues of the actions performed by stealth on the client computers.
- Several examples (note the use of the backslash as line continuation characters):
- CHECK LOG = remote/ls.root \
- All suid/gid/executable files on the same device as the root-directory (/) on the client computer are listed with their permissions, owner and size information. The resulting listing is written on the file BASE/remote/ls.root.
- CHECK remote/sha1.root \
- The SHA1 checksums of all suid/gid/executable files on the same device as the root-directory (/) on the client computer are determined. The resulting listing is written on the file BASE/remote/sha1.root.
- o
- NOTEST CHECK [LOG =] <logfile>
<command>
- Example:
- The SHA1 checksums of all suid/gid/executable files on the
same device as the root-directory (/) on the client computer are
determined. The resulting listing is written on the file
BASE/remote/sha1.root. stealth will not terminate if the
/usr/bin/find program returns a non-zero exit value.
OPTIONS¶
Long options are given immediately following the short-option equivalents, if available. Either can be used.- o
- -d --debug: Write debug messages to std error;
- o
- -c --parse-config-file: Process the config file, no further
action,
- o
- -e --echo-commands: echo commands to std error when they are processed (implied by -d);
- o
- -i --random-interval <interval>[m]>: start the scan a random interval of <interval> seconds (or minutes if an `m’ is appended to <interval>) following the delay specified at --repeat (see below). This option is ignored unless --repeat is provided as well.
- o
- -n --no-child-processes: No child processes are executed:
child actions
- o
- -o --only-stdout: Scan report is written to stdout. No mail
is sent.
- o
- -q --quiet: Suppress progress messages written to stderr;
- o
- -r --run-command <nr>: Only run command <nr> (natural number). Command numbers are shown by stealth -c;
- o
- -s --skip-files <skippath>: All entries in skippath (specified using an absolute path) are skipped. Their integrity is not monitored. If an entry is already present in a log file then stealth will once generate an IGNORING message in the mail sent to the address specified at EMAIL in the policy file. Each entry mentioned in filepath must be on a line of its own and must be specified using absolute paths. Entries ending in a slash are assumed to be directories whose contents must be skipped. Other entries are interpreted as the path names of files to skip. Initial and trailing blanks, empty lines and lines having a # as their 1st non blank character are ignored. If the
- o
- -v --version: Display version information and exit;
- o
- --keep-alive pidfile: Keep running as a daemon, wake up at interrupts.
- o
- --max-size <size>[BKMG]: the maximum file size that can be downloaded from the client in bytes (B), Kbytes (K), Mbytes (M), Gbytes (G). By default download size is 10M. When specified, the default unit is B.
- o
- --repeat <seconds>: keep running as a daemon, wake up at interrupts or after <seconds> seconds. The interval will be at least 60 seconds. To this interval a random delay may be added (see --random-interval).
- o
- --reload pidfile: reloads the configuration and skip-files and restarts the scan of a currently active stealth process.
- o
- --rerun pidfile: restart the scan of a currently active stealth process;
- o
- --resume pidfile: resume a suppressed stealth process, implying --rerun;
- o
- --suppress pidfile: suppress a currently active stealth process. All scheduled scans following --suppress are skipped, --rerun is ignored, but --resume and --terminate (see below) may be issued;
- o
- --terminate pidfile: terminate a currently active stealth process;
- o
- --usage: Display help information and exit;
- o
- --help: Display help information and exit;
- o
- pidfile: file containing the process id of a stealth process;
- o
- policy: path to the policyfile;
DEPLOYMENT SUMMARY¶
The following summarizes the advised steps to perform when installing stealth. All these steps are elaborated upon in stealth’s User Guide (chapter Running `stealth’):- o
- Install stealth (e.g., use dpkg(1) to install the .deb file);
- o
- Construct one or more policy files;
- o
- Automate running stealth using cron(1) (possibly calling stealthcron);
- o
- Set up automated log-file rotation, using, e.g.,
stealthcleanup and logrotate(1), defining one or more
/etc/logrotate.d/stealth... configuration files.
FILES¶
/usr/share/doc/stealth/;SEE ALSO¶
cron(1), dd(1), diff(1), dpkg(1), find(1), logrotate(1), ls(1), mail(1), sha1sum(1), passwd(5), sendmail(1), sh(1), ssh(1)DIAGNOSTICS¶
By default, the executed commands are echoed to stderr. Use -q to suppress this echoing.BUGS¶
None reportedCOPYRIGHT¶
This is free software, distributed under the terms of the `GNU General Public License’. Copyright remains with the author. Stealth is found at http://stealth.sourceforge.net/.ORGANIZATION¶
Center for Information Technology, University of Groningen.AUTHOR¶
Frank B. Brokken ( f.b.brokken@rug.nl).
2005-2012 | stealth_2.10.00.tar.gz |