Understanding the ICMP protocol
Posted 29 Aug 2007 at 03:01 UTC (updated 29 Aug 2007 at 03:23 UTC) by sye
On my intranet, between 'trusted' Linux hosts, sit
switches/routers/firewalls. I am
having the hardest time to persuade our info sec dept. to allow ICMP
packets to go between our servers. These servers are master server/
client server of an Enterprise distributed backup to ADIC tape library
application with media management layer to Oracle RMAN interface.
So my question to you all is that if TCP/UDP belong to transport layer
and IP/ICMP belong to network layer, for any complex
enterprise networking application, the default firewall security access
of blocking all ICMP packets make a more 'secure' or less 'secure'
environment within a corporate networked hosts?
Also what are the known security threat/holes of allowing ICMP
packets? Do you have any idea on the density/ratio of ICMP packets over
TCP/IP packets for congested network or not-so-congested network traffic?
Without at least some ICMP, you are compromising the smooth function of UDP and TCP (specifically, the fragmentation control packets). You're also making network diagnostics harder (blocking ICMP ECHO).
Security-wise, ICMP provides another possible covert channel and introduces the ability to do (some) network discovery.
I have a system set up, where I gather scan attempts (the IP address is otherwise firewalled off, with a DROP rule, so it's effectively unconnected as far as the world is concerned) and in the last 7 days, I have seen 3222 TCP-based scan packets, 569 ICMP ECHO and 189 UDP-based scan packets. The chances of the ICMP packets actually causing a compromise is low, there have been systems where they could've generated a DOS condition, though. Obviously, this is a rather specific set of stats and doesn't really reflect the make-up of normal IP traffic.
Once upon a time one could blue-screen a Windows 98 box with a single
ICMP packet. Those days are long gone of course.
Since there are far less blatant ways of constructing covert channels,
the only practical security implication of ICMP in the modern
environment is with regard to host discovery and fingerprinting. It is
generally futile, however, to make any reasoned case when dealing with a
paranoid security professional, who sees you as part of his threat
model. They are generally only responsive to authoritative directives.
I suggest getting a single TCP port openned between your systems, and
properly Internetworking them by means of an OpenVPN overlay network,
unless you have prohibitive latency constraints. This will allow you to
them as RFC-conformant internet hosts for all practical purposes, within
in this particular case with Syncsort Backup Express, it doesn't use ICMP: TCP/UDP/IP are sufficient.
I'm still not entirely sure about NFS. How NFS may use ICMP protocol. I can't seem to get a Solaris 9 NFS client to mount Linux SuSE NFS export with our lock-everything-down-by-default security/firewall policy situated in between.
Thank you both for your input.
anybody care to comment on VMware
Infrasture 3? . Is it a BIG deal to virtualize x86 computing
platform like resource provisioning in IBM's mainframe computing?
implications, posted 14 Oct 2007 at 22:00 UTC by Mysidia »
See informational RFC 2979 3.1.1.
Blocking ICMP right out can interfere with PMTU discovery. This can
cause undue delay in application traffic. It can cause other hosts to
be unable to communicate with application services over TCP/UDP.
Unfortunately, blocking all ICMP is one of those things that creates a
situation where the network "seems" to still work after ICMP is
blocked, despite the protocol's importance, but will break later,
(TCP/IP stacks and hardware following common assumptions are robust
enough that everything may seem to be running smoothly without ICMP)
The brokenness caused by blocking ICMP will show up randomly, or
sporadically enough that the firewall admin may not recognize or
be willing to admit that anything's wrong with the firewall config
-- instead it'll get blamed on other equipment, or the server, or
the end user's PC, network card, etc...
Maybe only their device has problems (a new addition to the network
is using a different transmission size)
ICMP provides a convenient way to determine whether or not a host
exists on a specific IP (ICMP ECHO). On a private intranet it may
be desired to keep the identity of certain hosts obscure.
There are other discovery techniques, such as sniffing, ARPing, or TCP
connect. ICMP is not the only way to discover that a host exists.
So preventing discovery of a host is not really a reason to block all
There are ways to prevent third-party hosts from discoverying private
hosts other than blocking all ICMP.
On the other hand, if a pairs of host communicates using TCP or UDP,
they already know each other exists. If one of the two is
compromised, the intruder will simply use the "netstat" command and
immediately know the identity of the peer.
So there's no reason to disallow the TCP/UDP peers from communicating
using ICMP. At the same time ICMP from outside origins might be
safely blocked (ICMP between hosts that don't ever communicate with
If the goal is to prevent host discovery, then when ICMP is blocked
between two hosts, then TCP should be also, as blocking ICMP is
inadequate to prevent one host from discovering the other.