Full Report
Kent Ickler // Link-Local Multicast Name Resolution (LLMNR) This one is a biggie, and you’ve probably heard Jordan, John, me, and all the others say it many many times. LLMNR […] The post How To Disable LLMNR & Why You Want To appeared first on Black Hills Information Security, Inc..
Analysis Summary
# Best Practices: Disabling Link-Local Multicast Name Resolution (LLMNR)
## Overview
These practices address the critical security risk posed by the Link-Local Multicast Name Resolution (LLMNR) protocol. LLMNR allows name resolution via multicast packets (UDP port 5355) without requiring a DNS server. The protocol is exploitable because any node can falsely claim authority for a requested hostname (**Impersonator**), tricking clients (especially Windows) into sending credential hashes to an attacker (**Hash Harvester**). Since modern networks rely on proper DNS, disabling LLMNR is considered a necessary step to close this significant risk vector.
## Key Recommendations
### Immediate Actions
1. **Identify LLMNR dependency:** Before disabling, verify if any critical legacy or ad-hoc systems *absolutely* require LLMNR for name resolution within subnets. Document these exceptions if they cannot be migrated to standard DNS.
2. **Implement centralized Group Policy Object (GPO):** For Active Directory environments, immediately create or update a GPO targeting all domain workstations to enforce the disabling of LLMNR.
3. **Apply registry setting manually to non-domain or Home editions:** For Windows non-domain joined, Home edition, or Linux workstations where GPO cannot be applied, apply the disabling configuration via command line or local policy immediately.
### Short-term Improvements (1-3 months)
1. **Systematic Review and Remediation:** For any systems identified in the immediate action phase as potentially reliant on LLMNR, work with stakeholders to migrate their dependency to standard DNS or upgrade/reconfigure the failing service.
2. **Validate Disablement:** After deployment, proactively monitor network traffic and endpoint logs to confirm that LLMNR traffic (UDP 5355 multicast) ceases or significantly drops across the environment.
3. **Update Security Baselines:** Incorporate the explicit disablement of LLMNR into the standard security hardening baseline configuration for all new endpoint deployments (Windows and supported Linux distributions).
### Long-term Strategy (3+ months)
1. **Decommission Legacy Systems:** Phase out any hardware or software that cannot function correctly without legacy protocols like LLMNR, formalizing DNS as the sole mechanism for name resolution.
2. **Continuous Configuration Auditing:** Schedule semi-annual audits using configuration management tools to ensure the LLMNR disablement policy (GPO or registry setting) has not been accidentally reverted or bypassed on individual endpoints.
## Implementation Guidance
### For Small Organizations
* **Centralize via Local Policy/Registry:** If not using Active Directory, use local policy editing (`gpedit.msc`) or the command line to universally apply the registry change to all workstations.
* **Focus on User Endpoint Protection:** Prioritize disabling LLMNR on all user workstations, as they are the primary targets for credential hash harvesting events.
### For Medium Organizations
* **Active Directory Centralization:** Utilize an existing or new GPO for efficient, domain-wide deployment.
* **Segment Review:** If multiple subnets exist, conduct subnet-by-subnet testing before global roll-out to isolate potential breakage points related to local name resolution needs.
### For Large Enterprises
* **Phased GPO Rollout:** Deploy the LLMNR disabling GPO in stages: Test OU $\rightarrow$ Pilot Users $\rightarrow$ Segmented Production Groups $\rightarrow$ Enterprise-wide.
* **Configuration Management Enforcement:** Use tools like SCCM, Ansible, or Puppet to enforce the registry key/policy setting, ensuring persistence even if GPO processing has issues.
* **Linux Standardization:** Ensure the corresponding configuration change is pushed to all managed Linux systems using configuration management platforms.
## Configuration Examples
### Windows (Active Directory GPO)
**Path:** Computer Configuration $\rightarrow$ Administrative Templates $\rightarrow$ Network $\rightarrow$ DNS Client
**Setting:** **Turn Off Multicast Name Resolution**
**Action:** Set to **Enabled**
### Windows (Command Line for Single Workstation/Home Edition)
1. Create the registry path if missing (often unnecessary on modern systems, but included for completeness):
bash
REG ADD “HKLM\Software\policies\Microsoft\Windows NT\DNSClient”
2. Add or set the value to disable multicast resolution (0):
bash
REG ADD “HKLM\Software\policies\Microsoft\Windows NT\DNSClient” /v ”EnableMulticast” /t REG_DWORD /d “0” /f
### Linux (Ubuntu/Systemd-resolved)
1. Edit the configuration file:
bash
nano /etc/systemd/resolved.conf
2. Locate or add the line under the `[Resolve]` section:
ini
LLMNR=no
3. Reboot the system to apply changes:
bash
reboot
## Compliance Alignment
Since LLMNR exploitation typically involves the unauthorized access or capture of user credentials (hashes), disabling it aligns with standards focusing on credential protection and secure network configuration.
* **NIST SP 800-53 (Rev. 5):** SC-8 (Transmission Confidentiality and Integrity), AC-3 (Access Enforcement).
* **CIS Controls:** Control 3 (Data Protection), Control 4 (Secure Configuration of Enterprise Assets and Software).
* **ISO/IEC 22301 / ISO 27001:** A.12.1.2 (Change Management) and addressing security flaws in network protocols.
## Common Pitfalls to Avoid
* **Assuming DNS is always sufficient:** Do not skip the dependency check; although rare, specialized or truly ad-hoc networks might rely on LLMNR.
* **Only applying the fix to domain controllers:** LLMNR is a client-side protocol issue; domain controllers generally do not need remediation unless they also host domain-joined workstations. The focus must be on endpoints.
* **Not verifying the fix:** Failing to reboot or re-run configuration tools after applying the GPO/registry setting results in a false sense of security.
## Resources
* **Protocol Specification:** [IETF RFC 4795](https://tools.ietf.org/html/rfc4795) (For background context on LLMNR protocol mechanics).
* **Microsoft Documentation:** Security guidance regarding DNS Resolution vulnerabilities (often tied to MS11-030 or similar advisories focusing on name resolution trust issues).