A rootkit is software that is installed on your server with the purpose of hiding the fact that your server has been compromised and providing access to your server so that the intruder can easily return. It is important to understand that in order for an intruder to install a rootkit they will have to have gained the rights to do so on your server. This means that the first line of defense is good security that prevents the installation of a rootkit.
The intruder could use a rootkit to hide the password cracker program that’s stealing your passwords and sending them back to the intruder. The intruder could also use a rootkit to hide a “back door” program that would give him easy access back into the compromised system.
There are at least six basic categories of rootkits which all serve the same purpose. They prevent the intruder’s malicious software from showing screen output to the unsuspecting user, and they prevent the malicious software from leaving traces in the system logs. They also prevent the malicious software from showing up in a “ps” or “top” process list.
Firmware rootkits
One of the most difficult rootkits to discover is the firmware rootkit that is placed in the code that exists in the ACPI or PCI cards or your system clock. Firmware rootkits can be installed in any flashable code on your motherboard or any cards that you install. The difficulties here will be that you cannot fix this by reinstalling your operating system or wiping your hard drives.
Virtualized rootkits change a computer’s boot-up sequence so that the rootkits get loaded instead of the operating system. Once the rootkits are running in memory, the original operating system loads and then runs in a virtual machine as a guest operating system. The rootkit can then intercept hardware calls from the original operating system in order to conceal the presence of any malicious software or activity.
Kernel rootkits
When Linux boots up, it loads kernel extensions, or modules. Loadable Kernel Module, or LKM rootkits, can modify these modules to make them do the intruder’s bidding. These are also very difficult to detect. They can subvert any attempt to detect them and can prevent removal. On the other hand, they can be prevented. On a known clean system, just recompile the Linux kernel without support for loadable kernel modules.
Boot Loader rootkits
In this rootkit the boot loader is replaced with a modified boot loader which is used to achieve the goals of the intruder.
Library rootkits
These rootkits work by modifying the operating system’s libraries that provide system calls. They will either patch the library files, hook onto them, or outright replace them.
Application level rootkits
These are sometimes referred to as “traditional” rootkits. That’s because they’re the oldest variety. Application level rootkits replace system utility programs with their own trojaned versions. On Linux, the affected system utilities include login, ls, du, netstat, ifconfig, ps and top. When the unsuspecting user invokes one of these counterfeit utilities, it’ll will do what the user wants done, but in the background, it will also do something for the intruder.
One way to check these utilities is to invoke them with the -/ option switch. If the command works with that switch, it’s an sign that its executable file is infected.
Rootkit Hunter
Rootkit Hunter performs a more comprehensive check than chkrootkit, and takes somewhat longer to run. If your distro’s package repository doesn’t have it, you can download it from the author’s website. The site is: http://rootkit.nl/projects or you can download it from sourceforge.net.
To perform a check of your system, enter:
rkhunter -c
Here is a typical summary which is listed at the end of the check.
System checks summary
=====================
File properties checks…
Files checked: 129
Suspect files: 0
Rootkit checks…
Rootkits checked : 115
Possible rootkits: 0
Applications checks…
Applications checked: 9
Suspect applications: 0
The system checks took: 3 minutes and 1 seconds
All results have been written to the logfile (/var/log/rkhunter.log)
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
To update Rootkit Hunter, enter:
rkhunter –update
If you do a test and it discovers some programs have changed but you are sure that the changes occurred as the result of an upgrade you will want to upgrade those changes with rkhunter so that it does not continually report those as problems. Note that rkhunter will only be able to tell you that changes have occurred not why they have changed, that is your responsibility to find out.
rkhunter –propupd
Run without User Input
In order to run rkhunter as a cron job, or without user input, you must make a few modifications. Other wise, during the course of its scan, it will stop several times and ask the user to press “Enter”. Use the command:
rkhunter –cronjob
Report only Problems
You can run rkhunter so that it will only report problems that it discovers.
rkunter –cronjob –rwo
Email Your Account
You will need to edit two lines to enter your email and check your mail command header setting. This command will work for Sendmail but not Postfix.
MAIL-ON-WARNING=youremail@example.com root@mydomain
MAIL_CMD=mail -s “[rkhunter] Warnings found for ${HOST_NAME}”
If you are using Postfix as the mail server you will want to modify the default line so it looks like this:
MAIL_CMD=/usr/sbin/sendmail
This is the message you will receive is there is a problem.
”Please inspect this machine, because it may be infected.”
False Positives
You may have to uncomment lines in the rkhunter.conf file to allow for some hidden directories. You may also have to enter the lines and issues that are discovered for your system that are false positives. Of course, you will want to verify either that rkhunter discovered these on a new system or that you are sure they do not represent intrusion.
LOGFILE=/var/log/rkhunter.log
If you allow the root user to login using SSH, change this line.
ALLOW_SSH_ROOT_USER=yes
You may need to allow some directories and files to stop the false positives.
#ALLOWHIDDENDIR=/etc/.java
ALLOWHIDDENDIR=/dev/.udev
#ALLOWHIDDENDIR=/dev/.udevdb
#ALLOWHIDDENDIR=/dev/.udev.tdb
ALLOWHIDDENDIR=/dev/.static
ALLOWHIDDENDIR=/dev/.initramfs
#ALLOWHIDDENDIR=/dev/.SRC-unix
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz
ALLOWHIDDENFILE=/usr/bin/.fipscheck.hmac
ALLOWHIDDENFILE=/usr/bin/.ssh.hmac
ALLOWHIDDENFILE=/usr/sbin/.sshd.hmac
SCRIPTWHITELIST=/sbin/ifup
SCRIPTWHITELIST=/sbin/ifdown
SCRIPTWHITELIST=/usr/bin/groups
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/usr/bin/whatis
Enter the applications you want to whitelist. This is a possible list for a CentOS system apache on Ubuntu is called apache2 instead of httpd.
APP_WHITELIST=”httpd sshd PHP named”
Here is an example of the output that you need to fix in order to eliminate false positives.
rkhunter –cronjob –rwo
Warning: Hidden directory found: /dev/.udev
Warning: Hidden file found: /usr/share/man/man1/..1.gz: gzip compressed data, from Unix, max compression
Warning: Hidden file found: /usr/bin/.fipscheck.hmac: ASCII text
Warning: Hidden file found: /usr/bin/.ssh.hmac: ASCII text
Warning: Hidden file found: /usr/sbin/.sshd.hmac: ASCII text
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
Be the first to comment