The /etc/hosts file provides local hostname to IP address mappings before external name resolution is used. Administrators use it for overrides, testing, and local services, but attackers may tamper with it to redirect traffic or bypass intended destinations. Monitor for unauthorised edits and keep entries minimal and accurate.
How /etc/hosts resolution works before DNS
The operating system checks /etc/hosts as a local name map before it asks external DNS, so an entry there can override what public or internal name servers would return. That makes it useful for quick testing, service redirects, and emergency fixes when DNS is unavailable. It also means the file sits on a trusted lookup path and should stay small, deliberate, and easy to review.
Resolution is straightforward: if a hostname matches an entry in the file, the system uses the associated IP address and stops there for that lookup. If no match exists, normal name resolution continues. The practical consequence is that /etc/hosts is not just a convenience file, it is a precedence mechanism that can change where applications connect without any change to DNS.
Because the file is local to the machine, it affects only that host unless configuration management or imaging copies the same entries elsewhere. That makes it a sharp tool for controlled overrides, but also a source of drift when different servers carry different mappings. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to manage local configuration changes, while NIST Cybersecurity Framework 2.0 is useful for thinking about configuration control, monitoring, and recovery when a local lookup source changes unexpectedly.
What can go wrong when hosts entries are wrong or tampered with
A stale or malicious entry can send users and services to the wrong destination even when DNS is correct. That can break updates, redirect admin traffic, interfere with internal service discovery, or create a stealthy path for credential theft if users trust the redirected endpoint. Since many applications rely on the system resolver, a single altered line can have outsized effect.
Failure mechanism: An attacker or careless administrator edits the file to change name resolution on the local machine, causing the system to resolve a trusted hostname to an unintended IP address before DNS is consulted.
Impact: Traffic can be diverted, blocked, or silently intercepted, which can produce service outages, hard-to-diagnose connectivity problems, or access to a spoofed service that looks legitimate to the user or application.
On Linux and Unix-like systems, monitoring this file is often as important as monitoring DNS itself because tampering does not require network-level compromise. A low-friction local edit can be enough to influence browser sessions, command-line tools, package managers, and automation that depend on system name resolution. That is why file integrity, change logging, and least-privilege access all matter here.
How to use /etc/hosts safely in practice
The safest use pattern is narrow and explicit: add only the entries you need, document why they exist, and remove them as soon as the override is no longer required. Wildcard thinking does not apply here, because each line can create a durable local exception to your normal naming and routing model.
For temporary testing, prefer a clearly named short-lived entry over ad hoc edits that nobody owns. For shared systems, treat the file as controlled configuration, not a scratchpad. If a hostname must always resolve locally, confirm that the entry is consistent with the service’s real target and will not be copied into environments where it would mask a legitimate DNS record.
CIS Benchmarks are a useful reference point for hardening and configuration discipline, especially where local name resolution can be abused to redirect traffic. In the same spirit, NIST SP 800-207 Zero Trust Architecture is a good reminder not to treat local trust signals as proof of destination trust; the resolved address still needs to be verified through policy, segmentation, and service validation.
Risk and Threat Considerations
/etc/hosts is a small file with a large blast radius because it can override name resolution before DNS and therefore influence which systems users and services reach. If an attacker can modify it, they can redirect traffic without touching network infrastructure, which makes the change attractive for persistence, phishing inside trusted workflows, or denial of access to legitimate services.
Failure mechanism: The threat depends on writable local configuration, weak file permissions, or poor monitoring that lets a malicious or unauthorized change persist long enough to matter.
Impact: The result can be silent redirection, broken updates, impaired incident response, or exposure to spoofed services that capture credentials or session data under a trusted hostname.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Hosts overrides depend on controlled system configuration and asset awareness. |
| PR.AA-05 — Identities are authenticated and access is enforced | Local file tampering can redirect access to trusted services. | |
| DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Unauthorized hosts-file edits are a detectable integrity event. | |
| Recommendation — Inventory systems that rely on local name-resolution overrides. Enforce access controls so only authorized admins can change resolution files. Monitor critical hosts files for unauthorized modification and drift. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | The file is a sensitive configuration object whose changes need restriction. |
| CM-6 — Configuration Settings | Hosts entries are configuration settings that affect resolution behavior. | |
| AU-9 — Protection of Audit Information | Integrity logging helps detect unauthorized local modifications. | |
| Recommendation — Restrict who can alter local name-resolution files and document exceptions. Baseline approved hosts entries and review deviations regularly. Protect and retain logs that record changes to critical configuration files. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Local hosts files are configuration artifacts that should be hardened and controlled. |
| CIS-8 — Audit Log Management | Change detection depends on reliable logging and alerting. | |
| Recommendation — Baseline and monitor hosts-file content on all managed systems. Alert on unauthorized edits to local resolution and trust files. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The hosts file is a configuration item whose integrity affects system behavior. |
| Recommendation — Manage hosts-file changes through controlled configuration processes. | ||
Practitioner Guidance
What to verify: Confirm ownership, permissions, and change control on the file, then compare its entries with the authoritative DNS records for the same names. If the file contains unexpected overrides, treat them as a security finding, not just a configuration nuisance.
What to measure: Track unauthorized edits, drift from approved baselines, and the age of exceptions. A growing list of ad hoc entries is usually a sign that local overrides are being used to compensate for broken naming discipline elsewhere.
Practitioner takeaway: Use /etc/hosts as a deliberate exception mechanism, not as a hidden dependency, and protect it with the same rigor you would apply to any control that can silently redirect trust and traffic.