Uninstall avahi Server Package
Ensures the avahi-daemon (Bonjour/mDNS zero-configuration service discovery) package is not installed.
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
avahi-daemon advertises and discovers services on the local network via mDNS/DNS-SD, continuously broadcasting host information and listening on UDP/5353. Servers rarely need automatic service discovery, and the daemon has a history of remotely exploitable vulnerabilities. Removing it reduces the network attack surface and stops unnecessary broadcast traffic (CIS 2.1.2, NIST CM-7 least functionality).
What Pavois checks
Pavois asks dpkg (via the InSpec package resource) whether avahi-daemon is installed and expects it absent. Checking the effective package state catches the service even if its unit was masked but the binary left installed.
describe package('avahi-daemon') do
it { should_not be_installed }
endHow to verify it is applied
Run dpkg -s avahi-daemon, expected package 'avahi-daemon' is not installed. Confirm nothing listens on mDNS with ss -lunp | grep 5353 (expected no output).
Inspect & investigate
dpkg -l avahi-daemonconfirms removal.- While installed, the daemon logs to
journalctl -u avahi-daemon; its listening socket is visible withss -lunp(UDP/5353).
Remediation
Pavois's harden plan removes the avahi-daemon package (package resource, remove action) with pavois harden apply, which stops the mDNS responder and disables its socket.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | remove |
|---|---|
| name | avahi-daemon |
| resource | package |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Removing avahi breaks .local hostname resolution and zero-config discovery of network printers and devices, noticeable on desktops/labs but rarely on servers. Before applying, confirm no application relies on mDNS (e.g. CUPS auto-discovery, Chromecast/IoT integration). On headless servers the impact is typically none.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.1.2 | direct | per OS, see the benchmark table | high |
| NIST | CM-7(a), CM-7(b), CM-6(a) | 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.