Today I Learned - kernel.modules_disabled

What it is

A DFIR.ch walkthrough demonstrating the Linux kernel.modules_disabled sysctl by building a trivial LKM (dfir.c → dfir.ko), loading it with insmod, then showing that once the flag is set to 1, loading and unloading are blocked until reboot. Motivating context: Mandiant's report on UNC3886, whose toolset included REPTILE, an open-source LKM rootkit that provides backdoor access — the class of threat this setting counters.

How it works

The parameter defaults to 0. Setting it to 1 is a one-way latch for the running kernel session: subsequent insmod and rmmod calls fail with Operation not permitted, including on modules already loaded. You cannot clear the flag at runtime — attempting sysctl -w kernel.modules_disabled=0 returns sysctl: setting key "kernel.modules_disabled": Invalid argument. Only a reboot reverts it.

What to do

Check the current state:

# cat /proc/sys/kernel/modules_disabled
0

Enable it (after confirming every module you need is already loaded):

# echo 1 > /proc/sys/kernel/modules_disabled

The critical operational constraint the page states plainly: ensure all necessary modules are loaded before enabling, because no further module loads are possible afterward and the change cannot be undone without a reboot. For incident responders, the inverse is the useful signal — if modules_disabled = 0 on a host, LKM loading was possible during the window in question; if 1, an attacker could not have inserted a kernel-module rootkit after it was set.

Caveats

• Setting persistence: the post only demonstrates the runtime /proc write, which does not survive reboot. It does not cover making the setting persistent across boots (e.g. via sysctl.conf or systemd), so treat this as a runtime demonstration, not a complete hardening recipe.
• The latch protects only against module-based tampering after it is set; it does nothing about modules already present or other low-level attack paths.