Detections
Analytics

3.2.7 Ensure unneeded network protocol kernel modules are not available

Information

The Linux kernel ships dozens of network-protocol implementations as loadable modules under kernel/net/ (e.g., esp4, esp6, rxrpc, sctp, dccp, rds, tipc, appletalk, decnet, ipx, x25, rose, ax25, netrom, econet, llc, llc2, and many others). On a default installation most of these modules are available but not loaded - present on disk under /lib/modules/$(uname -r)/kernel/net/, autoloadable on demand by modprobe, by socket-family registration ( AF_* socket calls), or by traffic arriving on an interface that requests the protocol.

This recommendation establishes a site-maintained allow-list / deny-list policy for network-protocol kernel modules: the operator enumerates every network-protocol module the site does not need and ensures each is blacklisted and bound to /bin/false (or /bin/true ) via /etc/modprobe.d/, so the kernel will refuse to autoload or manually load them.

This rule is the catch-all framework that complements the per-protocol recommendations elsewhere in subsection 3.2 Configure Network Kernel Modules.

 - The set of "unneeded" network-protocol modules differs materially between deployments (e.g., a site using IPsec needs esp4 / esp6 loaded; an AFS-using site needs rxrpc ; most sites need neither).
 - New network-protocol modules and new vulnerabilities in existing modules are disclosed continuously, and a hard-coded list in a CIS recommendation cannot keep pace with the kernel's release cadence or with public vulnerability disclosure.
 - A site that has already inventoried its required network protocols can apply this framework immediately when a new vulnerability is published, without waiting for a benchmark revision.

Worked example (illustrative, not normative): On May 7, 2026 Canonical disclosed the "Dirty Frag" local privilege escalation class - CVE-2026-43284 in the esp4 / esp6 modules (IPsec ESP fragmentation handling) and CVE-2026-43500 in the rxrpc module (Andrew File System RPC) - affecting all Ubuntu LTS releases from 14.04 through 26.04. A site that did not use IPsec or AFS could mitigate both CVEs immediately by adding esp4, esp6, and rxrpc to its /etc/modprobe.d/ deny list - exactly the workflow this recommendation institutionalises. A site that did use IPsec or AFS would scope those modules out of its deny list and accept the standard patching cycle for them instead.

This recommendation does not prescribe a specific list of modules. It prescribes the discipline of maintaining and enforcing one.

Every loadable network-protocol kernel module is a piece of code that can be reached by an unprivileged local user (via socket(AF_FAMILY, ...) for protocols mapped to a socket family, via ip link add type <kind> for some encapsulation modules, or via autoload triggers from received traffic). The protocol code typically runs in the kernel at the highest privilege level. A memory-safety bug, integer-overflow, or fragmentation-reassembly defect anywhere in this code is exploitable for local privilege escalation or, in some cases, remote denial-of-service or remote code execution.

The 2026 "Dirty Frag" disclosure is one example of this class - local unprivileged users on Ubuntu LTS systems could elevate to root by exercising vulnerable ESP fragmentation handling in esp4 / esp6 (CVE-2026-43284, CVSS 8.8) or AFS RPC processing in rxrpc (CVE-2026-43500, CVSS 7.8). Container escapes were also plausible because both modules expose attack surface to unprivileged user namespaces. Similar disclosures have historically affected dccp, sctp, rds, tipc, vsock, kcm, phonet, and others; the cadence is sustained.

Sites that have not pre-emptively disabled modules they don't use are forced into reactive patching every time such a disclosure lands - accepting a window of exposure between disclosure and patch-deployment. Sites that maintain an explicit, enforced deny list under /etc/modprobe.d/ close the attack surface in advance, so any newly disclosed vulnerability in a module they have already disabled has zero impact on them.

This is the same defence-in-depth posture taken by recommendations 3.2.1 through 3.2.6, generalised to give site administrators a documented, auditable workflow for protocols not individually called out by the benchmark.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

- Produce a site inventory of required network-protocol kernel modules. List each kernel/net/* module currently shipped with the running kernel and tag each as required, unneeded, or already covered by 3.2.1-3.2.6.

To enumerate the modules shipped with the running kernel:

# find /lib/modules/"$(uname -r)"/kernel/net -type f -name '*.ko*' -printf '%f\n' | sed -E 's/\.ko(\.[xg]z|\.zst)?$//' | sort -u

 - For each module flagged unneeded, append both an install and a blacklist directive to a single site-managed file under /etc/modprobe.d/ . The conventional filename used by the per-protocol recs in this section is 60-<module>.conf ; the catch-all may be consolidated into a single file (e.g., 60-cis-network-disabled.conf ) or split per-module.

Example, consolidating multiple modules into one file:

# cat > /etc/modprobe.d/60-cis-network-disabled.conf << 'EOF'
# CIS 3.2.7 - site-maintained network-protocol module deny list
# Each entry must be reviewed against the site's required-protocol inventory.

install esp4 /bin/false
blacklist esp4

install esp6 /bin/false
blacklist esp6

install rxrpc /bin/false
blacklist rxrpc

# Add additional unneeded network-protocol modules here.
EOF

 - Unload any of the listed modules that are currently loaded:

# for m in esp4 esp6 rxrpc; do modprobe -r "$m" 2>/dev/null; rmmod "$m" 2>/dev/null; done

 - Regenerate the initramfs so the deny list applies at boot, before any subsystem auto-loads a denied module:

# update-initramfs -u

 -

Confirm the configuration is in effect by re-running the Audit Procedure against each module on the site list.

 -

Record the site list in the configuration-management baseline (Ansible, Puppet, Chef, Salt, or equivalent) so the deny-list file is reproduced on rebuild and so additions are reviewed via the site's change-control process.

Note: install <module> /bin/false is preferred over blacklist alone. blacklist only prevents autoload triggered by alias resolution; an explicit modprobe <module> still succeeds. Pairing blacklist with install <module> /bin/false blocks both autoload and manual load. The per-protocol recs 3.2.1-3.2.6 use the same pattern.

Impact:

Disabling a network-protocol kernel module prevents any process or kernel subsystem from using that protocol. Before adding a module to the site's deny list, the operator must verify that no production workload depends on it. Common dependency examples:

 - esp4 / esp6 - required for IPsec/IKE VPNs (strongSwan, Libreswan, kernel xfrm ). Disabling breaks site-to-site VPNs and ipsec -mode WireGuard interop.
 - rxrpc - required for Andrew File System ( afs ). Disabling breaks AFS clients and any kafs mounts.
 - mptcp - required for Multipath TCP. Disabling reverts MPTCP connections to plain TCP single-path.
 - tcp_bbr / tcp_cubic - congestion-control modules; disabling the active one falls back to compiled-in defaults but may degrade throughput on long-fat-network paths.
 - nf_conntrack_* / nf_nat_* - netfilter helpers for specific protocols ( ftp, sip, pptp, etc.); disabling breaks NAT traversal for those protocols.

Operators must inventory required network protocols before applying the deny list. A reboot is recommended after deny-list changes to confirm no unit fails to start because its required protocol module is now blocked; alternatively, update-initramfs -u followed by service-by-service restart can validate the configuration without rebooting.

The deny-list file under /etc/modprobe.d/ survives package upgrades but is not automatically populated as new vulnerable modules are disclosed - the operator is responsible for reviewing the site's allow/deny inventory on the same cadence as the site's vulnerability-management process.

See Also

https://workbench.cisecurity.org/benchmarks/27798

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, 800-53|CM-7, CSCv7|9.2

Plugin: Unix

Control ID: 4ec14ce8b48781cbea15b00417182ec9862b73e88a9618eaffc7959d69fc595e