Modify rkhunter.conf
Modify for BSD users
BSD users please note: 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 rooty"
Modify for cusom install of rkhunter
If you have installed rkhunter 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 rkhunter 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 unhide
Can be made prior to first scan. unhide is available for a number of distributions.
http://www.security-projects.com/?Unhide
The tarball is available here
http://www.security-projects.com/unhide20100819.tgz
Recommended: test the unhide command prior to using with RKH
su - unhide -v quick > /tmp/quick (Otherwise try these? YMMV) unhide -v brute > /tmp/brute unhide -v proc > /tmp/proc unhide -v procfs > /tmp/procfs unhide -v reverse > /tmp/reverse unhide -v sys > /tmp/sys
unhide will report if it finds positive results.
Now edit your CONF, I suggest:
ENABLE_TESTS="all"
DISABLE_TESTS="none"
SCAN_MODE_DEV=THOROUGH
Remember to run propupd to update your database for your changed conf file, and checking log you may find positive hits
eg
[17:34:21] Info: Starting test name 'running_procs'
[17:34:21] Checking running processes for suspicious files [ None found ]
[17:34:21] Info: Starting test name 'hidden_procs'
[17:34:38] Checking for hidden processes [ None found ]
Running unhide -v proc and checking its contents I can see its no hits as per
Unhide 20100819 http://www.security-projects.com/?Unhide [*]Searching for Hidden processes through /proc stat scanning
Modify CONF to use command skdet
Can be made prior to first scan. Means Performing Suckit Rookit additional checks. Dick Gevers has made this available in the spirit of GPL as the original author can not be traced. Original author's contact was slider <slider@…>
Download it from here
http://dvgevers.home.xs4all.nl/
If you have already added /usr/local/sbin to your root BINDIR pathway, the rpm should work straight away. Or you can move and hide the executable and modify the pathway to suit.
Test it works
skdet -c 1 init...... many lines of output culled 5991 skdet
Comment...My pc was KDE on initial wiki creation. There is also skdet -s but netstat -atun appears better.
Now run rkhunter with all tests similar to unhide, logfile excerpt:
[17:29:37] Performing Suckit Rookit additional checks
[17:29:37] Checking /sbin/init link count [ OK ]
[17:29:38] Checking for hidden file extensions [ None found ]
[17:29:38] Running skdet command [ OK ]
[17:29:38] Suckit Rookit additional checks [ OK ]
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 ]
