1. Introduction
The remote host’s hostname is inconsistent with DNS information. This means the machine’s name doesn’t match what’s recorded in Domain Name System records, or it doesn’t resolve to an IP address at all. This can affect URLs within security reports and cause incomplete web tests. A business may experience inaccurate reporting and potentially miss vulnerabilities due to failed test conditions. Systems commonly affected are servers, workstations, and network devices with static hostnames. This issue has a low impact on confidentiality, integrity, and availability.
2. Technical Explanation
The root cause is typically a misconfigured reverse DNS (PTR) record or an incorrect entry in the host file of the scanning machine. An attacker could exploit this by performing man-in-the-middle attacks if they can control DNS records, redirecting traffic to malicious servers. The precondition for exploitation is the ability to manipulate DNS records associated with the target hostname.
- Root cause: Incorrect or missing PTR record in DNS, or an incorrect entry in the Nessus scanning host’s `/etc/hosts` file (or equivalent on Windows).
- Exploit mechanism: An attacker could poison the DNS cache with a false IP address for the hostname. This would redirect traffic intended for the legitimate server to a malicious one. For example, if a web application relies on URLs constructed using the hostname, an attacker controlling DNS could redirect users to a phishing site.
- Scope: All systems with static hostnames that are scanned by Nessus and rely on accurate DNS resolution.
3. Detection and Assessment
To confirm if a system is vulnerable, first check the hostname resolution and then verify the reverse DNS record.
- Quick checks: Use `hostname -f` to display the fully qualified domain name (FQDN) of the host. Then use `nslookup
` to resolve the hostname to an IP address. - Scanning: Nessus plugin ID 10874 can identify this issue. Other vulnerability scanners may have similar checks for DNS inconsistencies.
- Logs and evidence: Check system logs (e.g., `/var/log/syslog` on Linux) for DNS resolution errors or warnings related to hostname mismatches.
hostname -f
nslookup
4. Solution / Remediation Steps
Fix the reverse DNS record or update the host file on the scanning machine.
4.1 Preparation
- Ensure you have access to modify DNS records and the Nessus scanning host’s configuration files. Roll back by restoring the original DNS records or reverting the host file changes.
- A change window may be needed for DNS updates, depending on your organization’s policies. Approval from a network administrator might be required.
4.2 Implementation
- Step 1: Verify the correct IP address associated with the hostname using `nslookup
`. - Step 2: Update the reverse DNS record (PTR record) in your DNS server to map the correct IP address to the hostname. The exact method depends on your DNS provider.
- Step 3: If the issue persists, check the `/etc/hosts` file (Linux) or `C:WindowsSystem32driversetchosts` (Windows) on the Nessus scanning host for any incorrect entries and remove them.
- Step 4: Restart the DNS resolver service if necessary to apply changes.
4.3 Config or Code Example
Before (Example `/etc/hosts` file entry)
127.0.0.1 example.com example
After (Corrected `/etc/hosts` file – remove incorrect entry if present)
# No entry for example.com in /etc/hosts
4.4 Security Practices Relevant to This Vulnerability
- Least privilege: Limit access to DNS configuration to authorized personnel only, reducing the risk of unauthorized changes.
- Configuration management: Use a configuration management tool to ensure consistent and accurate DNS records across all servers.
4.5 Automation (Optional)
If you use infrastructure-as-code tools like Ansible, you can automate DNS record updates.
# Example Ansible task to update a DNS A record
- name: Update DNS A record
dnsmasq_record:
name: example.com
type: A
address: 192.168.1.100
state: present
5. Verification / Validation
Confirm the fix by re-running the hostname resolution checks and verifying that the DNS record is correct.
- Post-fix check: Run `hostname -f` and `nslookup
` again. The output should show the correct FQDN and IP address. - Re-test: Re-run the Nessus scan (plugin ID 10874) to confirm that the vulnerability is no longer detected.
- Smoke test: Verify that you can access web applications or services hosted on the affected server using its hostname.
- Monitoring: Monitor DNS resolution logs for any unexpected errors or changes related to the hostname.
hostname -f
nslookup
6. Preventive Measures and Monitoring
- Baselines: Implement a security baseline that requires accurate DNS records and proper host file configuration. For example, CIS control 5 covers secure system configuration.
- Pipelines: Integrate checks into your CI/CD pipeline to validate DNS resolution during deployment.
- Asset and patch process: Regularly review DNS records as part of your asset management process. A quarterly review cycle is sensible.
7. Risks, Side Effects, and Roll Back
- Roll back: Restore the original DNS records from your backup if any issues occur. Revert any changes made to the `/etc/hosts` file on the Nessus scanning host.
8. References and Resources
- Vendor advisory or bulletin: N/A – This is a general configuration issue, not specific to one vendor.
- NVD or CVE entry: N/A – No specific CVE for this generic issue.
- Product or platform documentation relevant to the fix: Consult your DNS server’s documentation for instructions on updating PTR records.