Reduce the risk by disabling responses to ICMP information requests and by filtering legacy ICMP traffic that is not required for operations. These requests are rarely needed in modern networks and can assist reconnaissance. Log unusual ICMP types at the perimeter so you can spot systematic discovery attempts.
What should be disabled or filtered to blunt ICMP information requests?
The most effective mitigation is to stop hosts from answering icmp information request unless you have a specific operational need. In parallel, filter legacy ICMP traffic at the perimeter or host firewall so only approved ICMP types can pass. That reduces reconnaissance value without changing the behaviour of core routing or diagnostics.
Because this is a legacy discovery technique, the right question is not whether ICMP exists on the network, but whether a given type is still needed for business traffic, monitoring, or troubleshooting. If it is not needed, deny it explicitly rather than relying on implicit defaults.
How does this fit into network hardening?
ICMP information requests sit in the broader category of protocol exposure management. They are usually low-value to legitimate operations and can reveal useful hints about hosts, stacks, or network behaviour to an observer performing discovery. Treat them the same way you would other obsolete or unnecessary network services: allow only what you can justify, and block the rest. The Network Ports and Protocols Security Guide is the natural parent resource for deciding which legacy network protocols should remain exposed.
In practice, the control objective is not “block all ICMP”, which can break useful diagnostics, but “reduce unnecessary response surface”. That means documenting which ICMP types are permitted, where they are permitted, and which systems are exceptions because of monitoring or legacy interoperability.
What should you watch for in perimeter logs and discovery activity?
Unusual ICMP types, repeated probing from the same source, or broad sweeps across address ranges are all signs that someone may be mapping reachable systems or testing filtering behaviour. Logging at the perimeter helps distinguish a one-off diagnostic event from systematic discovery, especially when ICMP is otherwise quiet in the environment.
When you see ICMP discovery traffic alongside other reconnaissance signals, such as port scanning or repeated connection attempts, treat it as part of a larger enumeration pattern rather than as an isolated event. The main value of the log data is correlation, not volume.
Risk and Threat Considerations
ICMP information requests are attractive because they are low-noise, often overlooked, and can help an attacker learn about reachable hosts or network behaviour before moving to more direct probing. The risk is highest where legacy ICMP is broadly allowed or unmonitored, because it gives an observer a lightweight way to map the environment.
Failure mechanism: Hosts or network devices answer ICMP types that are unnecessary for business operations, and the resulting responses disclose information that supports reconnaissance and follow-on targeting.
Impact: Attackers can refine target selection, increase scan efficiency, and combine ICMP observations with other discovery data to reduce uncertainty before attempting exploitation or access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | ICMP filtering and protocol hardening are network infrastructure safeguards. |
| Recommendation — Restrict unnecessary ICMP types and harden perimeter filtering for exposed network paths. | ||
| NIST CSF 2.0 | PR.PS-05 — Protective Technology | Filtering legacy ICMP traffic is a protective technology control against reconnaissance. |
| Recommendation — Apply protective filtering to reduce unnecessary protocol exposure. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Perimeter filtering of ICMP types is a boundary protection concern. |
| Recommendation — Enforce boundary filters that block unnecessary ICMP traffic types. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Selective ICMP blocking is a network security control under Annex A. |
| Recommendation — Document and enforce network filtering rules for unnecessary ICMP types. | ||
Practitioner Guidance
What to prioritise: Start by identifying where ICMP information requests are actually allowed today, then remove those allowances on internet-facing segments first. If a monitoring or troubleshooting exception exists, scope it narrowly and document the owner.
What to verify: Confirm that filtering rules block the specific ICMP types you do not need, not just “ICMP” as a blanket category. Validate that logging captures the source, destination, and ICMP type so you can tell accidental noise from deliberate discovery.
Practitioner takeaway: The best mitigation is selective suppression, not indiscriminate blocking, because the goal is to cut reconnaissance value while preserving the small set of ICMP functions that operations truly need.