How to remediate – ICMP Domain Name Request

1. Introduction

The ICMP Domain Name Request vulnerability means a remote host responds to requests for its DNS name using ICMP messages. This allows attackers to map IP addresses to domain names, potentially revealing internal network information. Systems directly exposed to the internet are most affected. A successful exploit could lead to information disclosure impacting confidentiality.

2. Technical Explanation

The remote host answered to an ICMP ‘Domain Name Request’ as defined in RFC 1788. An attacker can send an ICMP message requesting the DNS name associated with a target IP address, and if enabled, the host will respond with that information. This is not inherently malicious but provides unnecessary information about the network.

• Root cause: The host is configured to answer ICMP domain name requests.
• Exploit mechanism: An attacker sends an ICMP echo request (type 0) followed by a domain name request (type 37). The host responds with its DNS name in an ICMP reply (type 38).
• Scope: Any system running a network stack that answers ICMP Domain Name Requests. This is commonly found on Linux, Windows and other Unix-like systems.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking if it responds to ICMP domain name requests. A thorough method involves capturing network traffic during a request.

• Quick checks: Use the `ping` command with the `-n` option on Windows or `host` command on Linux, targeting an internal IP address. If you receive a DNS name in the response, the system is likely vulnerable.
• Scanning: Nmap can be used to detect this vulnerability using the script icmp-info. Example: nmap -p ICMP --script icmp-info .
• Logs and evidence: Network captures (using Wireshark or tcpdump) will show ICMP replies containing DNS names when a domain name request is sent.

ping -n 

4. Solution / Remediation Steps

To fix this issue, filter out incoming and outgoing ICMP packets of types 37 and 38. This prevents the host from responding to domain name requests and sending its DNS name in clear text.

4.1 Preparation

• Ensure you understand the impact of filtering ICMP traffic on other network tools that may rely on it. Approval from a network administrator might be needed.

4.2 Implementation

1. Step 1: Configure your firewall to block incoming ICMP packets with type code 37 (Domain Name Request).
2. Step 2: Configure your firewall to block outgoing ICMP packets with type code 38 (Domain Name Reply).
3. Step 3: Test the configuration by sending an ICMP domain name request from another system and verifying that no response is received.

4.3 Config or Code Example

Before

# No specific ICMP filtering rules configured

After

iptables -A INPUT -p icmp --icmp-type 37 -j DROP
iptables -A OUTPUT -p icmp --icmp-type 38 -j DROP
# Save the iptables rules to make them persistent. The exact command depends on your distribution (e.g., iptables-save > /etc/iptables/rules.v4)

4.4 Security Practices Relevant to This Vulnerability

Least privilege and network segmentation can reduce the impact of this vulnerability by limiting exposure. Input validation is not directly applicable, but secure defaults (disabling unnecessary services like ICMP domain name responses) are important.

• Practice 1: Least privilege – limit access to internal networks to only authorized users and systems.
• Practice 2: Network segmentation – isolate sensitive systems from the public internet.

4.5 Automation (Optional)

Ansible can be used to automate firewall rule updates across multiple systems. Be cautious when modifying firewall rules remotely, as incorrect configuration could disrupt network connectivity.

- name: Block ICMP Domain Name Requests
  iptables:
    chain: INPUT
    protocol: icmp
    icmp_type: 37
    jump: DROP
- name: Block ICMP Domain Name Replies
  iptables:
    chain: OUTPUT
    protocol: icmp
    icmp_type: 38
    jump: DROP

5. Verification / Validation

Confirm the fix by sending an ICMP domain name request and verifying that no response is received. A smoke test involves checking basic network connectivity to ensure other services are not affected.

• Post-fix check: Run ping -n again. You should *not* receive a DNS name in the output.
• Re-test: Re-run the Nmap scan (nmap -p ICMP --script icmp-info ). The script should no longer report that the host answers to domain name requests.
• Smoke test: Verify you can still ping external websites and access other network resources.

ping -n  # Should not return a DNS name

6. Preventive Measures and Monitoring

Update security baselines to include filtering ICMP domain name requests as a standard configuration setting. Implement CI/CD pipeline checks to ensure firewall rules are consistently applied across all systems. A regular patch review cycle helps identify and address similar vulnerabilities promptly.

• Baselines: Update your network security baseline or CIS control settings to disable ICMP Domain Name Request responses.
• Pipelines: Add a check in your CI/CD pipeline to verify that firewall rules are correctly configured on new systems.
• Asset and patch process: Review system configurations regularly for unnecessary services like ICMP domain name responses.

7. Risks, Side Effects, and Roll Back

Filtering ICMP traffic may impact network tools that rely on it (e.g., traceroute). Incorrect firewall configuration could disrupt network connectivity. To roll back, remove the added firewall rules and restore the previous configuration.

• Risk or side effect 1: Disruption of network diagnostic tools like traceroute if ICMP is completely blocked.
• Risk or side effect 2: Potential impact on systems relying on ICMP for specific functions (rare).
• Roll back:
  1. Step 1: Remove the added iptables rules using iptables -D INPUT -p icmp --icmp-type 37 -j DROP and iptables -D OUTPUT -p icmp --icmp-type 38 -j DROP.
  2. Step 2: Restore your previous firewall configuration from the backup.

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory available for this general issue.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-1998-675