Disable LLMNR Linux

What the LLMNR hardening Worklet does

This Automox Worklet™ disables Link-Local Multicast Name Resolution (LLMNR) on Linux endpoints that run systemd-resolved. LLMNR is a legacy multicast name resolution protocol defined in RFC 4795. It lets a host broadcast a UDP query to 224.0.0.252 (or ff02::1:3 on IPv6) when DNS does not return an answer, and any neighbor on the same broadcast domain can respond. On a corporate network with functioning internal DNS, that fallback path has no operational purpose and only exposes the endpoint to a well-documented credential theft technique.

The Worklet enforces a single line of configuration. It rewrites any existing LLMNR= line in /etc/systemd/resolved.conf to LLMNR=no, the file that controls the systemd-resolved name service caching daemon and that ships with a commented LLMNR entry under the [Resolve] section by default. After the remediation runs, the endpoint stops sending LLMNR queries and stops responding to LLMNR queries from other hosts on the link. A restart of systemd-resolved (or a full reboot) applies the change to the running service, and you can confirm the new state with resolvectl status.

The evaluation phase is idempotent, so a weekly check re-flags any host where an image refresh, a configuration management tool, or a manual edit puts LLMNR back into play. If the remediation cannot confirm LLMNR=no after running sed, it prints "LLMNR could not be toggled off." and exits 1, so failures land in Automox activity logs instead of going silent.

Why disable LLMNR across a Linux fleet

LLMNR poisoning is one of the most reliable credential theft techniques in modern penetration testing. Tools like Responder, Inveigh, and KrbRelayUp listen for LLMNR queries on the local segment, answer with their own IP, and capture NTLMv2 hashes or SMB authentication that they then crack offline or relay against another host. The attack works against any host that still has LLMNR enabled, including Linux endpoints joined to mixed Windows and Linux networks where the LLMNR traffic is plentiful. CIS Benchmarks for Ubuntu 22.04, RHEL 9, and Debian 12 all flag LLMNR as a finding and recommend setting LLMNR=no in resolved.conf for exactly this reason.

The Worklet rewrites the LLMNR line in /etc/systemd/resolved.conf to LLMNR=no on every Linux endpoint in scope. Subsequent evaluations confirm the value with grep and finish in milliseconds on hosts already aligned with the baseline. A RHEL build host, an Ubuntu developer workstation, and a Debian edge node where the value has drifted back to the distribution default all re-converge on the next policy run.

How LLMNR enforcement works on Linux

1. Evaluation phase: The script case-insensitively greps /etc/systemd/resolved.conf for the anchored pattern ^LLMNR=no. A match means the endpoint already enforces the hardened setting and the Worklet exits 0 (compliant). A miss means LLMNR is unset, commented, set to yes, or set to resolve (the systemd-resolved default that still answers queries) and the Worklet exits 1, which triggers remediation on the next pass.

2. Remediation phase: The script runs sed -i 's/.*LLMNR=.*/LLMNR=no/g' /etc/systemd/resolved.conf to rewrite any existing LLMNR line in place (commented or otherwise), then re-greps the file with the anchored pattern ^LLMNR=no to confirm the new value. On success it exits 0 and on failure it prints "LLMNR could not be toggled off." and exits 1. The Worklet does not bounce systemd-resolved on its own; schedule systemctl restart systemd-resolved (or a maintenance-window reboot) as a follow-up so the running service picks up the new configuration.

LLMNR hardening requirements

• Linux endpoint running systemd-resolved (Ubuntu 18.04+, Debian 11+, RHEL 8+, Fedora, openSUSE, Arch, and most current systemd-based distributions)

• /etc/systemd/resolved.conf present on disk with an existing LLMNR= line, commented or otherwise, for sed to rewrite (the stock file ships with #LLMNR=yes under [Resolve] on every supported distribution)

• Root privileges for the Automox agent so the remediation can sed-edit /etc/systemd/resolved.conf (the default agent context already meets this)

• Coreutils grep and sed available in the agent's PATH (present in every supported distribution's base install)

• A follow-up systemctl restart systemd-resolved or scheduled reboot so the running resolver reloads the updated configuration

• Endpoints that resolve names through an internal or upstream DNS server; LLMNR has no operational role in an environment with working DNS

Expected LLMNR state after remediation

After the remediation runs and systemd-resolved restarts, /etc/systemd/resolved.conf contains LLMNR=no in the [Resolve] section and the next evaluation reports the endpoint as compliant without re-running remediation. You can confirm the live state with resolvectl status; the output reports Protocols: -LLMNR (the leading minus sign signals the protocol is disabled) instead of the default +LLMNR. A tcpdump on the local interface for udp port 5355 should show no outbound LLMNR queries from the endpoint, even when DNS returns NXDOMAIN.

DNS resolution itself is unaffected. Applications continue to resolve hostnames through the upstream resolvers configured in /etc/resolv.conf or pushed by NetworkManager, and lookups that succeed in DNS today keep succeeding. Only the unauthenticated multicast fallback is removed. Endpoints stop trusting LLMNR responses from neighbors, which closes the path that Responder, Inveigh, and similar credential-relay tooling rely on to capture and relay NTLMv2 authentication on the local segment. The change satisfies the LLMNR control referenced in CIS Linux Benchmarks and supports NIST 800-53 SC-7 boundary protection as part of a broader fleet-hardening baseline.