One Hat Cyber Team

Edit File: README

THE ROOTKIT HUNTER PROJECT
==========================

It is recommended that all users of RootKit Hunter (RKH) join the
rkhunter-users mailing list. Subscribing to the list can be done via
the RKH website at http://rkhunter.sourceforge.net

A copy of the RKH FAQ is also available from the web site.

ROOTKIT HUNTER REQUIREMENTS
===========================

Please note that RKH has some requirements:

1) Before RKH starts it will check that certain required commands
   are present on the system. These are typical commands such as
   'cat', 'sed', 'head', 'tail', etc. If a command is missing then
   RKH will not run.

2) Some tests require commands such as stat, readlink, sha256 or
   sha256sum. If these are not present, then RKH has perl scripts
   which will automatically be used instead. However, this requires
   perl, and certain modules, being present. If they are not, then
   the tests will be skipped. Readlink is provided as a script
   itself, and does not use perl. Other tests will use other
   commands. If the relevant command is not found on the system,
   then the test will be skipped.

3) A tool should be present with which to download file updates. 
   Currently wget, curl, (e)links, lynx and GET are supported. If your
   system does not allow the possibility to install one of these 
   applications, but does run perl, you can use 'bget' available from 
   http://www.cpan.org/authors/id/E/EL/ELIJAH/. If you use another 
   generic method of updating RKH then please let us know. Additionally,
   a non-standard command to be used for file downloads can be
   configured in the RKH configuration file.

4) Some tests require single-purpose tools. RKH does not depend on
   these, but it will use them if it finds them. They can enhance
   RKH's detection capabilities.
   The tools are:
   - Skdet
       Tests for SucKIT, Adore, Adore-NG, UNFshit, UNFkmem and
       frontkey.
       http://www.xs4all.nl/~dvgevers/
   - Unhide and unhide-tcp (C versions)
       Finds hidden ports and processes.
       http://unhide.sourceforge.net
   If the relevant tool is not found, then the test is skipped.

ROOTKIT HUNTER INSTALLATION
===========================

Unpacking the tar file should produce a single directory called
'rkhunter-<version>'. Where '<version>' is the version number of rkhunter
being installed. For example, the rkhunter-1.4.0.tar.gz tar file will produce
the 'rkhunter-1.4.0' directory when unpacked. Within this directory is the
installation script called 'installer.sh'.

To perform a default installation of RKH simply unpack the tarball and,
as root, run the installation script:

tar zxf rkhunter-<version>.tar.gz
    cd rkhunter-<version>
    ./installer.sh --install

Note: If some form of file permission error is shown, then check that the
      'installer.sh' script is executable.

RKH installation supports custom layouts. To show some examples
run:

./installer.sh --examples

The installer also has a help option:

./installer.sh --help

The default installation process will install a configuration file,
called 'rkhunter.conf', into the '/etc' directory or where
you chose using the '--layout' switch. You can either edit the main
configuration file itself, or create a 'local' configuration file
for your own settings. This file, which must be called
'rkhunter.conf.local', must reside in the same directory as the main
configuration file. Alternatively, or in addition if wished, you can
create a directory, named 'rkhunter.d', in the same directory as the
main configuration file. Within 'rkhunter.d' you can then create
further configuration files. The only restriction is that the file
names end in '.conf'.

You should edit the configuration file(s) according to your own
system requirements.

Note: If the installer detects an existing 'rkhunter.conf.local' file,
or an 'rkhunter.d' directory, then these will be added to the main
configuration file for monitoring by rkhunter. The installer will also
add the 'rkhunter.conf' file itself to be monitored. By doing this, any
changes to the rkhunter configuration file(s) will be detected.

If the installer encounters an existing 'rkhunter.conf' file, it will
not be overwritten. Instead the installer creates a new configuration
file, but with a unique number as its suffix. Please inspect the new
configuration file, and copy over any changes to the existing main
configuration file or to your local configuration file(s).

The main RKH script will be installed into the '/usr/local/bin'
directory or where you chose using the '--layout' switch. Man pages will 
be installed into '/usr/local/share/man', and other documentation will 
be installed into the '/usr/local/share/doc' directory. RKH data files,
language support, and a directory for temporary files will be
installed into '/var/lib/rkhunter'. Finally, RKH support scripts will
be installed into '/usr/local/lib/rkhunter/scripts', or, if using an
x86_64 system, into '/usr/local/lib64/rkhunter/scripts'. All directories,
except 'lib64', will be created where necessary.

Before running RKH you will need to fill the file properties database by
running the following command:

rkhunter --propupd

Note that if you want to use the package management tools provided by 
your distribution you will need to select a package manager. In the case
of using RPM your command would be:

rkhunter --propupd --pkgmgr RPM

To run RKH, as root, simply enter the following command:

rkhunter --check

By default, the log file '/var/log/rkhunter.log' will be created. It
will contain the results of the checks made by RKH.

To see what other options can be used with rkhunter, enter:

rkhunter --help

or see the 'rkhunter' man page.

NOTE: The first run of 'rkhunter' after installation may give some
      warning messages. Please see the FAQ file and the rkhunter mailing
      list archive posts for more details about this.

STANDALONE INSTALLATION
=======================

It is possible to run RKH standalone, that is, with it all being
installed into one directory.

To do this unpack RKH as described above, and then install it using
the following command:

./installer.sh --layout custom . --install

It is then necessary to change to the 'files' directory:

cd files

Within the directory will be a copy of the 'rkhunter.conf' configuration
file. You can modify this file according to your requirements if you
wish.

To run RKH, as root simply enter the following command:

./rkhunter --propupd --check --sk

TESTING RKHUNTER WITHOUT INSTALLING IT
======================================

It is perfectly understandable that new users may wish to try out rkhunter
without having to fully install it. Similarly current users may want to
test a new version of rkhunter, or a development version of it, without it
affecting their current system or current installation of rkhunter. This is
all perfectly possible, and quite easy, using a standalone installation.

First, as the root user, it is suggested that a separate temporary directory
is created, and then change to that directory. For example:

mkdir /tmp/rkh
       cd /tmp/rkh

It is now necessary to either copy or download a tarball of the version of
rkhunter that you want to test. (Since you are reading this file, we assume
you have already downloaded the relevant version.) For users wishing to try
the latest development version, it is possible to download a tarball:

wget http://rkhunter.sourceforge.net/rkhunter-dev.tar.gz

Next, it is necessary to extract the files from the tarball. The simplest
way is to use the 'tar' command, such as:

tar xzf rkhunter-dev.tar.gz

Obviously, for official releases, you will need to use the correct tarball
name. For example:

tar xzf rkhunter-1.4.0.tar.gz

For users of systems with alternative implementations of 'tar', for example
Solaris users, you may need to break the extraction process into two steps
(or use the 'gtar' command if you have it installed). For example:

gunzip rkhunter-dev.tar.gz
       tar xf rkhunter-dev.tar

The extraction process will create a sub-directory containing all the
rkhunter files. The sub-directory name will contain the rkhunter version
number, or, for development tarballs, it will simply be called 'rkhunter'.
Change into this directory:

cd rkhunter-1.4.0         (for an official release tarball)
   or  cd rkhunter               (for development tarballs)

Now, we can run the installer program as described in the section above
about standalone installations:

./installer.sh --layout custom . --install

Finally change to the 'files' sub-directory:

cd files

Within here will be all the files that rkhunter requires. The configuration
file, './rkhunter.conf', will already have been configured for a standalone
installation. So there is no need to modify it unless you want to. Any
files created by rkhunter will be within this directory. So, as mentioned
above, it is perfectly possible to run a check using this installation
without affecting any other installation of rkhunter that may exist on your
system. To run a check use this command:

./rkhunter --propupd --check --sk

By default a log file (rkhunter.log) will be created, and that too will be
within this directory.

NOTE: If the rkhunter '--debug' option is used then this will, by default,
create a file in the '/tmp' directory, and not within the current directory.

Once you have finished testing rkhunter, simply delete the entire directory
it was installed into:

cd /tmp
       /bin/rm -rf rkh

INSTALLATION INFORMATION FOR x86_64 SYSTEMS
===========================================

The installation of RKH is largely independent of the system architecture.
However, RKH does have some support scripts and these need to be installed
into the appropriate library directory. When performing a default
installation, or using one of the known layout options (for example, '/usr'
or '/usr/local'), then the relevant 'lib64' directory will be used only if
it already exists. For a 'custom' layout, the 'lib64' directory will be used
and created if necessary. Standalone installations do not use any special
library directory at all. RPM installations will use the relevant 'lib64'
directory only if the system architecture is detected as being 'x86_64'.

REMOVING AN INSTALLATION
========================

RKH supports uninstallation. To do this unpack the installation
tarball, and then run the installer with the --remove option. If RKH
was installed using a default installation, then run:

tar zxf rkhunter-<version>.tar.gz
    cd rkhunter-<version>
    ./installer.sh --remove

If you chose a different layout, for example '/usr', then run the
installer using:

./installer.sh --layout /usr --remove

Note: the installer will not remove files that were installed using RPM
(use the 'rpm' command to remove the package).

For a standalone uninstallation, specified by using '--layout custom .',
the installer will remove the whole installation directory (the 'files'
sub-directory).

During uninstallation, the installer will remove the initial configuration
file (usually '/etc/rkhunter.conf'). However, any other files beginning with
'rkhunter.conf' are not removed. Similarly, any 'rkhunter.d' directory is
not removed. These may be removed manually if wished.

When installing RKH, some directories may have been created. However,
RKH is unaware of this when being uninstalled. As such, and especially
when having used a custom installation, some directories may be
emptied of files, but the directories themselves may remain. Again,
these can be removed manually if wished.

In order to see where RKH installed its files during installation, the
'--show' option can be used. For example:

./installer.sh --layout custom /opt --show

USING TEST NAMES
================

Within RKH some of the tests have been given names. There are two types of
test names - specific test names and grouped test names. A specific test name
generally refers to one specific test within RKH. A grouped test name refers
to a set, or group, of related tests. Within a group name there are usually
one or more specific test names.

To see the current list of test names use the 'rkhunter --list tests' command.
The grouped names list will show the specific names that are within the group.

So, for example, the file properties check has the grouped name of 'properties'.
However, within that test the file hash value test is known as 'hashes'.
Similarly, the file attributes check, which checks the file permissions, uid
and gid values, and so on, is known as the 'attributes' test. Note that while
it is possible to tell RKH to run the file properties check, but ignore the
file hash value test, it is not possible to tell RKH to run the file attributes
but to ignore the file permissions checks. RKH has no specific name for the
file permissions test, and so it cannot be specifically enabled or disabled.

RKH can be told to enable or disable one or more of the tests by using the
'--enable' and '--disable' command-line options. Alternatively, the RKH
configuration file options 'ENABLE_TESTS' and 'DISABLE_TESTS' can be used.
By default, if the command-line '--disable' option is used, then the
configuration file option 'DISABLE_TESTS' is also used to determine which tests
to run. If only the command-line option is to be used to determine which tests
to run, then the '--nocf' option must also be given. The program defaults, if
no options are used at all, are to enable all tests and to disable no tests.
For this purpose the enable options can use the special test name 'all', and
the disable options can use the name 'none'. The enable options cannot use the
name 'none', and the disable options cannot use the name 'all'. To specify
more than one test name, specify them as a comma-separated list. For example:

rkhunter --enable 'rootkits,hashes'

Note that in the above example no disabled test list was specified. As such, it
will default to the value of the configuration file option (DISABLE_TESTS), or
ultimately to the program default value of 'none'. The command-line options
'--enable' and '--disable' may be used more than once on the command-line.

The supplied RKH configuration file will have some tests already disabled.
These are generally CPU and/or I/O intensive tests, or ones which may be prone
to giving false-positive results. They can, of course, be enabled by editing
the DISABLE_TESTS list. To run the tests from the command line, either use
the '--enable' command-line option with the specified test name, or use
either '--enable all' or '--disable none'.

If either of the '--enable' or '--disable' command-line options is used, and
the '--propupd' option is not given, then '--check' is assumed.

If the '--enable' option is used and only one test name, other than 'all',
is given, then the '--skip-keypress' option is assumed as well. So, for
example, to run all the rootkit tests just use:

rkhunter --enable rootkits

Similarly, to run all the tests except the rootkit tests, then use:

rkhunter --disable rootkits

In this example RKH will assume the value of the configuration file option
(ENABLE_TESTS) for the enabled test list, or ultimately the program default
of 'all'. In the previous example, the value of DISABLED_TESTS or, ultimately,
'none' will have been used for the disabled tests list.

If a combination of enabled and disabled tests are specified, then RKH will
disable a test if it is specified in the enable list. So, for example:

rkhunter --enable 'rootkits,deleted_files' --disable malware

In this example the 'malware' test is disabled because it is part of the
'rootkits' test. The fact that the 'deleted_files' test is specified to be
run is ignored, because that is part of the 'malware' test. RKH will always
look to see what tests to disable first. It will then run any enabled tests
that are left.

By default RKH will log what test names have been enabled and disabled.
Additionally it will log each test name that it is about to execute. When
initially run RKH may skip some tests due to missing commands or files. It is
usually possible to omit these tests by including them in the DISABLE_TESTS
list in the configuration file. The test name associated with these tests can
be found by looking in the log file.

It should be noted that not all the tests have been given names. As such some
test names may execute more tests than expected. For example:

rkhunter --enable group_changes

The 'group_changes' test name refers to the check to see if the /etc/group file
has been modified. However, running the above command will also cause several
tests on the /etc/passwd file to be executed. This is because those tests are
part of the 'local_host' grouped test name, as is the 'group_changes' test,
but those other tests have no specific names. As such, RKH will start the
'local_host' tests, executing some of the /etc/passwd file tests and then the
'group_changes' test, but ignoring any other tests within 'local_host' which
do have specific names (for example, 'filesystem' and 'passwd_changes').

USING PACKAGE MANAGERS
======================

The RKH file properties check, by default, performs a check of various current
file properties against those that it has previously stored in the
'rkhunter.dat' file. This way RKH can warn the user if a file has changed. The
file properties include items such as the files hash value, file permissions,
uid, gid, inode number and so on. The properties are obtained and stored in the
rkhunter.dat file when RKH is run with the '--propupd' option.

Typically the file properties are obtained using commands such as 'stat',
'file', 'md5sum' and 'prelink'. However, it is also possible to specify that
RKH should get whatever values it can by using a package manager. This can be
done by using the '--pkgmgr' command-line option, or the 'PKGMGR' configuration
file option. When the RPM package manager is specified, during the file
properties check the results from the RPM verification command are used as the
test results. For the other package managers, the values from the package
manager database are compared against the current values for the files. By
using a package manager, it is possible to avoid some false-positive reports
that a file has changed when in fact it has been automatically updated by the
system.

The currently available package managers are 'RPM' for RedHat/RPM-based
systems, 'DPKG' for Debian-based systems, 'BSD' (using the 'pkg_info' command)
and 'BSDng' (using the 'pkg' command) for *BSD systems, and 'SOLARIS' for
Solaris systems. It is also possible to specify 'NONE' to indicate not to use
a package manager. The program default is 'NONE'.

Any file which is not part of a package is treated as before, that is,
the HASH_CMD configuration file option, or the '--hash' command-line
option, will be used.

It should be noted that all the package managers, except 'SOLARIS', provide
a hash value for a file. However, the 'RPM' and 'SOLARIS' package managers
can provide other file property values as well, such as the file permissions,
uid, gid, modification time and so on. During the file properties check all
of these values will be used, rather than the ones stored in the rkhunter.dat
file. The Solaris package manager does store a 16-bit hash value, but this is
not used by default. If it is wished to use the stored value, then the
USE_SUNSUM configuration option must be enabled.

It should also be noted that the 'DPKG', 'BSD' and 'BSDng' package manager
options only provide a files hash value. As such, during the file properties
check, all the other current file properties will be re-calculated as before,
and compared against the values in the rkhunter.dat file. Hence, only the 'RPM'
and 'SOLARIS' package managers offer any real benefits in using a package manager.

NOTE: It is possible for a package manager database to become maliciously
corrupted. To that extent the use of the package manager options with RKH
does not provide any increase in security. However, it may result in less
false-positive warnings of files which have changed. As always RKH can only
report on changes, but not on what has caused the change.

USING LOCAL MIRRORS
===================

When the '--update' or '--versioncheck' options are used, rkhunter uses
a mirror site from the mirrors.dat file to obtain the required information.
By default rkhunter will use any mirror listed in the file, and it will
then rotate the list of mirrors. At the time of writing the supplied
mirrors.dat file lists the Rootkit Hunter SourceForge site as a mirror.

However, it is possible for users to define a local mirror if they wish to.
This is done by simply editing the mirrors.dat file and inserting the
mirror URL. The line should begin with the text 'local='. For example:

local=http://www.example.com/rkhunter_data

The required rkhunter files must be placed in a location, of the users choice,
which is accessible by the clients. So in the above example, the rkhunter
data files would have been placed in the 'rkhunter_data' directory. The
required files consist of the '.dat' files supplied with rkhunter, and which
will have been installed in the database directory. For a default
installation this would have been in '/var/lib/rkhunter/db'.

Additionally, the mirror directory must have an 'i18n' sub-directory which
contains all the current language translation files for the various versions
of rkhunter. Each version is put into its own sub-directory. So, for example,
there would be a '1.4.0' sub-directory, a '1.4.2' sub-directory and so on,
all within the 'i18n' directory. Again, the database directory will already
have had the 'i18n' sub-directory installed in to it, but it will only
contain the language files for the current version of rkhunter. There are
no version sub-directories installed by default. As such, the mirror will
need to have the various version sub-directories created, and the relevant
language files put in to them, for the versions of rkhunter that the mirror
is required to support. If a client tries to access the language files for a
version of rkhunter that is not supported by the mirror, then the download
will fail. Depending on how the client is configured, another, possibly
remote, mirror may be tried, or rkhunter will give a warning.

Within each rkhunter version sub-directory of the 'i18n' directory, it is
necessary to have a file called 'i18n.ver'. This file simply contains a list
of the available language files, and their version numbers. For example:

cn:2009112801
      en:2009112902

So, as an example, the mirror file structure will need to look similar
to this:

rkhunter_data
                            ||
                            ||
     ===============================================
     ||               ||              ||          ||
 mirrors.dat  rkhunter_latest.dat    i18n    suspscan.dat
                                      ||
                                      ||
                  1.3.8 ============ 1.4.0 ============ 1.4.2
                  / | \              / | \              / | \
                 /  |  \            /  |  \            /  |  \
               cn  en  i18n.ver   cn  en  i18n.ver   cn  en  i18n.ver

Finally, if the '--versioncheck' option is to be supported with the local
mirror, then the directory, 'rkhunter_data' in the above example, must
contain a file called 'rkhunter_latest.dat'. This file must contain the
current rkhunter version number (for example, '1.4.0') and no other text.

It is possible to similarly define 'remote' mirrors, which begin with the
text 'remote='. At present though there is no real difference between a
local or remote mirror.

The supplied mirror site(s) in the mirrors.dat file begin with the text
'mirror=', and this should not be changed.

In order to select whether all the mirrors or only the local or remote
mirrors should be used, the rkhunter configuration file has an option in
it called 'MIRRORS_MODE'. This option takes a numeric value, which by default
is zero. The current values and meanings are:

0 - use any mirror (the default)
    1 - use only local mirrors
    2 - use only remote mirrors

To further support local and remote mirrors there are two other configuration
options available:

The first is 'UPDATE_MIRRORS', which simply tells rkhunter whether the
mirrors.dat file itself should be updated (i.e. overwritten) when the
'--update' option is used. If local mirrors are listed in the file then you
probably do not want the file automatically updated. The 'UPDATE_MIRRORS'
option has a default value of one, indicating that the mirrors.dat file should
be updated. Set this option to zero to disable this feature.

The second option is 'ROTATE_MIRRORS'. This tells rkhunter whether it should
rotate the list of mirrors whenever the '--update' or '--versioncheck' options
are used. Again, with local mirrors you may want these accessed in a specific
order, rather than rotated each time. The option has a default value of one
indicating that the mirrors should be rotated. Set this option to zero to
disable this feature.

By default if a mirror fails for some reason, then rkhunter will use the next
mirror, of the configured type, listed in the file. If there are no more
mirrors left, then rkhunter will give a warning message.

CREATING A NEW LANGUAGE FILE
============================

Creating a new language file to work with rkhunter is quite easy - the actual
translating is the hard part! First, it is necessary to find out where the
current language files are located. For a default installation this will be
in the '/var/lib/rkhunter/db/i18n' directory. If this directory does not
exist, then look in the rkhunter log file (usually located in /var/log) and
there should be a line similar to 'Using... as the database directory'.
Within that directory there should be the 'i18n' sub-directory. Once you
have changed to that directory, you should then see the current language
files. Next, take a copy of the 'en' language file and name it for your new
language. We would suggest that you use something similar to the known
ISO 639 language codes. For example, to create a generic French language
file, then execute 'cp -p en fr'. Once you have done this, your new language
file will be recognised by rkhunter. You can check this by using the command
'rkhunter --list lang'. Note that if you use the 'rkhunter --update' command,
the new language file will not be touched in any way. Also note that you must
not remove the 'en' file, rkhunter will not work without it.

The next part is to actually translate the messages. Each language file starts
with a line containing the version number of that file. The actual messages
start with a keyword, which must not be changed at all, followed by a colon
(:), and then the actual message. It is the actual message which you need to
translate. Some messages may contain variables such as '$1' or '$2'. Again,
these must not be changed. Once you have translated the messages you can test
them by using the command 'rkhunter --lang fr ...' - substituting 'fr' for
whatever name you gave to your language file.

If you want to have your new language translation made available as part of
rkhunter, then please submit a feature request on the rkhunter SourceForge
web site. However, please be aware that the language file is a fundamental
part of rkhunter, and as such is continuously changing. You should endeavour
to keep your translation up to date with the current version of rkhunter.

ROOTKIT HUNTER GENERAL SUPPORT
==============================

If a problem is found with RKH, it is recommended that users initially
try and resolve the problem themselves. This can be done by first
checking the FAQ file, which is present in your installation if the
distributed tarball is used as source. The FAQ will contain answers 
to many common problems. The latest version of the FAQ can always be 
found at RKH's project pages on SourceForge, in the 'Documentation' 
section.

If the problem has occurred directly after upgrading RKH, then please
check the CHANGELOG file. It will contain information about changes
made since the previous version of RKH, and may indicate why you are
now experiencing a problem.

Users should also check the rkhunter-users mailing list archives
(available on the web site). The problem will be investigated by the
RKH development team, and, where appropriate, a solution posted on the
mailing list. Hence the mailing list archives may well contain a
solution to the problem.

Additionally, users should check the RKH tracker system (available at
http://sourceforge.net/tracker/?group_id=155034). It is quite
possible that the problem has already been reported to us as a bug or
support request. It is also possible that a fix for the problem has
been provided in the tracker log.

Depending upon the nature of the problem it may be worthwhile trying
an Internet search (for example using google), to see if anyone else
has experienced a similar problem.

Finally, if you have still not found an answer to the problem, then
mail it to the rkhunter-users mailing list. Please provide as much
information as possible about the problem, but do not make the
message excessively long! Information such as your operating system
and version of RKH should always be included.

Please be advised that while you are free to ask for advice in your 
favourite IRC channel, all-purpose forum or distribution mailing list,
the demonstrated level of general and security knowledge and experience, 
and therefore the quality of responses, may vary (very much).

If you are sure the problem is a bug, or want it considered as a
support request, then please submit it directly into the tracker
system.

ROOTKIT HUNTER REPORTS SIGNS OF A POTENTIAL BREACH OF SECURITY
==============================================================

When you think you have a (potential) security problem it is advised to 
think and inform yourself thoroughly before you act. Please consider
checking the FAQ, the rkhunter-users mailing list archives, your
distribution documentation about security and security issues and the 
CERT Intruder Detection Checklist, formerly located at 
http://www.cert.org/tech_tips/intruder_detection_checklist.html, and 
archived at http://web.archive.org/web/20080109214340/\
http://www.cert.org/tech_tips/intruder_detection_checklist.html.
If you do not have the required knowledge and experience to deal with
security issues then please ensure yourself that the people who respond 
do and have.

- Logging in, killing processes, deleting files, powering down, rebooting
  the machine, removing or installing software may signal the intruder and
  may destroy vital information. If you need to communicate with people or
  compile software then do use a different machine to work on.
- If usage of the machine is governed by rules and regulations consider
  alerting the designated security officer or team, systems or network
  administrators or IT department before doing anything else.
- In your initial email or post include as much information and make it
  as detailed as possible. The more details you provide the more efficient
  the troubleshooting or incident response process will be.
- Do not be easily satisfied or mistake "don't worry" type of replies for
  qualitatively good answers: read the FAQ, ask for specific steps to take
  and commands to run so you can verify things yourself.
- Please act timely and responsibly. (Potential) security problems should be
  prioritized and acted on at the time of reporting, not days or weeks later.

ROOTKIT HUNTER AS PART OF YOUR SECURITY STRATEGY
================================================

Rootkit Hunter is a host-based, passive, post-incident, path-based tool.

- Host-based means it only diagnoses the host you run it on.
- Passive means it has to be scheduled or run manually.
- Post-incident means it can only be effective when a breach of security
  is suspected, is in progress or has already occurred. Due to the nature of
  software that hides processes and files it may be beneficial to run Rootkit
  Hunter from a bootable medium if a breach of security is suspected and the
  machine can be booted from a bootable medium.
- Path-based means RKH will check for filenames. It does not include or use
  heuristics or signatures like for instance an antivirus product could. Do 
  understand that the SCANROOTKITMODE configuration option and "suspscan" 
  functionality are just crude attempts to try and bridge that gap.

Rootkit Hunter is best deployed as part of your security strategy.

- Most breaches of security are preceded by reconnaissance. Regular system
  and log file auditing provides the necessary "early warning" capabilities.
- RKH does not replace, or absolve you from performing, proper host hardening.
  Common administration errors that may result in a breach of security includes
  failing to apply updates when they are released, misconfiguration, lack of
  access restrictions and lack of auditing.
  Please see your distribution documentation and search the 'net.
- Do not rely on one tool or one class of tools. Consider installing same-
  class tools like Chkrootkit or OSSEC-HIDS and consider overlap as a Good
  Thing. Additionally it is suggested you install and use a separate filesystem
  integrity scanner like Samhain, Aide, Integrit, Osiris (or even tripwire) to
  provide you with a second opinion.
- Like with all data used for verifying integrity it is recommended to 
  regularly save a copy of your RKH data files off-site.