Monitoring Linux Systems For Rootkits

Rootkits are considered to be one of the most tricky pieces of malware. Usually they are loaded onto the system by exploiting weaknesses in software. Next phase is being installed and hide as good as possible, to prevent detection. We have a look at a few security measures you can take to prevent this kind of threat.

System Protection


The kernel is the brain of the software system and decides what should be executed by the central processing unit. Any “damage” to this system decreases the integrity of the system and your data. So protecting the kernel against unauthorized modifications is an important step in keeping system secure.


Linux was originally a monolithic kernel, consisting of all functions in one piece of software. Nowadays its flexible, allowing additional functionality to be loaded when required. The downside of this is the chance that malicious people use this to load new kernel module, which in their turn alter how the kernel functions. For example when requesting a process listing, the kernel might leave out specific processes. Rootkits use these kind of tricks to prevent detection and it shows (pun intended).


Next in line are software components and system utilities in particular. Tools like ps, ls, netstat and others are targeted by rootkits, to avoid detection.

Intrusion Detection

While prevention is a good thing, detection is usually even more valuable. After all, if you can’t detect an intrusion, how do you know for sure you are safe? Let’s have a look at a few possibilities to perform malware and intrusion detection.

File Integrity Monitoring

Objective: Monitor changes to files and binaries in particular


File integrity monitoring can be implemented on different levels. Even a small script collecting all hashes could be a start. Better would be the usage of file integrity tools, which can detect changes and perform intrusion detection. Common examples include AIDE, AFICK and Samhain.

If you want to go even a step further, you can use IMA and EVM, which are Linux security modules to do file integrity for all files. When the kernel sees a file which is changed, it refuses to execute the file. This is definitely the maximum level of protection.

Malware Detection Tools

Object: Use proper tooling to detect malware.

Tools like Rootkit Hunter help with detection some forms of rootkits. ClamAV and LMD are other great examples of tools who can search for traces of malware.

Intrusion Prevention

While full system hardening is preferred, we focus on some powerful methods to prevent the biggest threats to break in.

Upgrade the System

Objective: stay up-to-date with software components


Upgrade on a regular basis software components. Also implement a strategy on how to deal with security upgrades in particular. Most Linux distributions have a way to split these security patches, so you can easily focus on those first.


Additionally it is wise to check for a required reboot. Patching is a great first step, but the kernel itself should be reloaded if there is a new version. Sure, we also know uptime is important and your customers don’t like reboots. But there is personal data at stake and usually more important than that tiny window of downtime.

Disable Kernel Modules

Objective: Disable loading of kernel modules, if system does not require it.


Check lsmod output, blacklist modules which are not being used by using the blacklist file. Additionally, disable loading all kernel modules for full protection.

Blacklist Kernel Modules

Create a custom file in /etc/modprobe.d directory, like custom-blacklisted.conf.

For example our output looks like this:

So let’s blacklist these items with:

blacklist e1000
blacklist psmouse
blacklist usbhid
blacklist hid_generic
blacklist lp
blacklist mac_hid
blacklist ppdev
blacklist serio_raw
blacklist i2c_piix4
blacklist joydev
blacklist parport_pc

Surprisingly we still see some show up after rebooting the system.

Some modules are still being loaded, like lp, usbhid and e100. This is due the modules being loaded at boot time. Some are actually needed, although the output looks like the module is being unused. For example e1000 is our network driver.

The lp module on the other hand is not needed, as can be seen by the dmesg output for lp: [ 219.078098] lp: driver loaded but no devices found.

So we should disable this driver from /etc/modules:

Kernel Modules To Be Loaded at boot Time

After adding a hash to the line starting with “lp”, we reboot the system another time. This time it is gone. Due to the blacklist line, services like udev can not load it anymore. However, modprobe still can. So we have to put in another layer of defense: disable loading new kernel modules.

Disabling Loading of Kernel Modules

To disable new modules from being loaded, a kernel setting have to be put in place via the sysctl command. By setting the value for kernel.modules_disabled to 1, no more kernel modules can be loaded.

Linux Kernel Modules Being Disabled With Sysctl Key

As can be seen in the screenshot above, the system refuses to turn on the setting again (even though it displays the value of 0). The great thing of this option is that attackers can’t disable this setting without rebooting the system. To keep things secure, you might want to monitor the system for unauthorized reboots as well.


  1. I don’t know who you wrote this for but you helped a brehtor out.

Leave a Reply

Your email address will not be published / Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.