CoursesLinux hardeningKernel & filesystem

Kernel module control

Blacklist what you never load.

Advanced10 min · lesson 10 of 16

The Linux kernel loads modules — drivers and features — on demand, and by default it can autoload a wide range of them when a matching device or protocol appears. That flexibility is attack surface: obscure filesystem and network-protocol modules have contained vulnerabilities, and an attacker who can trigger the load of a buggy module can exploit it. Hardening means blacklisting the modules you will never legitimately need so the kernel refuses to load them.

/etc/modprobe.d/blacklist-hardening.conf
# uncommon filesystems no server needs — refuse to load them
install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install udf /bin/true
# obscure network protocols with a history of CVEs
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true

How the blacklist works

The install <module> /bin/true trick tells modprobe that "loading" the module means running /bin/true (which does nothing and succeeds), so the real module never loads even if something requests it. This is more robust than the older blacklist keyword, which only prevents autoloading by alias but still allows explicit modprobe. The CIS benchmarks list exactly which filesystem and protocol modules to disable; the list above is the common core.

Lock module loading down further

On the highest-assurance systems you can go beyond blacklisting to disabling module loading entirely after boot: kernel.modules_disabled = 1 makes the running kernel refuse to load any new module until reboot, so an attacker with root still cannot insert a malicious kernel module (a rootkit). It is a strong control — nothing loads afterward, including things you might legitimately want — so it suits appliances and locked-down hosts more than general servers, but it closes the kernel-module rootkit path completely.

terminal
$ lsmod # what is currently loaded
$ modprobe -n -v dccp # dry-run: would it load? (shows /bin/true if blacklisted)
# the nuclear option (no more module loading until reboot):
$ echo 'kernel.modules_disabled = 1' | sudo tee /etc/sysctl.d/99-lockdown.conf
A malicious kernel module is game over
A kernel module runs with full kernel privileges — a loaded rootkit can hide processes, files, and network connections from every tool you would use to find it, because those tools ask the kernel it now controls. That is why controlling module loading matters: blacklist what you never need, consider disabling loading entirely on locked-down hosts, and treat an unexpected loaded module (lsmod showing something you did not install) as a serious incident indicator.