Disable xinetd Service
Ensures the legacy super-server xinetd.service is disabled and not running so on-demand legacy network services are not exposed.
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
xinetd is a legacy super-server that listens on behalf of other programs and launches them on demand. Modern systems use systemd socket activation instead, so xinetd is rarely necessary. Keeping it running can silently expose obsolete or insecure services configured under /etc/xinetd.d/ (telnet, tftp, rsh, etc.) and adds the xinetd daemon itself as an attack surface. Disabling it enforces least functionality and removes a path to legacy network services.
What Pavois checks
Pavois reads the effective unit state via service('xinetd.service') (systemctl is-enabled / is-active), including drop-in overrides. Because xinetd itself spawns other listeners from /etc/xinetd.d/, confirming the daemon is not running is the only reliable way to know none of those sub-services can be launched, a file scan would have to parse every fragment, while the effective unit state settles it in one check.
describe service('xinetd.service') do
it { should_not be_enabled }
it { should_not be_running }
endHow to verify it is applied
Run systemctl is-enabled xinetd.service (expect disabled/masked/not found) and systemctl is-active xinetd.service (expect inactive). Spot-check that the legacy listeners it would manage are gone with ss -lntu (no unexpected ports for services defined in /etc/xinetd.d/).
Inspect & investigate
Daemon transitions are in journalctl -u xinetd.service; xinetd's own per-connection logging goes to syslog (/var/log/syslog on Debian/Ubuntu, /var/log/messages on RHEL). After disabling, no further xinetd-spawned connections should be logged; confirm listeners with ss -lntu.
Remediation
Pavois's harden plan acts on the service resource named xinetd: it runs disable and stop so the super-server does not start at boot and is stopped now, which also prevents any sub-service in /etc/xinetd.d/ from being launched. It is applied with pavois harden apply. If no legacy service needs it, remove the xinetd package to eliminate it entirely.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | disable, stop |
|---|---|
| name | xinetd |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Disabling xinetd stops every service it manages at once, so any legacy daemon still wired through /etc/xinetd.d/ (e.g. a custom or appliance service) goes offline. Precautions: review /etc/xinetd.d/ for active entries (disable = no) before applying; migrate anything still needed to a native systemd socket/service unit; and confirm no monitoring or integration depends on an xinetd-launched listener.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.1.19 | direct | per OS, see the benchmark table | high |
| NIST | CM-7(a), CM-7(b), CM-6(a), 3.4.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.