Disable Cockpit Management Server
Disables and stops the Cockpit web management server to close its remote-login interface on TCP 9090.
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
Cockpit is a web-based management console that provides a form of remote login with full administrative reach over the host, listening on TCP 9090. Any internet-facing or unnecessary management endpoint widens the attack surface and offers another credential-attack and exploitation target. If remote web administration is not explicitly required, the service should be disabled.
What Pavois checks
Pavois queries systemd for the effective state of cockpit.service (systemctl is-enabled / is-active). Cockpit is typically socket-activated, so a config-file scan would miss that cockpit.socket can spin the service up on demand, the live systemd state is what reveals whether the management endpoint is reachable.
describe service('cockpit.service') do
it { should_not be_enabled }
it { should_not be_running }
endHow to verify it is applied
Confirm the service and its socket are off:
systemctl is-enabled cockpit.service cockpit.socket
systemctl is-active cockpit.service cockpit.socket
Expect disabled/masked and inactive. Confirm nothing listens on 9090: ss -lntp | grep 9090 should return nothing.
Inspect & investigate
Inspect the unit with systemctl status cockpit.service and journalctl -u cockpit. Web-login attempts and sessions also appear in the journal and in PAM/auth logs. Confirm the listening socket is gone with ss -lntp 'sport = :9090'.
Remediation
Pavois's harden plan acts on the service resource named cockpit: it runs disable (no start at boot) then stop (not running now). Applied with pavois harden apply. Note: if cockpit.socket is also present, ensure it too is disabled/masked to fully close the endpoint.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | disable, stop |
|---|---|
| name | cockpit |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration risk: an exposed Cockpit endpoint is a remote-administration and credential-attack target. Precautions: if administrators currently manage this host through the Cockpit web UI, disabling it removes that access path, ensure SSH or another management channel is working first so you do not lose remote administration. There is no impact on running services or non-Cockpit logins.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.1.3 | direct | per OS, see the benchmark table | high |
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.