Understanding the ICMP protocol

Posted 29 Aug 2007 at 03:01 UTC (updated 29 Aug 2007 at 03:23 UTC) by sye Share This

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 protocol packets to go between our servers. These servers are master server/ device 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?

Some general thoughts on firewalling ICMP, posted 29 Aug 2007 at 08:42 UTC by ingvar » (Master)

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.

Those days are gone, posted 29 Aug 2007 at 21:33 UTC by aminorex » (Journeyer)

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 treat them as RFC-conformant internet hosts for all practical purposes, within their VPN.

Well, as it turns out..., posted 30 Aug 2007 at 22:51 UTC by sye » (Journeyer)

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.

VMware Infrastructure 3, posted 1 Sep 2007 at 18:46 UTC by badvogato » (Master)

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 » (Observer)

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 ICMP.

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 each other).

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.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page