readme

在网络安全中经常会遇到rootkit

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 user
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 enabled test list of '--enable all'. In the
previous example, '--disable none' will have been assumed.

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 tests 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, and 'BSD' for *BSD 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_FUNC configuration file option, or the '--hash' command-line option, will
be used.

It should be noted that all the package managers provide an MD5 hash value for
a file. However, the 'RPM' package manager 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.

It should also be noted that the 'DPKG' and 'BSD' package manager options
only provide the files MD5 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'
package manager offers any real benefit 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.3.1' sub-directory, a '1.3.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:2007061401
      en:2007102501

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.1 ============ 1.3.2 ============ 1.3.3
                  / | \              / | \              / | \
                 /  |  \            /  |  \            /  |  \
               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.3.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.


ROOTKIT HUNTER 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.

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.