Common mistakes with Internet Control Message Protocol (ICMP) are leaving it fully open, or blocking it indiscriminately. ICMP is needed for diagnostics and path discovery, but attackers can use it for reconnaissance, tunnelling, or flood attacks. Limit it to required message types, filter at boundaries, and monitor unusual volumes or repeated error messages.
How ICMP should be handled, not just allowed or denied
ICMP is part of normal IP operations, so the mistake is treating it like a binary allow-all or block-all service. Some message types support path discovery, fragmentation feedback, and troubleshooting, while others are more useful to an attacker than to operations. The goal is selective filtering, not blanket suppression.
A Network Ports and Protocols Security Guide helps place ICMP alongside other exposed protocols that need selective exposure rather than unconditional trust. At the standards level, IANA is the authoritative registry for protocol parameters and identifier assignments, which is useful when you need to verify what a given ICMP type or code is intended to do.
The practical question is which ICMP traffic your environment actually needs. Network operators often keep echo replies, destination unreachable messages, and path-related functions available for diagnostics, while restricting unnecessary inbound exposure from untrusted networks. That approach preserves troubleshooting value without leaving every control message open to enumeration or abuse.
Why attackers care about ICMP abuse
ICMP is attractive because it can reveal reachability, latency, routing behavior, and host responsiveness with very little setup. Attackers may use it for reconnaissance, tunnelling, or flood-style disruption, so letting it through without monitoring can create both visibility and availability problems.
A Command and Control (C2) Guide is relevant because ICMP is sometimes used as a covert communication channel in adversary tradecraft, not just as a diagnostic protocol. For defenders, the important point is that protocol choice alone does not make traffic benign, especially when volume, direction, or message patterns diverge from normal network behavior.
The mistake many teams make is assuming ICMP is either harmless noise or automatically suspicious. In reality, the risk comes from context: unusually frequent errors, unexpected echo traffic across boundaries, or ICMP used where you would normally expect application-layer communication. Those patterns are often more informative than the raw presence of ICMP itself.
Filtering and monitoring ICMP without breaking operations
Good ICMP handling starts at the boundary. Allow the message types you need for routing feedback and troubleshooting, block or rate-limit the rest, and avoid exposing internal diagnostics broadly to the internet. Where possible, pair filtering with alerts on repeated error messages, sudden volume spikes, or unusual source and destination patterns.
NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for the control themes behind that approach, especially access control, monitoring, and system integrity. The value is not in a single ICMP rule, but in documenting the approved message types, reviewing exceptions, and validating that security monitoring can distinguish legitimate diagnostics from abuse.
Teams also underestimate how often ICMP exceptions are added during troubleshooting and never revisited. If you need a temporary rule for path discovery or incident response, time-box it and confirm that it is removed or narrowed after the operational need ends. Long-lived broad allowances are where diagnostic convenience turns into an attack surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | ICMP handling is a boundary filtering and exposure-control problem. |
| SI-4 — System Monitoring | Unusual ICMP volumes and repeated errors require detection and alerting. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | ICMP exceptions and repeated error conditions need reviewable evidence. | |
| Recommendation — Filter ICMP at trust boundaries and restrict allowed message types to operational need. Monitor ICMP patterns for reconnaissance, tunnelling, and flood indicators. Review logged ICMP anomalies and exception use to confirm controls stay effective. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Selective ICMP exposure is part of managing network traffic and device behavior. |
| Recommendation — Manage network device settings to permit only required ICMP flows and responses. | ||
| MITRE ATT&CK | T1095 — Non-Application Layer Protocol | ICMP tunnelling and covert traffic fit adversary use of non-application protocols. |
| Recommendation — Hunt for covert ICMP channels and block unauthorized protocol tunnelling. | ||
Practitioner Guidance
What to verify: Confirm which ICMP types your routing, monitoring, and operations tools genuinely require, then test whether the environment still functions when everything else is denied or rate-limited. If a rule exists only because “it always has,” treat it as an exception that needs justification.
Decision rule: If the ICMP message type supports a defined operational need, allow it narrowly and monitor it; if it does not, drop it at the boundary and keep an audit trail for any temporary override. For any ICMP traffic that crosses trust boundaries, review whether the same outcome can be achieved with a narrower scope or a different control.
What practitioners underestimate: ICMP problems are often caused by overcorrection, not just exposure. Blocking too much can break diagnostics and path MTU discovery, while allowing too much can expose topology and create a quiet reconnaissance channel.
Practitioner takeaway: Treat ICMP as a controlled diagnostic protocol, not a special case that is either fully trusted or fully denied, and make exceptions visible enough to review before they become permanent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org