I have been told that PING presents a security risk, and it's a good idea to disable/block it on production web servers. Some research tells me that there are indeed security risks. Is it common practice to disable/block PING on publicly visible servers? And does this apply to other members of the ICMP family, like traceroute (wikipedia on security)?
The ICMP Echo protocol (usually known as "Ping") is mostly harmless. Its main security-related issues are:
In the presence of requests with a fake source address ("spoofing"), they can make a target machine send relatively large packets to another host. Note that a Ping response is not substantially larger than the corresponding request, so there is no multiplier effect there: it will not give extra power to the attacker in the context of a denial of service attack. It might protect the attacker against identification, though.
Honored Ping request can yield information about the internal structure of a network. This is not relevant to publicly visible servers, though, since those are already publicly visible.
There used to be security holes in some widespread TCP/IP implementations, where a malformed Ping request could crash a machine (the "ping of death"). But these were duly patched during the previous century, and are no longer a concern.
It is common practice to disable or block Ping on publicly visible servers -- but being common is not the same as being recommended.
www.google.com responds to Ping requests;
www.microsoft.com does not. Personally, I would recommend letting all ICMP pass for publicly visible servers.
Some ICMP packet types MUST NOT be blocked, in particular the "destination unreachable" ICMP message, because blocking that one breaks path MTU discovery, symptoms being that DSL users (behind a PPPoE layer which restricts MTU to 1492 bytes) cannot access Web sites which block those packets (unless they use the Web proxy provided by their ISP).
ICMP has a data component to it. It can be used to build tunnels, and this is not just a theory thing, it's available in the wild. It's been found by several different researchers as parts of malware toolkits. Not to mention there is a prominent howto on this topic, not to mention the wiki, or the hackaday
ICMPTX uses the ICMP echo and ICMP reply. ICMP echo is not always harmless, since it contains a data component, it can be exfiltrating data or being used as a control channel, or being used (in the case of ICMPTX) as a tunneling protocol.
Current implimentation in distribution, with howto, (ICMPTX): http://thomer.com/icmptx/
Real attack scenario using ICMP data transmission for payload injection: Open Packet Capture
Use of an ICMP data transmission protocol via similar methods to ICMPTX(2006) for trojan C&C and Exfiltration: Network World
It is true that ICMP can be used by attackers to gain information, transport data covertly, etc. It is also true that ICMP is extremely useful, and that disabling it can often cause problems. Traceroute does in fact use ICMP, so disallowing certain ICMP types will break it.
The question highlights the classic balance of security and functionality, and it's up to you to determine how much functionality you're willing to lose to gain x amount of security.
One recommendation is to allow only certain types (the most commonly used), and disable all the others. Here are my iptables rules. Keep in mind that these are allowed because everything else is disallowed by default.
# Allow incoming ICMP: ping, MTU discovery, TTL expired /sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 8/0 -j ACCEPT /sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 3/4 -j ACCEPT /sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 11/0 -j ACCEPT
I think that outbound echo reply is more dangerous that inbound echo request because of ICMP amplification (either rate limit or deny this traffic). However, after decades of pondering this topic -- I've concluded that ICMP is more dangerous than useful, and thus it should be blocked in both directions, with logging on potentially spoofed outbound traffic.
The best of all worlds is null routes on everything that could be stateful-but-unwanted (TCP connections) and reflexive ACLs (performance driven) for anything stateful-but-allowed and/or not-fully-stateful (UDP datagrams), while removal of other IP protocol types, as they are unnecessary. IPsec AH/ESP is unnecessary, use OpenVPN (or similar) instead.
After you've blocked ICMP traceroute, you also need to contend with UDP based traceroute, as well as technology concepts such as found in the 0trace, LFT, and osstmm_afd tools.
Ping and Traceroute are required to troubleshoot networks. With modern firewalls, and security tools there is very little, and bordering on non-existant chance of either protocol being used successfully in an malicious way.
In 1996, sure it was a problem, but it is now 2015 almost 20 years later, and blocking these only leads to dramatically increased time frames to resolve connectivity and performance. Crippling the ability of tier 1/2 teams to identify and fix simple routing and network issues is a service delivery issue which impacts customer's satisfaction with whatever network services you provide.
Instead of answering the primary question of "what are the security risks of ping", I'll answer your sub-question of "Is it a good idea to block/disable on production web servers"
I think we can find a balance between security and utility here. Support staff generally find ping useful when checking the latency or availability of a certain node. Security staff are concerned about many of the security issues outlined in this page, and are often the "bad guys".
Why not consider disabling Ping in a whitelist / blacklist format, and make that known to your support staff. If your core audience is in a certain geographical region, limit the ability to ping based on IANA IP allocation
After an initial access to your server, a malicious software can use the ping protocol as a way of communication to its command and control server. As an example, a reverse shell using ping protocol: https://github.com/inquisb/icmpsh
In "Requirement for internet hosts", a respected authority responsible for the standarization of the ICMP, TCP, IP and other protocols, the IETF, specifies that hosts should respond to ICMP Queries. So not only is the practice safe, but it's considered mandatory for compliancy with their standards:
Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A host SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes.
In standard IETF language, MUST means that "the item is an absolute requirement of the specification." While SHOULD means that that there "may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood"
This means that a server must respond to an ICMP Echo Query, but may not provide a user interface for them.
The document refers to an extensive debate that took place before the date of the redaction 1989:
"This neutral provision results from a passionate debate between those who feel that ICMP Echo to a broadcast address provides a valuable diagnostic capability and those who feel that misuse of this feature can too easily create packet storms."
Even after more recent (2010) discussions on theoretical attacks through ICMP on RFC 5927, the IETF still didn't downgrade ICMP ECHO Responses from a MUST to a SHOULD. The target of this RFC are vendors and implementers of ICMP and TCP, not consumers. The worst-case scenarios described are degradation of service.
In short, ICMP is safe. Disabling is not recommended.
If you respect the shoulders of the giants you stand on, you will respect their decision and avoid deviating from convention.