Rootkit Hunter Wiki
Brought to you by:
dogsbody,
dogsbodymark
Menu
▾
▴
modify
Modify rkhunter.conf
Some config edits can be done before first scan.
John's TIP for edits
Have all changes at the tail or bottom of your config. This may mean that you
comment out a line in the body.....so it acts as the default setting
Then you copy and paste to the tail and make your edit there.
Let me show a couple of examples for home users?
(at line 424) #PKGMGR=NONE
Copy and paste to tail and edit it as example only
PKGMGR=DPKG
(at line 616) #ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz
Paste and edit to tail as example only
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz
(at line 353) DISABLE_TESTS=suspscan hidden_ports hidden_procs deleted_files packet_cap_apps
Comment out above line
Paste and edit to tail....as example only
DISABLE_TESTS=suspscan deleted_files packet_cap_apps
Suggest edit CONF prior to first scan --to use skdet
Discussed on its own wiki page
Suggest edit CONF prior to first scan --to use unhide
Discussed on its own wiki page
Modify for BSD users
Allow the following accounts to be root equivalent. These accounts will have a UID value of zero. This option is a space-separated list of account names. The 'root' account does not need to be listed as it is automatically whitelisted.
UID0_ACCOUNTS=toor
Modify for custom install of RKH
If you have installed RKH in a custom layout such as opt, you may need to edit your CONF to include that directory in the bin search.
BINDIR="/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /usr/libexec
/usr/local/libexec /opt/bin"
Modifications can be made before or after propupd command is run. So I place some mods here and others in flowchart stage 7 area. I expect you will tune your CONF in the top 7 flowchart stages and then not have to have to modify it unless you make major changes to software. Be aware that RKH may need to find more than just the executables in the BINDIR pathway. The log is your guide.
Modify for distros using pre-link
The FAQ states: Your system probably uses prelinking (the log file will say if it does or not). Sometimes a file may be updated but not be prelinked. When this happens RKH cannot determine the files hash value. If you run the command
" # prelink --verify --sha <file>
it will probably give an error about the files dependencies having changed. This is what RKH sees, and flags it as a missing hash. If you are sure that the file is genuine,then you can try using
" # prelink <file>
to correct it. The 'prelink' command above should then work. Re-run RKH with the '--propupd' option to ensure that all the hash values are recorded.
Short-term prelink dependency errors can usually be resolved simply by running the prelink command on the given pathname. However, if it is more enduring consider changing to this part of the CONF. IGNORE_PRELINK_DEP_ERR="/bin/ps /usr/bin/top"
Modify for your own watch list and create watchlist for WHITELISTED files
It is now possible to nominate folders or files not already scanned by RKH. Be aware, that once they are in the CONF, they act like any other bin or sbin type file and may report further warnings consistent with the executable. An example would be if RKH detects your watched file is a replacement script.
'#USER_FILEPROP_FILES_DIRS=
It can be folder or a file, so one entry for each pathway please.
Here is an example on my system to remove a false positive for a certain rootkit that hit hdparm.
USER_FILEPROP_FILES_DIRS=/etc/init.d/bootlogd
USER_FILEPROP_FILES_DIRS=/etc/init.d/checkroot.sh
After updating the properties database and doing a new scan, the sh function created further RKH warnings so I then added a whitelist after confirmed the contents of the script was indeed false positive.
SCRIPTWHITELIST=/etc/init.d/bootlogd
SCRIPTWHITELIST=/etc/init.d/checkroot.sh
Part two.
It is now possible for each whitelisted file, to nominate them with
USER_FILEPROP_FILES_DIRS=<filename>
so RKH after running propupd, can include the whitelisting properties file. In other words, you do not want a file whitelisted and then someone substitute it without receiving a warning.
Please remember to always run propupd, after validation process so your whitelisted files are protected from unauthorised changes. Naturally some system updates will cause RKH log and mail to show warnings and it is still up to to user to investigate each warning.
Modify CONF for package manager
Normally enabled prior to your first scan. RKH will scan your package manager data files.
'#PKGMGR=NONE
Change to
PKGMGR=RPM (or DPKG) (or BSD)
No matter which you choose, verify it works, later by reading the top area of your log file.
14:30:03] Info: Using package manager 'RPM' for file property checks
The README states.....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,
/var/lib/rkhunter/db/rkhunter.dat
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.
A package manager will be used to check whatever values it provides as part of the file properties check. However, none of the current package managers provide all the information - for example, has a file changed from being a binary to a shell script? The rpm package manager cannot tell you that. So RKH will perform other checks as well to verify that the file has not changed at all. As far as I remember there are 10 or 11 tests in the file properties check. The rpm package manager provides about 7 or 8 test values, the bsd and Debian package managers only provide 1. All the other test values are obtained by other means and compared against the rkhunter.dat file. This is why the '--propupd' option should be one of the first used after rkhunter has been installed. It creates the rkhunter.dat file, and allows rkhunter to fully check each file in the file properties check. If it ('--propupd') is not used, then the file properties check can only perform some of the tests (those not requiring the rkhunter.dat file).
I asked if the RPM checks could be shown in the log in a more explicit way.
Answer: There is not really any useful additional information to be logged if a file has passed rpm verification, other than the fact that it has passed the test.
Modify CONF for hash values
Normally enabled prior to first scan. As RKH is available to Operating Systems All POSIX (Linux/BSD/UNIX-like OSes) it is possible you may have a system that can not use the package manager method. Using locally supplied hashes is the new way of doing things. So, this scan should be used in combination with other options. To repeat, there is nothing stopping you use all methods if available....and I suggest you do.NOTE not all files are changed due to system updates. For these to be detected, even if false positive, the rkhunter will still use a hash value check. According to the new README ....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.
NOTE: If the hash function is changed then you MUST run rkhunter --propupd command to rebuild the file properties database.
Hashes are available either as :
For Solaris 9 : HASH_FUNC=gmd5sum
For Solaris 10: HASH_FUNC=sha1sum
For AIX (>5.2): HASH_FUNC="csum -hMD5"
For NetBSD : HASH_FUNC="cksum -n -a sha512
For other *nix systems then those that use prelinking are restricted to using either SHA1 or MD5 functions. To get rkhunter to look for the sha1(sum)/md5(sum) command, or to use the supplied perl scripts, simply specify this option as 'SHA1' or 'MD5' in uppercase. The default is SHA1, or MD5 if SHA1 cannot be found. So changes are needed in the CONF in this area:
HASH_FUNC=sha1sum
The HASH_FLD_IDX option specifies which field from the HASH_FUNC command output contains the hash value. The fields are assumed to be space-separated. The default value is one, but for BSD users rkhunter will automatically use a value of 4. The option value must be a positive integer.
HASH_FLD_IDX=4.
So valid values of Hash function are..SHA1..MD5...gmd5sum...sha1sum....(note the use of double quotes for the next 2) "csum -hMD5"......."cksum -n -a sha512"
e.g. of a possible Slackware CONF?
HASH_FUNC=sha1sum
No need to comment out and change the (#) HASH_FLD_IDX=4 CONF line as default is 1.
e.g. of a possible BSD CONF?
HASH_FUNC="cksum -n -a sha512
HASH_FLD_IDX=4
e.g. After choosing MD5 CONF option I can verify it worked by this log entry
09:19:40] Info: Using the '/usr/bin/md5sum' command for the file hash checks
Modify CONF for suspscan test
Purpose: checks for files with suspicious contents.
When: prior to first scan.
Caveats: suspscan is not and should not be enabled by default because it is CPU and I/O intensive.
ENABLE_TESTS="all"
DISABLE_TESTS="none"
You could always use the named test but I like to keep it simple. After adding this test to your CONF the log shows:
21:46:35] Info: Starting test name 'suspscan'
21:46:35] Directories to check are: /tmp /var/tmp
21:46:35] Temporary directory to use: /dev/shm
21:46:35] Maximum file size to check (in bytes): '1024000'
21:46:35] Score threshold is set to: 300
21:46:35] Checking directory: '/tmp'
21:46:38] File checked: Name: '/tmp/drakx-images/IM_001-FON-UK.png' Score: 0 Hitcount:
Hits: ()
21:51:11] No suitable files found to check.
The above logfile reports my setting that are selected in the CONF. Read the CONF for more info but it does warn do not enable by default as suspscan is CPU and I/O intensive and prone to producing false positives. Run it at least once to see how long it takes, on my system total time for the lot was less than 7 minutes.
On another run I get this:
14:11:00] Warning: File '/var/tmp/kdecache-gordy/http/a/www.aco.com.au44e985dc'
(score: 221) contains some suspicious content and should be checked
The above site wanted flash and javascript. I had some trouble with that site.
Note that one of the settings in the CONF is your temporary directory for suspscan so the log will show this
08:58:38] Info: SCAN_MODE_DEV set to 'THOROUGH'
08:58:52] Checking /dev for suspicious file types ( Warning )
08:58:52] Warning: Suspicious files found in /dev:
08:58:52] /dev/shm/suspscan.4988.strings: ASCII text
The above warning can be ignored.
I recommend do not whitelist any /dev/shm file either so you can catch and check all warnings of this nature
Modify CONF to use command tripwire
Can be made prior to first scan. I do not recommend RKH include this scan but prefer running tripwire with its own daily cronjob.
ENABLE_TESTS="all"
DISABLE_TESTS="none"
SCAN_MODE_DEV=THOROUGH
The manual scan does not mention Tripwire by name but the logfile shows
09:31:39] Checking for software intrusions ( None found )
Tripwire adds considerable time to the RKH scan.
OPTIONAL change some system files
This is not a modification of your CONF but can be made prior to first scan to harden your system.
Here I have disabled all /etc/ssh/config files and the ssh executable, log result:
Performing system configuration file checks
Checking for SSH configuration file ( Not found )
