Using RPM to detect RootKits

Protecting Your Linux System From Rootkits

Auditing the system is very important on your server, especially if it is Internet facing. Even, the simple process, of reading logs will help protect your system from malware and rootkits. Suspicious activity can be caught early on where the logs are monitored. This now leads us into investigating rootkits and how to detect them. A rootkit is simple a collection of tools in the form of programs that a hacker may use to try and mask their attacks or activity on your system. Rootkits are commonly availably on Unix variants inlcluding Linux ,as well as having being ported to Windows with collections such as NTROOT.

Commonly a rootkit will replace binaries such as ls and ps on your system. The idea is that the imported ls command will not list files associated with the rootkit and in the same way the imported ps command will refuse to display and processes that the root kit runs. In this way the activity of the hacker may go undetected.

A simple detection method on Enterprise Linux systems such as CentOS that use RPM packages is to use the command rpm -V. Like many options we may use the choice of -V or –verify option if the long-hand makes more sense. Exected without arguments the command will verify each package.  It would be good the run with this with cron as it will take some time. To veriry the coreutils package that delivers ls and the procps-ng package that delivers ps we can use:

$ rpm -V coreutils procps-ng

We hope for no output stating that the files in use match those in the package inventory. The match is made on the size, date stamp and md5 checksum. So this is not just a simple match against the file size and name. The elements that are checked are listed in the man page for the rpm command but also in the following:

S The file size differs

M The file mode or permissions differ

5 The digest or checksum of the file differs

D The device major or minor number differs

L The read link differs

U The user owner differs

G The group ownership differs

T The last modified time stamp differs

P The file capabilities differ

If we test the the –verify operation against the crontabs package. This inlcudes the /etc/crontab file which has been edited on my system:

$ sudo rpm -V crontabs

S.5....T.  c /etc/crontab

We can see that the Size is different, the MD5 checksum and the Timestamp all differ. The c just marks this as a configuration file which we could expect to differ.

If we choose to send the oput through to a file we can campare the latest results with a baseline taken soon after the installation and configuartion of the server:

$ diff baseline.results recent.results

1a2

> .M.......  c /etc/shadow

The diff command now highlights that in the second file we have a new difference that was not present on the baseline file. The video show a demonstration: