← All rules
SOCLE-CLD-GEN-056// Hardening (misc)mediumeffective runtime

Deactivate Wireless Network Interfaces

Disables all wireless radios (Wi-Fi, etc.) so the host has no active wireless interface, via nmcli radio reporting every radio as off.

Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.

A pass proves✓ running now? on disk? survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 4 standards

Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.

A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.

Why this rule matters

An enabled wireless radio on a server is an uncontrolled network edge. Attackers can stand up a rogue access point and lure the host into a malicious association or ad hoc connection, then run man-in-the-middle interception, traffic capture or denial of service, entirely bypassing the wired perimeter and firewall. On systems that only need wired networking, turning off all radios removes this attack surface completely.

What Pavois checks

Pavois asks NetworkManager for the live radio state with nmcli radio all and passes only when nothing reports enabled. This reflects the actual runtime status of the radios, including ones brought up after boot, which a static check of config files or kernel module blacklists could miss; the running state is what an attacker can reach.

only_if { command('ls -d /sys/class/net/*/wireless 2>/dev/null | grep -q .').exit_status == 0 }
describe command('nmcli radio all 2>/dev/null | grep -qiw enabled && echo ko || echo ok') do
  its('stdout.strip') { should eq 'ok' }
end

How to verify it is applied

Run nmcli radio all. The expected output shows WIFI, WWAN (and others) as disabled/missing, with none enabled. To make it persistent, nmcli radio all off plus blacklisting the wireless kernel modules.

Inspect & investigate

NetworkManager logs radio changes via journalctl -u NetworkManager. The presence and state of wireless devices can be inspected with nmcli device status, rfkill list and ip link; kernel module loads appear in dmesg.

Remediation

No automated harden plan is defined, so this must be applied manually: turn radios off now with nmcli radio all off, and make it durable by blacklisting the wireless drivers (e.g. add install <module> /bin/false entries under /etc/modprobe.d/) so they cannot be reloaded, then verify with nmcli radio all and rfkill list.

Pavois applies this with its own harden engine, the plan below, not a shell script:

commandnmcli radio all 2>/dev/null || rfkill list # nmcli radio all off (or: rfkill block wifi), only on hosts that must not use wireless
reasondisabling wireless can cut connectivity, confirm the host is wired
resourcemanual
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Only apply this on hosts that rely solely on wired networking. On a laptop or any machine whose only connectivity is Wi-Fi, disabling the radios will cut network access, including your remote session, so never run it over the wireless link you depend on. Confirm an active wired path first, and remember the radios may re-enable on reboot unless you also blacklist the modules.

Standards mapping

StandardReferenceTypeVersionConfidence
CIS1.3.3, 3.1.2directper OS, see the benchmark tablehigh
NIST3.1.16, AC-18(3), AC-18(a), CM-6(a), CM-7(a), CM-7(b), MP-7supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS1.3.3supporting4.0.1medium
DISA STIGUBTU-22-291015, UBTU-24-600230directper OS STIG releasehigh

Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.

Sources & references