, , , , , , ,

Last November I introduced a collection of tools that could thoroughly audit a UNIX system for signs of rootkit infection. I’ve recently found something else that performs a wider and more comprehensive range of tests. It’s called ‘Tiger‘, and some interesting things can be done with it.
Tiger is pretty old, dating from around 1995, but it’s still relatively maintained with the last update being released in 2010. Since it’s not an anti-malware system as such, and checks generic system configurations and components, it’s still quite reliable.

So, firing up Tiger, it automatically runs through a series of checks by default:


One of the problems with Tiger (apart from the false positives) is the test can hang for around 30 minutes on certain tests, as it did here when running $grep against /etc/inittab:


Fortunately there is a way of running a specific test on its own, or a predefined range of tests (we’ll come to that). When audit’s completed, the results are stored in a log file at /var/log/tiger/security.report.[hostname].[date]. Users must have root privileges to read the file.


The report is pretty comprehensive, pointing at specific configuration issues that might need addressing, and hinting at what the correct configurations should be.
Another major disadvantage with Tiger is the huge number of false positives generated, especially on a machine with the larger security tools installed and running as servers. OpenVAS and Nessus databases would result in roughly a thousand warning entries being dumped to the log file.

Reporting Options
There are a couple other things we could do with the security reports. They can be piped to another location, such as a security analyst’s home directory, or a dedicated log server elsewhere on the network:
#tiger -l [location]

There’s also the option of dumping the report in HTML format:
#tiger -H

If the user doesn’t fully know what the entries mean, descriptions will be added to them with the ‘-e‘ option, although that would increase the report file’s size. A separate file might be created for explanations using the ‘-E‘ option.

Another very useful feature is the ability to scan the binaries on the system and generate MD5 signatures for them. This could be done periodically, with a script comparing the output files to detect modifications:
#tiger -G

On reading the man page for Tiger, we learn that it’s actually a ‘framework’ consisting of modules (compiled C programs) that each perform a specific check on the system. This opens up new possibilities.
The modules are stored in /usr/lib/tiger/scripts. They’re not shell binaries but there is a way to execute them, or even create a BASH script that launches only the modules we want and uses $cat to pipe the output to a text file:


Even better, why not create a Tiger remix by copying whatever modules to another location and putting them together with a BASH script?