Section: Administrator Commands (8)
Updated: 12 August 2003Index
Return to Main Contents
tiger - UNIX Security Checker
Tiger is a package consisting of Bourne Shell scripts, C code and
data files which is used for checking for security problems on a
UNIX system. It scans system configuration files, file systems,
and user configuration files for possible security problems and
reports them. The command
can be used to obtain explanations of the problems reported by tiger.
You can configure
by adjusting the
variables in the
configuration file. For each available module (see
below) there is a corresponding variable in the configuration file that
determines whether the module is run. All of the variables names start with
and should be set equal to Y to run, or N to skip. Other configuration
variables will modify the behaviour of some modules, and should be
adjusted based on the operating system.
configuration file defines a set of messages that will not be presented
in the report even if any of the modules generate them.
If the file exists, all the entries (line by line) are used as extended
regular expressions that are compared against each message (notice that
it will introduce some overhead which grows with the size of the file).
For more information on this mechanism read the
- The following arguments can be used when calling the program:
- -B tigerdir
Specify the directory where
is installed. If not specified, /usr/lib/tiger is used.
- -l logdir|@logserver
Specify the name of the directory where
will write the security report. This defaults to /var/log/tiger.
The filename of the report will
be of the form 'security.report.hostname.date.time'.
If the directory begins with a @, the name will
be interpreted as a tiger logging server. Tiger logging's server
is currently a server that listens in port (tcp) 5353 on a remote
host. The tiger process will just send the results to that server
using a telnet connection.
- -w workdir
Specify a directory to use for creating scratch files. This defaults
- -b bindir
Specify the directory which contains (or will contain) the binaries
generated from the C modules. If the systems directories contain
all the binaries, they will be used directly from there. If not,
contains the binaries, these will be used. If none are found in
either place, then an attempt will be made to compile the C code
and install the executables into bindir.
- -c tigerrc
Specify an alternate name for the
control file. The default is '/etc/tiger/tigerrc'.
This option will cause explanations to be inserted into the security
report following each message. This can greatly increase the size
of the report, as explanations may appear repeatedly.
This option indicates that a separate explanation report should be
created, with explanations for each type of message only appearing
once. The filename of the explanation report will be of the
Generate the signatures (MD5 hashes and file permissions)
for system binary files.
This option will format the report into HTML creating local links
to the problem descriptions.
This option indicates that a surface level check of the configuration
files of any diskless clients served by this machine should be checked
at the same time. The checks will not be as in depth as they would be
if run on the client itself.
Suppress messages to be as quiet as possible, only
security messages will be shown.
- -A arch
This option overrides the default value obtained for the current architecture
detected by the internal configuration engine to a value defined
by the user.
- -O os
This option overrides the default value obtained for the current operating
system detected by the internal configuration engine to a value defined
by the user.
- -R release
This option overrides the default value obtained for the current
operating system release detected by the internal configuration engine
to a value defined by the user.
Notice that changing the real values for the operating system and
is running in might result in scripts being run which are not
appropriate to it, and, as a consequence, unexpected (and potentially
dangerous) errors might be generated. When executed
will show which operating system, release and architecture thinks it is
is composed of a series of modules. Each of these modules check specific
security issues related to UNIX systems. The framework provided by
allows the provision of both generic modules and those specific for
the operating system the software runs in. Modules can be executed
stand alone, from cron or through the
program (which will execute all those available).
If you want to write additional modules for your system read the
currently provides the following modules:
Checks the accounts provided in the system, looking for disabled accounts
with cron, rhosts, .forward, and valid shells.
Performs a check for mail aliases and improper configuration.
Determines if the anonymous FTP service is properly configured.
Validates the cron entries in the system.
Determines if embedded pathnames are configured properly.
Analyses configuration files for NFS exported filesystems to see if
access is properly restricted.
Checks the UNIX groups available in the system, looking for conflicts
and improper entries.
Checks the inetd configuration file: compares against services
definition, valid directory paths, non-existent binaries and active
Looks for known intrusion signs including backdoors and mail spools.
Checks if users's netrc files are insecurely configured.
Looks for wrong configuration in the NIS+ entries.
Checks the UNIX users available in the system, looking for conflicts
and improper entries.
Validates the binaries in user's PATHs as well as PATH definitions
used by scripts in order to determine insecure definitions.
Check filepermissions and inconsistencies.
Analyses the configuration for the printer control file.
Checks rhosts files in order to see if user's configuration leaves the
system open to attack.
Checks sendmail configuration files.
Compares binary files signatures against those stored in the local database
(provided with the program).
This module calls the operating system's specific modules available at
configuration file and reports on generic issues which might introduce
exposures or vulnerabilities in the system.
Checks for devices's permissions, warning about devices that have world
Analyses .exrc files that are not in user's home directories. The vi
command will look for the existence of such a file in the current
directory, and so may inadvertently perform commands that can
compromise your system's security when starting vi or ex.
Checks if deleted files are being used by any process in the current
system. This might be an indication of intrusion (a user executing
processes and then deleting its files) or of unpatched servers
(which, if not restarted use old library files and are still
Analyses the system's /etc/ftpusers and determines if the administrative
users are in that file.
Checks the /etc/issue and /etc/issue.net file to determine if they
contain the appropriate content (this is defined in the ISSUEFILE and
Checks for the existence of log files (wtmp, btmp, lastlog and utmp). It
will also check for proper umask settings.
Analyses configuration files for lilo and grub boot loaders (Linux-specific).
Checks for processes listening on TCP/IP sockets (servers) in the system as
well as users running them. Will warn if the user running a server is not
an authorised one or if the server is listening on all available interfaces.
Checks the format of the /etc/passwd file in order to
determine inconsistencies which indicate an intrusion or misconfiguration.
Checks if patches are available for the system (i.e. new packages).
It will use autorpm or apt-get to check this (so this tools need to be
properly configured). This check is specific to Linux (RedHat or Debian).
Checks if remote root login is allowed to the local system.
Checks the permissions for the root directory.
Tries to find systems which have been rootkited, it does so by
looking for trojaned ls and find commands.
It also includes a wrapper to run the chkrootkit program
and format the results in Tiger's message format.
Checks if the system is properly configured to disallow single-user
access. This check is specific to Linux.
Analyses the version of the operating system and determines if it is
too out of date. This check is specific to Linux (RedHat or Debian).
This module will check if the processes configured in
are running currently in the system. If any of the processes
is not running,
will warn the administrator (this acts as a lightweight software watchdog)
Check which services are configured in the system (usually in
/etc/services) versus the ones that should be configured (in the
provided services file)
Tests for the existence of tcp-wrappers and changes in their configuration
it also determines which services are running wrapped in tcp-wrappers.
Check for umask setting in configuration files.
Checks which xinetd services are enabled or disabled.
Runs a local installation of the Crack program which can be used
to determine if local user passwords are easy (or not) to guess.
- tripwire_run aide_run integrit_run
Wrappers for a number of integrity checkers, these programs enhance the
support of Tiger for MD5 and SHA-1 binary signatures and file
system permission checks (implemented with the the check_perms
and check_signatures scripts). You should consider installing
any of these three programs (Tripwire, Aide or Integrit)
and use read-only locations (such as CD-ROM) to store the hashes of the system.
This module checks against a list of stored Debian Security
Advisories in order to see if the system has any package installed
whose version might be subject to any security vulnerability (Debian-specific).
Compares the MD5 sums of binary files against those provided after installation.
Changes in these files might be an indication of a compromised system
Looks for files installed in the system's directories that are not provided
by any installed Debian packages (Debian-specific).
Configuration file for the
Configuration file for the
Location of the log messages generated by
when run through cron.
Working directory used by
scripts to create temporary files.
Configuration file that defines which messages generated by modules will be
and will not be presented in the final report.
There are also a number of
files that describe in detail the behaviour of
and how it can be used to setup a host-based intrusion detection
system. These can be found in the top directory of the sources or
once it is installed (in Debian the location of the full documentation
set is /usr/share/doc/tiger/)
There are a lot more things to check.
Some places in the package are not shell meta-character or white-space
You can report or read known bugs at the
For Debian-specific (known) bugs read the
document or the
was originally developed by a team of the
Texas A&M University Supercomputer Center, as of September 1993,
the development done via the Network Group, Computing & Information Services.
This software was written originally by Douglas Lee Schales, Dave K. Hess, Khalid Warraich,
and Dave R. Safford (circa 1993).
of changes were introduced by the ARSC team (a.k.a. the TARA team)
Liam Forbes <lforbes at arsc.edu>, Nathan Bills <bills AT arsc.edu> and
Mike Kienenberger <mkienenb at arsc.edu>, including support for quite a number
of operating systems.
Current upstream maintenance of
is being done by Javier Fernandez-Sanguino Peña and coordinated at
The adaptation for the GNU/Linux operating system was made by
Robert L. Ziegler <rlz at mediaone.net>
The modifications for the Debian GNU/Linux operating system have been made
by Javier Fernandez-Sanguino Peña <jfs at computer.org>, including a number of
checks for the GNU/Linux
and some specific for Debian
- SEE ALSO