Disable Bluetooth Service
Disables and stops the bluetooth service to remove the wireless Bluetooth attack surface.
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.
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
The bluetooth service exposes a wireless attack surface: Bluetooth stacks have a history of remote-exploitable vulnerabilities (e.g. BlueBorne), and an active adapter lets nearby attackers attempt pairing, eavesdropping, or device tracking. Servers and most fixed infrastructure have no need for Bluetooth, so disabling the service removes the radio interface and its protocol stack entirely. The risk decision may legitimately vary on endpoints that rely on Bluetooth peripherals.
What Pavois checks
Pavois queries systemd for the effective state of bluetooth.service (systemctl is-enabled / is-active), catching a daemon that is running or socket/dbus-activated regardless of /etc/bluetooth/main.conf. A config-file scan cannot confirm whether the bluetooth stack is actually live and the adapter powered on.
describe service('bluetooth.service') do
it { should_not be_enabled }
it { should_not be_running }
endHow to verify it is applied
Confirm the unit is off:
systemctl is-enabled bluetooth.service
systemctl is-active bluetooth.service
Expect disabled (or masked) and inactive. Confirm no adapter is up with bluetoothctl show (should report no default controller) or rfkill list bluetooth.
Inspect & investigate
Inspect the unit with systemctl status bluetooth.service and journalctl -u bluetooth.service. Adapter and pairing events also surface in the journal; rfkill list bluetooth shows whether the radio is blocked. Package presence: dpkg -s bluez or rpm -q bluez.
Remediation
Pavois's harden plan acts on the service resource named bluetooth: it runs disable (no start at boot) then stop (not running now). Applied with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | disable, stop |
|---|---|
| name | bluetooth |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration risk: an active Bluetooth stack exposes a wireless attack surface to nearby adversaries. Precautions: disabling the service breaks any Bluetooth peripherals in use, keyboards, mice, headsets, audio. On a remotely managed server this is safe, but on a workstation confirm the admin is not relying on a Bluetooth input device (which could effectively lock them out of local console access). There is no impact on SSH or network logins.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 3.1.3 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.16, AC-18(3), AC-18(a), CM-6(a), CM-7(a), CM-7(b), MP-7 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.