Disable telnet Service
Ensures the cleartext telnet.service is disabled and not running so no insecure telnet listener is 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
The telnet protocol carries all traffic, including usernames and passwords, in cleartext. Any party able to observe the network (a switch span port, a compromised hop, a Wi-Fi sniffer) can capture login credentials and the full session, and telnet offers no protection against man-in-the-middle tampering. With strongly authenticated, encrypted alternatives (SSH) universally available, an active telnet listener is a high-severity exposure that hands attackers credentials and remote access.
What Pavois checks
Pavois reads the effective unit state via service('telnet.service') (systemctl is-enabled / is-active), so it detects telnet whether started directly or via socket activation, and accounts for drop-in overrides. Checking the running unit beats grepping config files: a telnet listener can be socket-activated or enabled through an override that a file scan of /etc/xinetd.d/ or similar would not flag.
describe service('telnet.socket') do
it { should_not be_enabled }
it { should_not be_running }
endHow to verify it is applied
Run systemctl is-enabled telnet.service (expect disabled, masked, or Unit ... could not be found) and systemctl is-active telnet.service (expect inactive). Confirm nothing is listening on TCP/23 with ss -lntp | grep ':23' (expected: no output).
Inspect & investigate
Telnet activity and unit transitions appear in journalctl -u telnet.service and in the auth log (/var/log/secure on RHEL/Alma). Listening sockets are confirmed with ss -lntp | grep ':23'. After disabling, no new telnet sessions should appear in the auth log.
Remediation
Pavois's harden plan acts on the service resource named telnet: it runs disable (so it does not start at boot) and stop (so it is not running now). It is applied with pavois harden apply. For full elimination, also remove the telnet-server package and any telnet.socket so it cannot be socket-reactivated.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | disable, stop |
|---|---|
| name | telnet.socket |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Disabling telnet removes a remote-access method. The only real risk is on legacy systems where telnet is the sole management path. Precautions: before disabling, confirm SSH is installed, running, and reachable (systemctl is-active sshd and a successful test login) so you do not lose remote access; provide console/out-of-band access as a fallback; and migrate any scripts or appliances that still rely on telnet to an encrypted transport.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | 3.1.13 | 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.