How to remediate – Additional DNS Hostnames

1. Introduction

Nessus has detected potential virtual hosts, known as Additional DNS Hostnames. This means your system may be accessible via hostnames other than its primary one. This can allow attackers to target different web applications hosted on the same server, potentially leading to information disclosure or service disruption. Systems running web servers are usually affected. A successful attack could compromise confidentiality, integrity and availability of services.

2. Technical Explanation

The vulnerability occurs because multiple hostnames can resolve to a single IP address, allowing different websites (virtual hosts) to be served from the same server. An attacker could exploit this by sending requests to an alternate hostname associated with your server, potentially accessing unintended web applications or content. There is no specific CVE for this detection as it’s a configuration issue rather than a software flaw.

• Root cause: The server is configured to respond to multiple hostnames on the same IP address.
• Exploit mechanism: An attacker sends an HTTP request to one of the alternate hostnames, hoping to access a web application or content not intended for public access. For example, sending a request to www.example.com when the server is primarily configured for example.com.
• Scope: Web servers (Apache, Nginx, IIS) are affected.

3. Detection and Assessment

You can confirm whether your system is vulnerable by checking the hostnames associated with its IP address. A quick check involves listing all DNS records for your server’s IP.

• Quick checks: Use `nslookup ` or online tools like `dig` to list all DNS records pointing to your server’s IP address.
• Scanning: Nessus identifies this issue with plugin ID 14820. Other vulnerability scanners may have similar checks for virtual hosts.
• Logs and evidence: Web server logs (e.g., Apache access logs) may show requests coming in for alternate hostnames. Look for `Host:` headers that don’t match the primary hostname.

nslookup 192.0.32.10

4. Solution / Remediation Steps

To fix this issue, ensure your web server is configured to only respond to intended hostnames or properly configure virtual hosts if needed.

4.1 Preparation

• Ensure you have access to modify the web server’s configuration file and restart the service. A roll back plan is to restore the original configuration file.
• Changes may require a brief service outage, so schedule during off-peak hours with appropriate approval.

4.2 Implementation

1. Step 1: Edit your web server’s configuration file (e.g., Apache’s httpd.conf or Nginx’s nginx.conf).
2. Step 2: Remove any unnecessary virtual host definitions that point to the same IP address as your primary website.
3. Step 3: If you need multiple hosts, ensure each is explicitly configured with its own `ServerName` and `ServerAlias` directives.
4. Step 4: Restart the web server service to apply the changes.

4.3 Config or Code Example

Before

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com
</VirtualHost>
<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/example.com
</VirtualHost>

After

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – restrict access to web server configuration files to only authorized personnel.
• Practice 2: Secure defaults – configure the web server with minimal virtual hosts and only enable those that are required.

4.5 Automation (Optional)

Automation is not recommended for this issue due to the complexity of web server configurations. Manual review is preferred.

5. Verification / Validation

Confirm the fix by checking DNS records and verifying that only intended hostnames resolve to your server’s IP address.

• Post-fix check: Run `nslookup ` again and confirm that only expected hostnames are listed.
• Re-test: Re-run the Nessus scan (plugin ID 14820) to verify that the vulnerability is no longer detected.
• Smoke test: Access your primary website via its intended hostname to ensure it still functions correctly.
• Monitoring: Check web server logs for unexpected `Host:` headers and create an alert if any are found.

nslookup 192.0.32.10

6. Preventive Measures and Monitoring

Update security baselines to include checks for unnecessary virtual hosts.

• Baselines: Update your web server baseline or policy to require explicit configuration of all virtual hosts.
• Pipelines: Implement a code review process for any changes to the web server configuration files.
• Asset and patch process: Regularly review web server configurations as part of your asset management program.

7. Risks, Side Effects, and Roll Back

Removing virtual hosts could disrupt access to other websites hosted on the same server.

• Risk or side effect 1: Removing a necessary virtual host will cause downtime for that website.
• Risk or side effect 2: Incorrect configuration changes can prevent the web server from starting.
• Roll back: Restore the original web server configuration file and restart the service.

8. References and Resources

• Vendor advisory or bulletin: N/A – Configuration issue, no specific vendor advisory.
• NVD or CVE entry: N/A – Not a software vulnerability.
• Product or platform documentation relevant to the fix: https://en.wikipedia.org/wiki/Virtual_hosting