TIGER(8)

📦 version 3.2.4~rc1, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

TIGER(8) — UNIX Security Checker 💖

Administrator Commands ✨ the manual, bestie

🌸 NAME 🌸

tiger — UNIX Security Checker 🐯💅

✨ SYNOPSIS ✨

tiger [-vthqGSH] [-B dir] [-l dir|@host] [-w dir] [-b dir] [-e|-E] [-c
config] [-A arch] [-O os] [-R release]

🦋 DESCRIPTION 🦋

okay so, tiger? it's a whole package, not just one lil script — we're talking Bourne Shell scripts, C code and data files, all working together to check your UNIX system for security problems. she scans your system config files, your file systems, and your user config files, looking for anything sus, and then reports it. 📋✨

and when you get a report full of cryptic nonsense, the command tigexp(8) is right there to give you explanations of the problems tiger reported. no cap, that's the whole point.

you can configure tiger by adjusting the Tiger_ variables in the /etc/tiger/tigerrc configuration file. for each available module (peep MODULES below 👀) there's a corresponding variable in the config file that decides whether that module even runs. all those variable names start with Tiger_check_ and you set them to Y to run it, or N to skip it. simple. other config variables tweak how some modules behave, and you should adjust those based on your operating system. 💫

the /etc/tiger/tiger.ignore config file defines a set of messages that will not show up in the report, even if some module generates them. if that file exists, all the entries (line by line) get used as extended regular expressions compared against each message — heads up tho, this adds some overhead, and it grows with the size of the file 😭. for more info on how this works, read the README.ignore document. 🎀

💅 OPTIONS 💅

here's what you can pass when you call the program:

  • -B tigerdir — specify the directory where tiger is installed. if you don't, /usr/lib/tiger gets used.
  • -l logdir|@logserver — specify the name of the directory where tiger writes the security report. defaults to /var/log/tiger. the report filename will look like 'security.report.hostname.date.time'. if the directory starts with an @, the name gets interpreted as a tiger logging server. the tiger logging server is currently a server that listens on port (tcp) 5353 on a remote host. the tiger process just sends the results over to that server using a telnet connection. 📡
  • -w workdir — specify a directory to use for creating scratch files. defaults to /var/lib/tiger/work.
  • -b bindir — specify the directory which contains (or will contain) the binaries generated from the C modules. if the system's directories already have all the binaries, they get used directly from there. if not, then if bindir has the binaries, those get used. if neither place has them, then it'll attempt to compile the C code and install the executables into bindir. 🔨
  • -c tigerrc — specify an alternate name for the tigerrc control file. default is '/etc/tiger/tigerrc'.
  • -e — this one makes explanations get inserted into the security report right after each message. warning: this can greatly increase the size of the report, because explanations may appear repeatedly. 💀
  • -E — this one says a separate explanation report should be created, with explanations for each type of message only appearing once. the filename of the explanation report will look like 'explain.report.hostname.date.time'.
  • -G — generate the signatures (MD5 hashes and file permissions) for system binary files. 🔐
  • -H — this one formats the report into HTML, creating local links to the problem descriptions. 🌈
  • -S — this one says 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 won't be as in depth as they'd be if run on the client itself. ngl, it's giving "quick vibe check, not a full audit" 🫶
  • -q — suppress messages to be as quiet as possible; only security messages will be shown. 🤫
  • -A arch — overrides the default value obtained for the current architecture, which was detected by the internal configuration engine, to a value you define.
  • -O os — overrides the default value obtained for the current operating system, detected by the internal configuration engine, to a value you define.
  • -R release — overrides the default value obtained for the current operating system release, detected by the internal configuration engine, to a value you define.
⚠️ okay bestie, real talk: notice that changing the real values for the operating system and architecture tiger is running in might result in scripts being run that are not appropriate for it, and as a consequence, unexpected (and potentially dangerous) errors might be generated. 😭

when executed, tiger will show which operating system, release and architecture it thinks it's running in. 👑

🧩 MODULES 🧩

Okay so here's the tea: Tiger isn't one big blob, bestie. It's a whole squad of modules, and each one is out here checking a specific security issue on your UNIX system. The framework lets you have both generic modules and ones that are specific to whatever OS you're running on. And the flex? Modules can run standalone, from cron, or through the tiger program itself (which just runs every single one that's available). Main character behavior, honestly.

If you wanna write your own modules for your system, go read the README.writemodules document. The door is open, we love that for you 🫶

Tiger currently provides the following modules:

  • check_accounts — Checks the accounts provided in the system, looking for disabled accounts with cron, rhosts, .forward, and valid shells.
  • check_aliases — Performs a check for mail aliases and improper configuration.
  • check_anonftp — Determines if the anonymous FTP service is properly configured.
  • check_cron — Validates the cron entries in the system.
  • check_embedded — Determines if embedded pathnames are configured properly.
  • check_exports — Analyses configuration files for NFS exported filesystems to see if access is properly restricted.
  • check_group — Checks the UNIX groups available in the system, looking for conflicts and improper entries.
  • check_inetd — Checks the inetd configuration file: compares against services definition, valid directory paths, non-existent binaries and active services.
  • check_known — Looks for known intrusion signs including backdoors and mail spools.
  • check_netrc — Checks if users's netrc files are insecurely configured.
  • check_nisplus — Looks for wrong configuration in the NIS+ entries.
  • check_passwd — Checks the UNIX users available in the system, looking for conflicts and improper entries.
  • check_path — Validates the binaries in user's PATHs as well as PATH definitions used by scripts in order to determine insecure definitions.
  • check_perms — Check filepermissions and inconsistencies.
  • check_printcap — Analyses the configuration for the printer control file.
  • check_rhosts — Checks rhosts files in order to see if user's configuration leaves the system open to attack.
  • check_sendmail — Checks sendmail configuration files. (and yeah, the manpage literally runs this straight into the next one, no paragraph break, no nothing — iconically chaotic 💀)
  • check_signatures — Compares binary files signatures against those stored in the local database (provided with the program).
  • check_system — This module calls the operating system's specific modules available at /usr/lib/tiger/systems/.
  • check_apache — Checks the Apache configuration file and reports on generic issues which might introduce exposures or vulnerabilities in the system.
  • check_devices — Checks for devices's permissions, warning about devices that have world permissions.
  • check_exrc — 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.
  • check_finddeleted — 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 vulnerable).
  • check_ftpusers — Analyses the system's /etc/ftpusers and determines if the administrative users are in that file.
  • check_issue — 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).
  • check_logfiles — Checks for the existence of log files (wtmp, btmp, lastlog and utmp). It will also check for proper umask settings.
  • check_bootloader — Analyses configuration files for different bootloaders including lilo and grub (Linux-specific).
  • check_listeningprocs — 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.
  • check_passwdformat — Checks the format of the /etc/passwd file in order to determine inconsistencies which indicate an intrusion or misconfiguration.
  • check_patches — 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).
  • check_root — Checks if remote root login is allowed to the local system.
  • check_rootdir — Checks the permissions for the root directory.
  • check_rootkit — 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.
  • check_single — Checks if the system is properly configured to disallow single-user access. This check is specific to Linux.
  • check_release — 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).
  • check_runprocs — 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_services — Check which services are configured in the system (usually in /etc/services) versus the ones that should be configured (in the provided services file)
  • check_tcpd — Tests for the existence of tcp-wrappers and changes in their configuration it also determines which services are running wrapped in tcp-wrappers.
  • check_umask — Check for umask setting in configuration files.
  • check_xinetd — Checks which xinetd services are enabled or disabled.
  • crack_run — 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.
  • deb_checkmd5sums — 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).
  • deb_nopackfiles — Looks for files installed in the system's directories that are not provided by any installed Debian packages (Debian-specific).

📂 FILES 📂

These are the spots on your filesystem that matter, bestie — memorize the map 🗺️✨

  • /etc/tiger/tigerrc — Configuration file for the Tiger tool.
  • /etc/tiger/cronrc — Configuration file for the Tigercron tool.
  • /var/log/tiger — Location of the log messages generated by Tiger when run through cron.
  • /var/lib/tiger/work — Working directory used by Tiger scripts to create temporary files.
  • /etc/tiger/tiger.ignore — Configuration file that defines which messages generated by modules will be ignored by Tiger and will not be presented in the final report.

👀 SEE ALSO 👀

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/)

🐛 BUGS 🐛

Not me telling you the flaws, but like, honestly, transparency is the vibe:

👑 AUTHOR 👑

The origin story, because everyone deserves lore:

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 http://savannah.nongnu.org/projects/tiger.

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).

and that's the whole page, bestie!! 💖✨

This came out of the Security corner of the manual, and the version on deck is dated 12 August 2003 — it's TIGER(8), periodt. Now go run your security checks and slay responsibly 👑🦋💅

📦 where this page comes from