[wiki:#Contents]

[wiki:SPRKH#Introduction Introduction] br [wiki:SPRKH#Flowchart Flowchart] br [wiki:SPRKH#Faq FAQ, Readme and new configuration files-Preview and Download] br [wiki:"SPRKH#Download Tarball" Download Tarball] br [wiki:"SPRKH#Clean Install" Clean Install] br [wiki:"SPRKH#Install Rootkit Hunter executable" Install Rootkit Hunter executable] br [wiki:"SPRKH#Modify config file" Modify the configuration file called rkhunter.conf] br [wiki:"SPRKH#Commands --propupd and --update" Commands --propupd and --update] br [wiki:"SPRKH#First Scan" First Scan] br [wiki:"SPRKH#Check Log and modify CONF" Check Log and modify CONF] br [wiki:"SPRKH#Abnormal Activity" Abnormal Activity ] br [wiki:"SPRKH#Regular System Activity" Regular System Activity] br [wiki:"SPRKH#Software Modified" Software Modified ] br [wiki:"SPRKH#Scan - Manual or Automatic" Scan - Manual or Automatic] br [wiki:"SPRKH#Check Log" Check Log] br [wiki:SPRKH#Investigate Investigate] br [wiki:"SPRKH#Intrusion Procedure" Intrusion Procedure ] br [wiki:SPRKH#Validate Validate] br [wiki:"SPRKH#Second Opinion" Second Opinion] br [wiki:"SPRKH#Run --propupd and or modify CONF" Run --propupd and or modify CONF] br [wiki:"SPRKH#Examples of commands with no changed CONF" Examples of commands with no changed CONF] br [wiki:"SPRKH#Mail Deletion" Mail Deletion] br [wiki:"SPRKH#Remove an installed RKH" Remove an installed RKH] br [wiki:"SPRKH#Run Manual Tests" Run Manual Tests] br [wiki:SPRKH#Licensing Licensing] br [wiki:"SPRKH#Credits and Contact" Credits and Contact]

[wiki:#Introduction]

Introduction

Rootkit Hunter (commonly abbreviated as "RKH") is a security monitoring and analyzing tool for POSIX compliant systems, to help you detect known rootkits, malware and signal general bad security practices. Rootkits have a certain structure and files in certain areas, known to the Rootkit Hunter team. This is similar to virus signatures. RKH offers additional scans that may assist you.

One of the features RKH offers is a scan for changed file properties similar to some criteria that file integrity checkers use. It is completely dependent on ensuring you have a correct database to scan from. In general this can be achieved by installing Rootkit Hunter right after a clean Operating System installation.

Rootkit Hunter is not a reactive tool: it only enumerates encountered threats. It is up to you to read the log file and investigate suspicious activity.

The RKH team includes documentation with each release (which you can also find on-line). In addition this Wiki offers limited suggestions. Another source of information is the rkhunter-users mailing list archive. If you can not find a solution to your problem in those sources of information, would like to suggest improvements or would like to discuss a breach of security you are invited to join the rkhunter-users mailing list. If you would like to submit a patch you can also use our Sourceforge bug tracker.

br

The RKH configuration file has a number of options. The most important ones are discussed below. You can also run

{{{ man rkhunter }}}

for other options.

Remarks br CONF (the RKH configuration file) refers to /etc/rkhunter.conf, /usr/local/etc/rkhunter.conf or where you installed it if you chose a non-standard location.

Commands can be copied and pasted into your shell. Please be aware you need to change the path and your login name as appropriate. Konsole users can use pull down menu and select paste. My home folder is /home/gordy.....change my commands to suit. RKH uses US spelling in commands while I use Australian spelling elsewhere.

Disclaimer br I am not a part of the RKH develpoment team but the prime RKH Wiki editor and a RKH home user. My documentation and suggestions have been verified by the Rkhunter team. I accept no blame for any of this Wiki text I wrote. Please use independent advice if you have any concerns or refer to the intrusion procedures.

[wiki:#Flowchart]

Flowchart

Image(MiscWikiFiles:flowchart.png, align=center)

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:#Faq]

FAQ, Readme and new configuration files-Preview and Download

The tarball link (in next section), is dated 27Feb2008. However, John and the mailing list recommend that you use the more up-to-date FAQ, Readme and I suggest the config file as well. You may like to preview them before downloading them.

The idea is store these on removable media and replace them after you have done the clean install...and installed the executable.

Here is the main reason: br The MAIL-ON-WARNING option must now exist in the config file. This avoids the problem of it being misspelt and rkhunter then not alerting the user to any warnings. RKH will continue if it is not present, but alerts the user and sets the return code.

TIP In my browser, if I click on download in the preview page....the text appears in the browser. If that happens to you, I suggest you (for a right hander) right hand click and use the context menu to save link as.....from the relevant page.

FAQ

Preview or download from br http://rkhunter.cvs.sourceforge.net/rkhunter/rkhunter/files/FAQ?view=log

Readme

Preview or download from br http://rkhunter.cvs.sourceforge.net/rkhunter/rkhunter/files/README?view=log

New Conf file

Preview or download from br http://rkhunter.cvs.sourceforge.net/rkhunter/rkhunter/files/rkhunter.conf?view=log

[wiki:"#Download Tarball"]

Download Tarball

Download tarball (source.gz) br Click on the Download link or copy to your web browser to get the stable edition.

http://sourceforge.net/projects/rkhunter/

Store on removable media br Copy the unpack folder onto an USB or floppy or cd. br Consider downloading and saving suggested helper applications like unhide and skdet as well please.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Clean Install"]

Clean Install

RKH and other scanning tools work best on a clean install. The propupd command can only be trusted on a clean install. However, a scan on an existing install will still reveal rootkits.

[wiki:"#Install Rootkit Hunter executable"]

Install Rootkit Hunter executable

Copy the file from your USB (or other media) to /yourname/.

{{{ su (and your password) }}} or change if you use sudo where you have added the local name to the sudoers list {{{ cd /home/gordy/......(if you are not already in your folder) tar zxvf rkhunter-1.3.2.tar.gz cd rkhunter-1.3.2/ sh installer.sh --layout default --install }}}

The following is the output of a successful install. br Checking system for: br Rootkit Hunter installer files: found. OK br Available file retrieval tools: br wget: found. OK br Starting installation/update br Checking PREFIX /usr/local: exists, and is writable. OK br Checking installation directories: br Directory /usr/local/share/doc/rkhunter-1.3.2: creating: OK. br Directory /usr/local/share/man/man8: exists, and is writable. OK br Directory /etc: exists, and is writable. OK br Directory /usr/local/bin: exists, and is writable. OK br Directory /usr/local/lib: exists, and is writable. OK br Directory /var/lib: exists, and is writable. OK br Directory /usr/local/lib/rkhunter/scripts: creating: OK. br Directory /var/lib/rkhunter/db: creating: OK. br Directory /var/lib/rkhunter/tmp: creating: OK. br Directory /var/lib/rkhunter/db/i18n: creating: OK. br Installing check_modules.pl: OK. br Installing check_update.sh: OK. br Installing check_port.pl: OK. br Installing filehashmd5.pl: OK. br Installing filehashsha1.pl: OK. br Installing showfiles.pl: OK. br Installing stat.pl: OK. br Installing readlink.sh: OK. br Installing backdoorports.dat: OK. br Installing mirrors.dat: OK. br Installing os.dat: OK. br Installing programs_bad.dat: OK. br Installing programs_good.dat: OK. br Installing defaulthashes.dat: OK. br Installing md5blacklist.dat: OK. br Installing suspscan.dat: OK. br Installing rkhunter.8: OK. br Installing ACKNOWLEDGMENTS: OK. br Installing CHANGELOG: OK. br Installing FAQ: OK. br Installing LICENSE: OK. br Installing README: OK. br Installing WISHLIST: OK. br Installing language support files: OK. br Installing rkhunter: OK. br Installing rkhunter.conf: OK. br Installation finished

The installer is running the above checks and if you lack a component the installer should report an error. br You can delete file /yourname/rkhunter-1.3.2.tar.gz if you wish as its on your removable media as a backup.

CONF file is under /etc/ br Changelog, FAQ and Readme are under /usr/local/share/doc/rkhunter-1.3.2 br Changelog shows you different things you can do. br FAQ has been greatly expanded and answers all those important questions br Readme has also changed to reflect the emphasis on local verification and external supplied data files. br Now when you do the install, if you feel up to it, please note where the files are installed and replace the FAQ, Readme and CONF files.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Modify config file"]

Modify rkhunter.conf

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. br UID0_ACCOUNTS="toor rooty"

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. br 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. br 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. br Be aware that RKH may need to find more than just the executables in the BINDIR pathway. The log is your guide.

Modify CONF for package manager

Normally enabled prior to your first scan. RKH will scan your package manager data files. br

PKGMGR=NONE ....Change to br

PKGMGR= RPM or DPKG or BSD br No matter which you choose, verify it works, later by reading the top area of your log file. br [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' package manager offers any real benefit 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. br So rkhunter will perform other checks as well to verify that the file has not changed at all. br 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. br 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. br 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. br 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. br Hashes are available either as : br For Solaris 9 : HASH_FUNC=gmd5sum br For Solaris 10: HASH_FUNC=sha1sum br For AIX (>5.2): HASH_FUNC="csum -hMD5" br 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:

 1. HASH_FUNC=sha1sum
 1. 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.
 1. HASH_FLD_IDX=4.

br

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? br 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? br HASH_FUNC="cksum -n -a sha512 br HASH_FLD_IDX=4

e.g. After choosing MD5 CONF option I can verify it worked by this log entry br [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. br When: prior to first scan. br Caveats: suspscan is not and should not be enabled by default because it is CPU and I/O intensive.

ENABLE_TESTS="all" br DISABLE_TESTS="none" br You could always use the named test but I like to keep it simple. br After adding this test to your CONF the log shows: br [21:46:35] Info: Starting test name 'suspscan' br [21:46:35] Directories to check are: /tmp /var/tmp br [21:46:35] Temporary directory to use: /dev/shm br [21:46:35] Maximum file size to check (in bytes): '1024000' br [21:46:35] Score threshold is set to: 300 br [21:46:35] Checking directory: '/tmp' br [21:46:38] File checked: Name: '/tmp/drakx-images/IM_001-FON-UK.png' Score: 0 Hitcount: Hits: () br [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. br 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: br [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 br [08:58:38] Info: SCAN_MODE_DEV set to 'THOROUGH' br [08:58:52] Checking /dev for suspicious file types [ Warning ] br [08:58:52] Warning: Suspicious files found in /dev: br [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. Download unhide from br http://www.security-projects.com/?Unhide:Download br After downloading the 2 Nov 2007 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-02-11-2007 su gcc -Wall -o unhide unhide-linux26.c }}}

In your unpacked unhide folder will appear a new executable...unhide. Do not change its name as RKH needs to detect it under the current name. However, RKH also needs to find it under its bindir pathways, or you have to add your pathway to BINDIR. br Eg /usr/share/doc/sed/unhide. br BINDIR="/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /usr/libexec /usr/local/libexec /usr/share/doc/sed"

It may help to change /etc/rkhunter.conf to rw permissions.

Recommended: test the unhide command

The following code would not display correctly inside the box with the ...&& so the command is outside box

br

unhide proc && unhide sys && unhide brute

The result of above command is this

{{{ Unhide 02-11-2007......(checking proc) yjesus@security-projects.com [*]Searching for Hidden processes through /proc scanning Unhide 02-11-2007 (checking sys) yjesus@security-projects.com [*]Searching for Hidden processes through getpriority() scanning [*]Searching for Hidden processes through getpgid() scanning [*]Searching for Hidden processes through getsid() scanning [*]Searching for Hidden processes through sched_getaffinity() scanning [*]Searching for Hidden processes through sched_getparam() scanning [*]Searching for Hidden processes through sched_getscheduler() scanning [*]Searching for Hidden processes through sched_rr_get_interval() scanning [*]Searching for Hidden processes through sysinfo() scanning Unhide 02-11-2007 (checking brute force) yjesus@security-projects.com [*]Starting scanning using brute force against PIDS }}}

unhide will report if it finds positive results.

Now edit your CONF, I suggest: br ENABLE_TESTS="all" br DISABLE_TESTS="none" br SCAN_MODE_DEV=THOROUGH br [17:29:47] Info: Starting test name 'hidden_procs' br [17:29:58] Checking for hidden processes [ None found ]

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. br Original author's contact was slider <slider@decebal.org>

Download it from here br http://www.xs4all.nl/~dvgevers/

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...... 2 pages of konsole output culled 5991 skdet }}}

Comment...My pc is a KDE system so lots of bloat. There is also skdet -s but netstat -atun appears better.

Now run rkhunter with all tests similar to unhide, logfile excerpt: br [17:29:37] Performing Suckit Rookit additional checks br [17:29:37] Checking /sbin/init link count [ OK ] br [17:29:38] Checking for hidden file extensions [ None found ] br [17:29:38] Running skdet command [ OK ] br [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. br ENABLE_TESTS="all" br DISABLE_TESTS="none" br SCAN_MODE_DEV=THOROUGH

br

The manual scan does not mention Tripwire by name but the logfile shows br [09:31:39] Checking for software intrusions [ None found ] br 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. Recommended for home users. br Here I have disabled all /etc/ssh/config files and the executable, log result: br Performing system configuration file checks br Checking for SSH configuration file [ Not found ]

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Commands --propupd and --update"]

Commands --propupd and --update

PROPUPD

{{{ rkhunter --propupd }}}

Means update your system file properties. This is a necessary step to establish a foundation database file to compare scans. There is another command called --update which is not the same. On a clean install, the first run of propupd, creates a new database file. On later scans, running the propupd command, updates the database file. So, to update the database file, you are satisfied you have only trusted source system file changes. Rkhunter offers choices, in the CONF, in how you verify system file changes. You can use your package manager and other resources to verify changes reported in the log file. Note the RKH team do not maintain an independent properties database for each distro and their various releases. The properties database file is always maintained locally by you.On a default layout, after propupd is run, the file can be found at /var/lib/rkhunter/db/rkhunter.dat

There is a small delay before the command completes the creation of the initial database. You can not do this on a computer that has already been connected to a network already. Clean install is the necessary pre-condition before running propupd. Once the database has been created we can connect internet and run

UPDATE

The update command requires net access. It is highly recommended that no net access is allowed until you have completed the PROPUPD command. So the correct order is propupd and then update commmands.

{{{ rkhunter --update }}}

The update command looks for various data updates. These are not going to modify your properties database. They relate to other data files in a default layout under /var/lib/rkhunter/db/ and are maintained by the RKH team. These updates tend to be infrequent. But on a clean installation, you can expect some updates.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#First Scan"]

First Scan

{{{ rkhunter -c -sk }}}

This is a manual scan. I recommend manual scans initially so you can check the command output as well as the log.

If colours on output are a concern, run {{{ rkhunter -c -sk --nocolors }}}

[wiki:"#Check Log and modify CONF"]

Check Log and modify CONF

Note, even if, on your first scan, you have zero positives in the summary area, if you scroll up in konsole or any other good shell, you may still see warnings.

Modify CONF for hidden files or directories

Highly recommened not to be done prior to first scan. We want to check how good our first scan is, not weaken it. Most distros have hidden files or directories. If logfile shows: br [08:58:53] Checking for hidden files and directories [ Warning ] br [08:58:53] Warning: Hidden directory found: /etc/.java br [08:58:53] Warning: Hidden directory found: /dev/.udev br [08:58:54] Warning: Hidden directory found: /dev/.udevdb

br

Check them out and if ok you can whitelist them in the CONF. Allow the specified hidden directories or files by removing the hash for each verifed file or you may need to add them.

One directory per line (use multiple ALLOWHIDDENDIR lines) br ALLOWHIDDENDIR=/etc/.java br ALLOWHIDDENDIR=/dev/.udev br ALLOWHIDDENDIR=/dev/.udevdb br

ALLOWHIDDENDIR=/dev/.udev.tdb br
ALLOWHIDDENDIR=/dev/.static br
ALLOWHIDDENDIR=/dev/.initramfs br
ALLOWHIDDENDIR=/dev/.SRC-unix

Allow the specified hidden files. #One file per line (use multiple ALLOWHIDDENFILE lines). br

ALLOWHIDDENFILE=/etc/.java br
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz br
ALLOWHIDDENFILE=/etc/.pwd.lock br
ALLOWHIDDENFILE=/etc/.init.state

Modify CONF for bourne shell replacements or other scripts

Must not be done prior to first scan. If log shows bourne shell replacements or other scripts similar to this example: br [08:48:02] /bin/egrep [ Warning ] br [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 CONF to add or uncomment your choices.

Allow the specified commands to be scripts. #One command per line (use multiple SCRIPTWHITELIST lines). br

SCRIPTWHITELIST=/sbin/ifup br
SCRIPTWHITELIST=/sbin/ifdown br
SCRIPTWHITELIST=/usr/bin/groups br

SCRIPTWHITELIST=/bin/egrep

Modify CONF for other sections

Check you log and modify as appropiate. As a guide, with no network and on a clean install, all warnings and positive scan results are false positives.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Abnormal Activity"]

Abnormal Activity

Non-exhaustive list: br -hard drive activity light remaining on after you would expect cron to have finished and you are not running any intensive applications; br -network monitoring shows unusual download or upload activity or your ISP bills for excess bandwith or shaping your bandwith earlier than you expect; br .........file sharing such as torrent clients could be the reason and not intrusion....others may be hitting you or your router or modem....Your ISP counts downloads to your router not to your computer br ........VOIP are downloads and are normally a fragment of your downloads but may increase if you change the codec or become a frequent caller. Again, your ISP counts downloads and anything going down to your router or modem not to your computer. br -umounted floppy or cd or usb ....changes to mounted without your assistance as shown by hardware lights or sounds; br -commands crash eg ls ...ps....; br -log entries show missing time frames or unusual activity; br -computer reboots without your consent;

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Regular System Activity"]

Regular System Activity

Learn to be observant of what is normal behaviour and anything else is abnormal. I recommend if you turn off your computer use anacron to catch missed daily cron jobs. br Look at your hardware and get a feel for what is normal drive and other light activity. You are the best judge for what is normal.

[wiki:"#Software Modified"]

Software Modified

Meaning you have done updates or removed software or installed new software. br It also includes significant modification of config files that change the behaviour of your applications. Especially, internet related activity like ssh, firewall, mail, file sharing, allowing remote access control of your computer.

If new hardware is installed, new drivers may be required so software is changed so it falls to this section as well. br TIP br Run a scan after an update as your syslog or other system logs should still have each package removed, modified or installed. So it is easier to investigate.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Scan - Manual or Automatic"]

Scan - Manual or Automatic

MANUAL

Manual scans are best in the beginning to observe all the warnings and information that RKH scans provide. I recommend running a manual scan after a significant update like a new kernel.

However, manual scans take longer than automatic ones due to the need to show output on the screen and write to the log. br RKH manual scan provide a summary so its the best to read this area first. br File properties checks... br Required commands check failed br Files checked: 120 br Suspect files: 8

Rootkit checks... br Rootkits checked : 109 br Possible rootkits: 0

Applications checks... br Applications checked: 3 br Suspect applications: 0

The system checks took: (time deleted)

All results have been written to the logfile (/var/log/rkhunter.log)

One or more warnings have been found while checking the system. br Please check the log file (/var/log/rkhunter.log)

Those suspect files must be investigated. br However, this log extract was from my first scan....and most were solved by modifying my CONF. br Automatic scans need cron, and if you turn off computer, anacron. I hope home users will think of climate change and turn off computer.

AUTOMATIC

There are 2 main cron jobs we can adopt. br A job added to crontab to run hourly or daily. br A script made executable that sits in /etc/cron.daily br Or you can add a command to your rc.local script that needs a computer to boot daily to execute, so ignored.

There are restrictions on cron depending on the existance of cron.allow or cron.deny files and their contents.

Note crontab jobs are not “catched up” by anacron. So home users can skip this section. All /etc/crontab jobs can only run if computer is on.

Automatic ---using /etc/crontab jobs

My initial /etc/crontab contents were: br SHELL=/bin/bash br PATH=/sbin:/bin:/usr/sbin:/usr/bin br MAILTO=root br home=/ br run-parts 01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly br 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily br 22 4 * * 0 root nice -n 19 run-parts --report /etc/cron.weekly br 42 4 1 * * root nice -n 19 run-parts --report /etc/cron.monthly

Cron is a root process, so my mail goes to root.

Cron tab columns are from left to right: br minutes past the hour from 0 (0 to 59) br hour of the day (0 to 23 using 24 clock eg 23 means 11 pm) br day of the month (1 -31) br month of the year (either 1 to 12 or jan,feb,.....dec) br weekday (either 0 to 6 with 0=sun or sun, mon,...sat)

means every possible permutation in that column. br
/n means every number equal to N for that column.

Lets add some automatic scan commands then discuss. br Assuming you have vi command you could use br vi -e /etc/crontab and when it opens run visual to get to full output. Press i to get into insert mode, type your changes then press the ESCape key to get back to command mode then type commands :wq! ....This writes to file, quits without prompting you. br Another way is to open a shell su to root powers and then run a gui editor like kwrite? br Cron wakes up every minute so, create an entry 2 minutes into the future to test.

Examples:

30 14 * * * root /usr/local/bin/rkhunter --cronjob --update --rwo --nocolors br 0 * * * * root /usr/local/bin/rkhunter --cronjob --update --rwo --nocolors {{{* */4 * * root /usr/local/bin/rkhunter --cronjob --update --rwo --nocolors}}} 40 2 * * * root /usr/local/bin/rkhunter --update -c -sk --nocolors --nocolors {{{* * */1 * root /usr/local/bin/rkhunter--cronjob --update --rwo --nocolors}}}

Notes: br John advises all cron jobs are to be run with --nocolors. br For all rwo crontabs, modify your conf to comment out MAIL-ON-WARNING.

So top line is: br at 30 minutes past 2 pm, every day, execute a RKH scan after updating any stale data files and report warnings only by mail. Mail only produced if warnings found. br Second line is: br at 0 minutes past every hour execute a RKH scan after updating any stale data files and report warnings only by mail. br Third line is: br same as last entry but run every multiple of 4 hour intervals. That is, at 4,8,noon,4pm,8pm, and midnight. br Fourth line is: br at 40 minutes past 2 am execute a RKH scan after updating any stale data files and mail report similar to manual scan results.....a full report. br Last line is: br equal to having a cron.daily script it means every day update stale data files then scan and send a mail only if warnings found.

Note how easy the last line is, but its a trap if you turn off your computer. You have to wait until past midnight the next day to get your next scan. So if you always go to bed early you have no RKH scans! Recommend anacron and use a RKH script in cron.daily if you turn off computer.

Mail for --cronjob --update --rwo --nocolors

Assuming the scan detects a warning or higher, mail is sent to root. As a home user I recommend you install Gkrellm to alert you to new mail.

Image(MiscWikiFiles:gkrellm.png, align=center)

br

.....mail example br Warning:....and the type of warning...... br One or more warnings have been found while checking the system. br Please check the log file (/var/log/rkhunter.log) br You then check the log and investigate.

If there is no warning....the rwo switch means you get no mail.

Mail for --update -c -sk --nocolors --nocolors br You will receive mail even if there are no warnings as its the same scan as our first manual scan. br .....mail ....excerpts: br Subject: Cron <root@gs> /usr/local/bin/rkhunter --update -c -sk --nocolors br And the last line br No warnings were found while checking the system

Now if your mail matches the last line, you could change your crontab to a rwo format. br If you want mail each day then do not convert to rwo cronjob.

--Automatic ---using /etc/cron.daily scripts br These are better for home users as anacron catches up on missed tasks.

Anacron wil catch all missed cron.daily, cron.monthy and cron.yearly scripts. So this time 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily is rarely achieved by crontab but is “catched up” by anacron.

Create a cron.daily script br Copy and paste the following into a text editor. Please do not include the lines, they are just a signal of the start and end of text.

br

!/bin/sh

{{{( /usr/local/bin/rkhunter --cronjob --rwo --nocolors && echo "" ) \}}} | /bin/mail -s "Rkhunter daily run on {{{`}}}uname -n{{{`}}}" root

exit 0 br

Then using root powers save the file as /etc/cron.daily/rkh and then change its properties to make it executable. Konqueror is easy to use but if you prefer commands, with root powers, run br chmod 700 /etc/cron.daily/rkh br If successful, the permissions appear as

Image(MiscWikiFiles:cron.png, align=center)

br

If you prefer a replacement for manual scan, add -c -sk to the script. br Reboot for a full test or run with ROOT powers {{{ /etc/cron.daily/rkh }}}

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Check Log"]

Check Log

You are checking either because you received a warning, or for a manual scan, you are not sure of something. The end of the log is the ideal place to check first. If you failed to tweak your conf during the top 2 rows of flowchart, you may have missed certain “not found” messages or 'skipped” and so on. All rootkit checks should read [none found or not found]. But the only way you are going to tell if an extra scan was used by RKH, is to check the log.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:#Investigate]

Investigate

After propupd had been run, new executables installed will be detected by the property checking feature of RKH.

Eg On a later scan, when I was testing a new unhide executable the log showed: br Warning: The file '/bin/unhide' exists on the system, but it is not present in the rkhunter.dat file. br I knew what I was doing, so I did not have to investigate this warning. br You may experiment with software, so as long as you know where the software is installing, you can ignore certain warnings.

Investigate includes running mail again and checking for any reports your distro may be mailing to you.

Sometimes we forget what the scan was using in the conf, so before getting nervous, re-check what your conf is scanning for. Then go to the bottom of the log and for each warning.....check what your intention was in the conf. It may sound simple, but home users may enable all tests and wonder why they are getting warnings for RKH reporting it can not find something.

[23:54:42] Info: Check skipped - tripwire not installed br This was harder to investigate. First we need the executable tripwire to be in the conf in BINDIR. Next, I opened the rkhunter executable with a text editor in read mode and searched for tripwire and it wanted tripwire database file under /var/lib/tripwire/. So I created a folder /var/lib/tripwire and a symbolic link from my /opt/tripwire/lib/tripwire/gs.net.twd to /var/lib/tripwire/ and a new scan gave br [09:31:39] Checking for software intrusions [ None found ] br This may change if tripwire reports violations.

[14:57:33] Info: Unable to find the 'skdet' command br Again, RKH needs to find executables in the pathway in BINDIR.

The options open to you when investigating are: br a) br scan result is false positive due to you making an authorised change to software, mainly by updating or re-configuring. Your package manager and your /var/log/syslog and other such logs are your friends in this decision. br Action.....validation achieved, run propupd.

b) br scan result especially for a rootkit, is positive. Meaning intrusion has occurred. br Again, you know that software detected as being installed, is not a dependency required during normal software updates or authorised software installs and you have referred to your package manager and /var/logs for assistance.

c) br After checking various logs you are undecided what action to take. br Action.....save logs on removable media, refer to FAQ and README and post to mailing list for second opinion. This section of howto concerns itself with checking to see if deleted files are false postives or need futher investigation. Your outputs will differ if you are using a different distro and different gui apps.

A) Detect the deleted files...find in your /var/log/rkhunter.log or run a quick scan just for this function br rkhunter --enable 'deleted_files'

This produces (hopefully) a small log.....from the log you may get something like

[17:01:28] Warning: The following processes are using deleted files: br [17:01:28] Process: /usr/bin/python PID: 4333 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4392 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4394 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4397 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4398 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4402 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4404 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4412 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/bin/python PID: 4414 File: /tmp/init.yIg6Jl br [17:01:28] Process: /usr/lib/gconfd-2 PID: 4561 File: br /tmp/gconfd-gordy/lock/0t1209283676ut890097u500p4561r659025555k3213016184

B) Find the fd/number

The log supplies the PID so one check is run br ls -al /proc/PID/fd br where you replace PID with the relevant number from the log.

Image(MiscWikiFiles:proc.png, align=center)

br

We are interested in the lines showing (deleted) so files of interest are: br /proc/4050/fd/1 br /proc/4050/fd/2

Then repeat the action to find the other deleted file ....files of interest.

C) Investigate files of interest in userland

You can now copy files of interest to a non-tmp folder eg /home/yourname/Documents br cp /proc/4050/fd/1 /home/gordy/Documents/4050a

Here I have chosen to call it 4050a as there will be a b from the same PID. You can use a root power text editor on it if you like.

Now run file on it and then try various tools to scan or investigate it.(eg) {{{ file /home/gordy/Documents/4050a }}}

That gave ascii text so I was able to run strings on it which shows "Starting mailman". Naturally for you, your senses may be heightened if the service...mailman ..was disabled by you but if you know you run it....this is a false positive. br strings /home/gordy/Documents/4050a

D) Utilities or tools to try on these home file include: {{{ file strings ldd objdump

(with relevant filename etc) }}}

Anti-virus scan or br running it in a Virtual machine if it's some binary. (I prefer virtualbox)

unSpawn cautions no executable should be attempted to tested on a production machine or host computer including home computers, which is why he is recommending you run it in a virtual machine.

Lets leap to the local tmp one. {{{ ls -al /proc/4561/fd }}}

gives only one deleted line

l-wx 1 gordy gordy 64 2008-04-27 17:01 13 -> /tmp/gconfd-gordy/lock/0t1209283676ut890097u500p4561r659025555k3213016184 (deleted)

But we have a link file so we check /tmp/gconfd-gordy/lock/ and a differnt lock file there gives br 4561:IOR:010000001600000049444c3a436f6e666967536572766572323a312e30000000030000000054424f600000000101020005000000554e4958 br 000000000a0000006c6f63616c686f7374000000350000002f686f6d652f676f7264792f746d702f6f726269742d676f7264792f6c696e632d313164312d br 302d6137633562633064376539370000000000000000caaedfba6000000001010200350000002f686f6d652f676f7264792f746d702f6f726269742d676 br f7264792f6c696e632d313164312d302d613763356263306437653937000000001c000000000000006ea6341089d9e8a8dc29282828282828010000000 br 9a7ff4f01000000480000000100000002000000050000001c000000000000006ea6341089d9e8a8dc292828282828280100000009a7ff4f0100000014000 br 0000100000001000105000000000901010000000000

/proc/4561/fd/13 is our file of interest...file says its a ascii...and its output matches the current lock file br 4561:IOR:010000001600000049444c3a436f6e666967536572766572323a312e30000000030000000054424f600000000101020005000000554e4958 br 000000000a0000006c6f63616c686f7374000000350000002f686f6d652f676f7264792f746d702f6f726269742d676f7264792f6c696e632d313164312d br 302d6137633562633064376539370000000000000000caaedfba6000000001010200350000002f686f6d652f676f7264792f746d702f6f726269742d676 br f7264792f6c696e632d313164312d302d613763356263306437653937000000001c000000000000006ea6341089d9e8a8dc29282828282828010000000 br 9a7ff4f01000000480000000100000002000000050000001c000000000000006ea6341089d9e8a8dc292828282828280100000009a7ff4f0100000014000 br 0000100000001000105000000000901010000000000

Now the mtime of that current tmp (not deleted) file is 16:07 hours so we check our logs to see what we were doing then? br Well the kernel was still booting and did not finish until after 16:08 so another false positive.

Looking at the pathway it has gconfd...= gconf daemon and that is a gnome configuration database application.

Examples of some other checks

{{{ file /home/gordy/Documents/4414a

strings /home/gordy/Documents/4414a

ldd /home/gordy/Documents/4414a

objdump -s /home/gordy/Documents/4414a }}}

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Intrusion Procedure"]

Intrusion Procedure

From the FAQ....Rootkit Hunter tells me there is something wrong with my system. What do I do?

Prior to any incident it is recommended that you have read "Intruder Detection Checklist". This is available from

http://www.cert.org/tech_tips/intruder_detection_checklist.html

This document will tell you what to check, and makes it easier for you to find out and answer any questions.

If you are unsure as to whether your system is compromised, you can get a second opinion from sources such as the rkhunter-users mailing list, the Linux-oriented forum !LinuxQuestions.org, or even IRC. Please note you need to subscribe before posting to the rkhunter-users mailing list.

If a file property check fails, then it is possible you have what is called a 'false positive'. Sometimes this will happen due to package updates, customised configurations or changed binaries. If so, then please check further:

1. If you run a file integrity checker, for example Aide, Samhain, or tripwire, consult the results from running those tools. Note they must be installed directly after the O/S installation in order to be useful, and you must keep a copy of the binary, configuration files and databases off-site. br Also note that running those tools, and Rootkit Hunter, is no substitute for updating software when updates are released, and proper host and network hardening.

2. If you don't run a file integrity checker you can possibly use your distributions package management system if it is configured to deal with verification.

3. Run 'strings <file>' and check the results for untrusted file paths (for example, /dev/.hiddendir).

4. Check recently updated binaries and their original source.

5. Run 'file <file>' and compare the results with other files, especially trusted binaries. If some binaries are statically linked and others are all dynamic, then they could have been trojaned.

6. If you have a warning from another part of the checks, then please subscribe first and then email the rkhunter-users mailing list and tell us about your system configuration: br the purpose of the server (for example, web server, intranet fileserver, shell server); br the (aproximate) date of the incident and when you found out; br the running distribution name, release and kernel version; br whether any passwd/shadow file data has changed; br any anomalies you find from reading the system, daemon, IDS and firewall logs; br if all the installed software was recently updated; br what services are or were running at the time; br if you found setuid root files in directories for temporary files; br any anomalies you find from reading user shell histories.

7. If your system is infected with a rootkit, cleaning it up is not an option. Restoring is also not an option unless you are skilled, and have autonomous and an independent means of verifying that the backup is clean, and does not contain misconfigured or stale software. Never trust a compromised machine. Period.

Read "Steps for Recovering from a UNIX or NT System Compromise". This is available from

http://www.cert.org/tech_tips/root_compromise.html

A clean install of the system is recommended after backing up the full system. To do this follow these steps:

1. Stay calm. Be methodical.

2. From another machine inform users, and the network,facility or host owner, that the machine is compromised.

3. Get the host offline or make sure the firewall is raised to only allow network traffic to and from your management IP address or range.

4. Backup your data. If you do not intend to investigate the problem, then do not backup any binaries or binary data which you cannot verify.

5. Verify the integrity of your backup by visual inspection (authentication data, configurations, log files), or by using a file integrity checker or your distributions package management tools.

6. Install your host with a fresh install. Whilst you are updating and configuring the software and services,restrict network access to the system using authentication fatures like accounts, PAM, firewall, TCP wrappers, and daemon configurations. Make sure you properly harden the machine.

7. Investigate the old log files, and the tools used if possible. Also investigate the services which were vulnerable at the time of attack.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:#Validate]

Validate

If a warning, suspect application, changed property etc is reported in the log it could be a false positive. If you can verify they are false positives, then you have validated the detections found in the log and can then run propupd to eliminate further false positives in future scans.

[wiki:"#Second Opinion"]

Second Opinion

There are detailed helpful tips on what to do in the README. they include : br Check the FAQ, CHANGELOG, mail archives br Check if a bug or support request has already been lodged here http://sourceforge.net/tracker/?group_id=155034) br 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 br Checking for similar reports by others using a search engine like google. br FINALLY send an email if all else fails.

[wiki:"#Run --propupd and or modify CONF"]

Run --propupd and or modify CONF

Run rkhunter --propupd if and only if, you have validated or confirmed all positive results are false positives. That is, they are all authorised or legit. br Either you have discovered this fact or a second opinion has.

When adding a new range of software, or changing the way you use the internet or making significant re-configuration of existing software, you may wish to modify the CONF.

End of flowchart ......Non-essential but maybe relevant information below

[wiki:"#Examples of commands with no changed CONF"]

Examples of commands with no changed CONF

{{{ rkhunter --update -c -sk --pkgmgr RPM

rkhunter -c -sk --debug

rkhunter -c -sk --configfile /media/disk/RKH/date/rkhunter.conf

rkhunter --list tests

rkhunter --enable "all” }}}

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Mail Deletion"]

Mail Deletion

If you wish to delete mail, you need to su or sudo to root powers to delete the mail. {{{ (root@gs gordy)#mail }}} output is {{{ [root@gs gordy]# mail Heirloom mailx version 12.3 67/25/08. Type ? for help. "/var/spool/mail/gordy": 3 messages >O 1 root Wed Jun 25 07:59 33/2173 [msec] *** Diff Check on

O  2 root               Wed Jun 25 07:59  104/4175  [msec] *** Security Check
O  3 root               Wed Jun 25 08:19   94/6291  Rkhunter daily run on gs.

? }}} Then to delete use these commands {{{ ? d1 ? d2 ? d3 ? q }}} The d with the number is short for delete mail message number X........The q stands for quit mail.

Please use the shell to delete mail rather than attempt to cull the mail with the text reader via /var/mail or where ever your mail is.

[wiki:"#Remove an installed RKH"]

Remove an installed RKH

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 rkhunter. Note some files may remain as per this output br sh installer.sh --layout default --remove br Starting uninstallation br Checking PREFIX /usr/local: exists, and is writable. OK br Removing installation files: br Removing rkhunter.8: OK. br Removing /usr/local/bin/rkhunter: OK. br Removing /etc/rkhunter.conf: OK. br Please remove any /etc/rkhunter.conf.* files manually. br Removing installation directories: br Removing /usr/local/lib/rkhunter: OK. br Removing /usr/local/share/doc/rkhunter-1.3.0: OK. br Removing /var/lib/rkhunter: OK. br Done removing files. Please double-check.

If you chose an non-standard (custom) layout install, it increases the chance the uninstall script will fail to remove files or folders.

br

[wiki:SPRKH#Contents Back to Contents] br [wiki:"#Run Manual Tests"]

Run Manual Tests

After reading your logs, you may decide to run a limited scan for one or more features that concern you.

To see the range of tests availble run {{{ rkhunter --list tests }}}

Select the testname(s) and replace the word testname in the following command, if you have more than one test separate with a comma please.

{{{ rkhunter --enable 'testname' }}}

I normally get daily reports showing deleted files. If I re-run this test, be aware that my new log is very short and my main log will be the old scan. {{{ rkhunter --enable 'deleted_files' }}}

Another normal test I run sometimes is {{{ rkhunter --enable 'filesystem' }}}

This I run, sometimes after using the net to check if any hidden file has just been created. But assumes you have whitelisted certain verified hidden folders (directories) and files.

[wiki:#Licensing]

Licensing

!RootKit Hunter is licensed under the GPL, copyright Michael Boelen. See the LICENSE file for details of GPL licensing. Commercial users who wish to reprint any part of the file, I gift all of my rights to the Rootkit Hunter team at sourceforge.net.

[wiki:"#Credits and Contact"]

Credits and Contact

Flowchart designed by unSpawn.

Dick Gevers for re-hosting skdet tool.

crontab */ was mentioned by Jon at www.newlinuxuser.com br . br Author aus9. I am responsible but accept no liability as per disclaimer for all mistakes etc in this wiki. If you have any issues please mail me br aus9 - at -users -dot - sourceforge - dot - net....(join the strings and change the dots please)

New admin for RKH are unSpawn and John Horne.

They and the mailing list users have provided fantastic assistance to my questions.

br

[wiki:SPRKH#Contents Back to Contents]

Referensi

Pranala Menarik

Keamanan Jaringan

RKHunter: Tutorial

CONTENTS