tiger - UNIX Security Checker
tiger [-vthqGSH] [-B dir] [-l dir|@host] [-w dir] [-b dir] [-e|-E] [-c
config] [-A arch] [-O os] [-R release]
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 tigexp(8) can be used to obtain explanations of the
problems reported by tiger.
You can configure tiger by adjusting the Tiger_ variables in the
/etc/tiger/tigerrc configuration file. For each available module (see
MODULES below) there is a corresponding variable in the configuration
file that determines whether the module is run. All of the variables
names start with Tiger_check_ 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.
The /etc/tiger/tiger.ignore 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 README.ignore document.
The following arguments can be used when calling the program:
Specify the directory where tiger is installed. If not
specified, /usr/lib/tiger is used.
Specify the name of the directory where tiger 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
Specify a directory to use for creating scratch files. This
defaults to /var/lib/tiger/work.
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, then if bindir 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.
Specify an alternate name for the tigerrc control file. The
default is ’/etc/tiger/tigerrc’.
-e 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
-E 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 form ’explain.report.hostname.date.time’.
-G Generate the signatures (MD5 hashes and file permissions) for
system binary files.
-H This option will format the report into HTML creating local
links to the problem descriptions.
-S 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.
-q Suppress messages to be as quiet as possible, only security
messages will be shown.
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.
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
architecture Tiger is running in might result in scripts being run
which are not appropiate to it, and, as a consequence, unexpected (and
potentially dangerous) errors might be generated. When executed Tiger
will show which operating system, release and architecture thinks it is
Tiger is composed of a series of modules. Each of these modules check
specific security issues related to UNIX systems. The framework
provided by Tiger 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 tiger program
(which will execute all those available).
If you want to write additional modules for your system read the
Tiger 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
Looks for known intrusion signs including backdoors and mail
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
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. check_signatures 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 /usr/lib/tiger/systems/.
Checks the Apache configuration file and reports on generic
issues which might introduce exposures or vulnerabilities in the
Checks for devices’s permissions, warning about devices that
have world permissions.
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
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
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 ISSUENETFILE).
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
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
This module will check if the processes configured in tigerrc
are running currently in the system. If any of the processes is
not running, Tiger 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
Compares the MD5 sums of binary files against those provided
after installation. Changes in these files might be an
indication of a compromised system (Debian-specific).
Looks for files installed in the system’s directories that are
not provided by any installed Debian packages (Debian-specific).
Configuration file for the Tiger tool.
Configuration file for the Tigercron tool.
Location of the log messages generated by Tiger when run through
Working directory used by Tiger scripts to create temporary
Configuration file that defines which messages generated by
modules will be ignored by Tiger and will not be presented in
the final report.
There are also a number of README files that describe in detail the
behaviour of Tiger 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 in /usr/lib/tiger 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
/usr/share/doc/tiger/README.Debian document or the
Tiger 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).
A lot 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 Tiger 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 operating systems
(check_listeningprocs) and some specific for Debian
(deb_checkadvisories, deb_checkmd5sums and deb_nopackfiles).