From LQWiki
This page can be translated to major languages here http://www.online-translator.com/ or google for other translators. I have changed to thumbnails, click on the link to see the bigger picture (no pun intended)
IN this wiki....I use update(s) to mean update or upgrade and RKH = the rootkit hunter scan.
The CONF file refers to /etc/rkhunter.conf.
Disclaimer
I am not a part of the dev team but a home user. You are welcome to email me if you have any concerns and can not help with the wiki directly. Otherwise feel free to edit
lqaus9@yahoo (dot) com (dot) au
Download
The stable 1.2.9 version has almost finished its job and its time to look at the cvs edition 1.3.0
If you have time to test the beta for 1.30 its here
http://sourceforge.net/project/showfiles.php?group_id=155034
I assume you know how to run the stable version. If you have come here by accident but are interested in rootkit detections the main page is here http://wiki.linuxquestions.org/wiki/Rootkit_Hunter
You can go to the main sourceforge rkh site and click on cvs and follow those instructions or you could, if using a good browser, click on the next link to download the tarball. If the link fails try copy and paste into your browsers address bar and press enter?
http://rkhunter.sourceforge.net/rkhunter-CVS.tar.gz
The rest of the links are snapshots that may assist you?
http://www.filehigh.com/viewimg.php?f=38573&i=430918
Install or remove
Expand and install the executable
http://www.filehigh.com/viewimg.php?f=38573&i=430913
The above picture shows a DEFAULT install using root powers. If you do not like that, feel free to read the /Path-to-rkh-files/README on other options.
There is also a FAQ and a CHANGELOG in that folder.
My preferred install commands are....
su (root password) (or sudo if su is not an option)
cd /path-to-rkh-cvs edition/rkhunter/
sh installer.sh --layout default --install
You can remove it with a similar type su and cd command and then
sh installer.sh --layout default --remove.
This removal is your choice but is handy if you are wanting to do a clean install of an updated cvs rkh. Note some files may remain as per this picture so pls check.
http://www.filehigh.com/viewimg.php?f=38573&i=457721
The install now supplies commands in a shell including
rkhunter --update
rkhunter --propupd
rkhunter -c -sk
rkhunter --versioncheck
Rootkit hunter can also be run as a cron job. If home users turn off their computers, anacron may also be needed to run any job that has missed its cron schedule?
I suggest you do not create the cron job until you are happy with the results of a manual scan.
Changelog ...FAQ.....and Readme are now expanded and improved
Changelog is a new file but has high relevance is showing you different things you can do.
FAQ has been greatly expanded and answers all those important questions
Readme has also changed to reflect the emphasis on local verification and external supplied data files.
Understanding the PROPUPD command
rkhunter --propupd
Means update your system file properties. This is now a necessary step to establish a base or data file to compare scans.
Do this ONLY when you are satisfied you have only trusted source system file changes. Rkhunter now offers choices in how you verify system file changes which impacts on how to use the command.
http://www.filehigh.com/viewimg.php?f=38573&i=430914
You use the /var/lib/rkhunter/db/rkhunter.dat file that is created by this propupd command in combination with other scans.
Home users may have difficulty in establishing legit files from illegal files so I suggest that you do a clean install. Since you are doing a clean install, you may as well install independent tools like Tripwire and create initial data files for those type of tools as well. Other suggestions are to disable as many services as possible and especially if you are using a ....always on...computer, disable the ssh daemon or disable all configs files for it. eg On Mandriva, config files are in /etc/ssh, init scrips may be called from /etc/init.d and the executable resides in /usr/bin. Symbolic links may be in /etc/rc (number) folders but they link to init.d
The rkhunter scan will detect how bad your config file is, but if you do not need ssh, why not try turning it off? On my system, I can not remove it without breaking some other files I depend on. So disable is my preferred option.
If you are unwilling to rebuild from a clean install, home users will be forced to check scan warning results with tools like their package manager.
eg rpm -q rpmdrake gives response rpmdrake-3.69.1-1.1mdv2007.1
/var/log/syslog shows when it was updated ....Jul 11 14:26:09 MandrivaUpdate[5069]: [RPM] rpmdrake-3.69.1-1.1mdv2007.1 installed
My package manager shows what files were impacted eg /usr/bin/MandrivaUpdate
Depending on your download mirror, you may be able to verify the stored cache rpm file's md5sum with the hash at the web site. But as you can guess, it is a lot safer to start from a clean install. (It is the one you miss that is the one that is likely to bite you.)
So, to repeat, we use the properties update command.....IF..... we have verified the properties reported by the scan are legit and can therefore be removed from future scans.
I want to warn that, once you have verified all is legit, you MUST run the propupd command. Why? Because, to compare changes it is necessary to have a base or foundation to work from. This means that the data file created acts similar to Tripwire and other related products that look for changes.
Warning....once verified if the propupd command is not run, and an illegal change is made, you have no data to compare changes so you may only get that a basic change has occurred.
Read this again until understanding is achieved before you venture into changing your scans please.
Simple scan
rkhunter -c -sk
Means scan done with root powers so output can be written to logfile called /var/log/rkhunter.log.
-c means the same as --check (that is perform the scan based on the config file located at /etc/rkhunter.conf)
-sk means skip keyboard presses to allow scan to be done in one hit. It assumes you have a shell or terminal or konsole or whatever, that has a scroll function, that can be used in post scan review.
If you are unsure what that means just run .....rkhunter -c .....instead.
Your first simple scan
Lets do the following root commands after installing rkh.
No internet for these commands
rkhunter -c -sk
Verify warnings for properties of files are legit then run the propupd command. The first scan may also detect various script replacements. Again its up to you to check they are legit. I suggest you edit the config file for at least the hidden files or directories and whitescript settings....see the options below.
rkhunter --propupd
Now we can connect internet and run
rkhunter --versioncheck
then its
rkhunter --update
http://www.filehigh.com/viewimg.php?f=38573&i=430919
rkhunter -c -sk (to re-check sytem files..... if updates were available)
Then update your system using your package manager or whatever and then re-run the scan command.
If changes are detected, verify the changes are legit and then run the propupd command.
We then continue this cycle forever.....update system....scan....verify results...run propupd command.
It should become clear, that the art of verifying your detected changes are legit,.... needs to be smarter and faster. Rootkit hunter, may have the answer. See the package manager method and the Tripwire scan for help in this area.
COMBINATION scan using package manager
Enabling package manager option means extra scans occur in the .....File property checks.
We assume you have understood how to use the propupd command and have run it to establish your first data file. Now lets find a way to assist in verifying system files that are detected by a scan....possible false positive detections....are actually legit file changes.
The scan is a combination of using the data file and an extra config setting in your config file. Naturally, this is only good for changes effected in using the package manager for your style of system.
Modify the CONF file to use the appropiate package manager style....RPM...DPKG....or BSD.
We need to change 1 lines to our CONF file. This line may be commented out using the # symbol, if so pls remove the #
PKGMGR=NONE ....Change NONE to RPM...DPKG....or BSD
No matter which you choose, verify it works by reading the top section of your log file.
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' package manager offers any real benefit in using a package manager.
In a public avaiable reply to one of my emails, John Horne advises that...... 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 RKH has been installed. It creates the rkhunter.dat file, and allows RKH 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). .....end of email quote.
Home users would then repeat this cycle ..more system updates ...more scans and hopefully no reported non-authorised changes.
What is now different? Less work for home users to verify CERTAIN system files as the extra scan is doing the work.
What is still to be done? Checking other scan results not attributed to using the package manager.
eg After I chose RPM in the CONF file I can verify it worked by this log entry
[09:19:40] Info: Using package manager 'RPM' for file property checks
[09:19:45] Performing file properties checks
[09:19:45] Info: Starting test name 'properties
In another public viewable email, I asked if the RPM checks could be shown in the log in a more explicit way. At the time I was not aware it was already in the file properties check. However, John's reply states...
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.....end quote.
COMBINATION scan using local machine supplied hash values
Enabling hashes check means extra scans occur in the .....File property checks
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. eg Slackware
Using locally supplied hashes is the new way of doing things. So, this scan should be used in combination with others like package manager. 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 RKH 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.
Back to the action.
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.
UNIX appears to be owned by The Open Group according to this link http://news.zdnet.com/2100-9595_22-1016221.html
So changes are needed in the CONF file in this area:
(#)HASH_FUNC=sha1sum
(#)....the following is all commented
(#) 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"
Please verify your settings are working, the log file reveals all.
eg 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 ....as is...
eg of a possible BSD CONF?
HASH_FUNC="cksum -n -a sha512
HASH_FLD_IDX=4
eg 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
To a public viewable email, I quote relevant parts...
Does the RPM checks replace the hashes value checks? > Forget about the old 'hashes' check, that releated to version 1.2.9 and before. Version 1.3.0 has a 'file properties' check. One part of that check is to see if a files hash value has changed. This can be done using a package manager, or by other means and then comparing against the value stored in rkhunter.dat. The CHANGELOG file points out that the file properties check checks more than just the files hash value though.
Recommended sequence - for CLI users
If you do not want cron or anacron handling your scans, then a manual scan in a good terminal is the way to go. I use Konsole.
Steps are:
1 Install
2 update.....rkhunter --update
3 first scan....rkhunter -c -sk......(or rkhunter -c -sk --pkgmgr RPM) or other such switches depending on what you left out of your CONF file.
4 create properties data file....rkhunter --propupd
5 Your next scan and thereafter is a cycle of
rkhunter --update and rkhunter -c -sk
BSD users please note
The CONF file suggests... 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. Note: For *BSD systems you may need to enable this for the 'toor' account.
UID0_ACCOUNTS="toor rooty"
Check the summary results
http://www.filehigh.com/viewimg.php?f=38573&i=430917
Read the log file
The log provides more information than available from the command line or stdout.
It should be here
/var/log/rkhunter.log
ROOTKIT HUNTER SUPPORT
There are detailed helpful tips on what to do in the README.
ROUGHLY they include
check the FAQ
check the CHANGELOG (this is a new file)
check the mail archives
check if a bug or support request has already been lodged here http://sourceforge.net/tracker/?group_id=155034)
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
checking for similar reports by others using a search engine like google.
FINALLY send an email if all else fails.
OPTIONAL whitelist hidden files or directories in /etc/rkhunter.conf
This is a frequent event for most distros to have hidden files or directories that you may consider whitelisting them.
If logfile shows this
[08:58:53] Checking for hidden files and directories [ Warning ]
[08:58:53] Warning: Hidden directory found: /etc/.java
[08:58:53] Warning: Hidden directory found: /dev/.udev
[08:58:54] Warning: Hidden directory found: /dev/.udevdb
and
[08:58:54] Warning: Hidden file found: /usr/share/man/man1/..1.bz2: bzip2 compressed data, block size = 900k
Similar to stable version, check them out and if ok you can whitelist them in the CONF file like this
Allow the specified hidden directories by removing the hash for the verifed common ones already in CONF file or you may need to add them..
(#) One directory per line (use multiple ALLOWHIDDENDIR lines)
ALLOWHIDDENDIR=/etc/.java
ALLOWHIDDENDIR=/dev/.udev
ALLOWHIDDENDIR=/dev/.udevdb
(#)ALLOWHIDDENDIR=/dev/.udev.tdb
(#)ALLOWHIDDENDIR=/dev/.static
(#)ALLOWHIDDENDIR=/dev/.initramfs
(#)ALLOWHIDDENDIR=/dev/.SRC-unix
(#) Allow the specified hidden files.
(#)One file per line (use multiple ALLOWHIDDENFILE lines).
(#)ALLOWHIDDENFILE=/etc/.java
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz
(#)ALLOWHIDDENFILE=/etc/.pwd.lock
(#)ALLOWHIDDENFILE=/etc/.init.state
OPTIONAL whitescript your bourne shell replacements or other scripts
If log shows bourne shell replacements or other scripts like this
[08:48:02] /bin/egrep [ Warning ]
[08:48:02] Warning: The command '/bin/egrep' has been replaced by a script
/bin/egrep: Bourne shell script text executable.
I knew I should be ok as this log was created on a clean install with no network local or external. You may need to research your scripts with your distro forum or try linuxquestions.org?
After verifying each is ok edit the CONF file for this section, in my case I added the line to the list
(#) Allow the specified commands to be scripts.
(#)One command per line (use multiple SCRIPTWHITELIST lines).
(#)SCRIPTWHITELIST=/sbin/ifup
(#)SCRIPTWHITELIST=/sbin/ifdown
(#)SCRIPTWHITELIST=/usr/bin/groups
SCRIPTWHITELIST=/bin/egrep
On rescan RKH no longer gives any warning(s) for those whitelisted.
OPTIONAL edit other sections of your CONF file
There are several more edits you could do, read the /etc/rkhunter.conf to see what effect they may have.
Similar to all other edits, verify that you have valid system files before whitelisting or changing any scan method etc.
OPTIONAL change some system files
Here I have deleted all /etc/ssh/config files so the result becomes
http://www.filehigh.com/viewimg.php?f=38573&i=430916
OPTIONAL run the scan using the suspscan test
Means Checking for files with suspicious contents
CONF file using the simple commands
ENABLE_TESTS="all"
DISABLE_TESTS="none"
SCAN_MODE_DEV=THOROUGH.
You could always use the named test but I like to keep it simple.
After adding this test to your CONF file 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: ()
file culled...
[21:51:11] No suitable files found to check.
The above logfile reports my setting that are selected in the CONF file. Read the CONF file for more info but it does warn that do not enable by default as suspscan is CPU and I/O intensive and prone to producing false positives.
OPINION Run it at least once to see how long it takes, on my system total time for the lot was less than 7 minutes.
Note that one of the settings in the CONF file 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
and the warning is to be ignored.
OPINION I suggest you do not whitelist any /dev/shm file either so you can catch and check all warnings of this nature.
OPTIONAL run the scan using the independent tool.....unhide
Means checking for hidden processes.
The CVS edition can be modified in the tests it runs to include unhide. Here is one way to get it working. Thankyou John Horne for assistance in my method.
Download unhide from here
http://www.security-projects.com/?Unhide:Download
After downloading the 28 Dec 05 file, unpack it and install it assuming everyone is now running a 2.6 kernel using root powers for the commands.
tar zxvf unhide.tgz
cd /home/yourname/unhide-28-12-2005
gcc -Wall -o unhide unhide-linux26.c
Move new command ...unhide.....to a root pathway eg /usr/local/sbin and edit your /etc/rootkithunter.conf file to show that pathway.
BINDIR="/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /usr/libexec /usr/local/libexec"
Test the unhide command works independently? You should get this output
[root@localhost /]# unhide sys
Unhide 28-12-2005
yjesus@security-projects.com
[*]Searching for Hidden processes trougth getpriority() scanning
[*]Searching for Hidden processes trougth getpgid() scanning
[*]Searching for Hidden processes trougth getsid() scanning
[*]Searching for Hidden processes trougth sched_getaffinity() scanning
[*]Searching for Hidden processes trougth sched_getparam() scanning
[*]Searching for Hidden processes trougth sched_getscheduler() scanning
[*]Searching for Hidden processes trougth sched_rr_get_interval() scanning
http://www.filehigh.com/viewimg.php?f=30814&i=446156
Now edit your rkh.conf file ....I suggest simple one is
ENABLE_TESTS="all"
DISABLE_TESTS="none"
SCAN_MODE_DEV=THOROUGH
This will now include unhide in the scan process but thorough will take about 5 minutes depending on your hardware. Leaping ahead the scan command was
rkhunter -c -sk
http://www.filehigh.com/viewimg.php?f=30814&i=446157
OPTIONAL run the scan with independent tool ....tripwire
Means checking for software intrusions.
CONF file using simple commands
ENABLE_TESTS="all"
DISABLE_TESTS="none"
SCAN_MODE_DEV=THOROUGH
The CLI manual scan does not mention Tripwire by name but the logfile shows
[09:31:39] Checking for software intrusions [ None found ]
This log will of course change if you had intrusions detected by Tripwire.
OPTIONAL run the scan with independent tool ....skdet
Means Performing Suckit Rookit additional checks
Command skdet may not be available anymore at public download sites?
If you have it, copy the executable to a pathway similar to unhide eg /usr/local/sbin
run it to test it works
[root@localhost gordy]# skdet -c
1 init
2 migration/0
3 ksoftirqd/0
4 events/0
5 khelper
.....list culled you get the idea.
http://www.filehigh.com/viewimg.php?f=30814&i=446217
Now run RKH with all tests similar to unhide the shell gives no mention of skdet as such here
http://www.filehigh.com/viewimg.php?f=30814&i=446216
but the logfile is more informative
[20:52:45] Performing Suckit Rookit additional checks
[20:52:45] Checking /sbin/init link count [ OK ]
[20:52:45] Checking for hidden file extensions [ None found ]
[20:52:45] Running skdet command [ OK ]
[20:52:45] Suckit Rookit additional checks [ OK ]
This page is available under a