Uninstall xinetd package if not used by network services
Ensures the legacy xinetd super-server package is not installed when no service requires it.
Checked against what is installed or registered, packages present/absent, account databases.
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 ports and launches network daemons on demand. It is largely obsolete, replaced by systemd socket activation, and is mostly used today to wrap old, insecure services (telnet, rsh, tftp). Keeping it installed decreases nothing and increases the risk of accidentally or intentionally exposing those legacy services. Removing the package eliminates that risk and shrinks the attack surface.
What Pavois checks
Pavois queries the package database via the InSpec package('xinetd') resource (rpm -q / dpkg -s). Checking the package guarantees the super-server cannot be reactivated to launch wrapped legacy daemons; if the package is gone, no xinetd-managed service can be brought up.
describe package('xinetd') do
it { should_not be_installed }
endHow to verify it is applied
On RHEL-family: rpm -q xinetd → package xinetd is not installed. On Debian/Ubuntu: dpkg -s xinetd → dpkg-query: package 'xinetd' is not installed.
Inspect & investigate
- Package state:
rpm -q xinetd/dpkg -s xinetd; removal in/var/log/dnf.rpm.logor/var/log/dpkg.log. - Past super-server activity (before removal):
journalctl -u xinetd.
Remediation
Pavois's harden plan declares a package resource for xinetd with action remove, so pavois harden apply uninstalls it (dnf remove xinetd / apt-get purge xinetd). Removing the package also removes the xinetd unit, so no restart is needed.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | remove |
|---|---|
| name | xinetd |
| resource | package |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If xinetd stays installed, any legacy service configured under /etc/xinetd.d/ can be (re)exposed on the network. Before applying: as the title warns, confirm no service is actually launched by xinetd, inspect /etc/xinetd.d/ for enabled entries and ss -lntp for ports xinetd is bound to. If a needed service still relies on it, migrate it to a native systemd unit or socket activation first, then remove the package. Removal does not affect SSH, so there is no remote-management lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R62 | direct | 2.0 | high |
| CIS | 2.1.19, 2.2.4, 2.1.20 | direct | per OS, see the benchmark table | high |
| NIST | CM-6(a), CM-7(a), CM-7(b) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.4 | supporting | 4.0.1 | 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.