53

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)?

AviD
  • 72,138
  • 22
  • 136
  • 218
Mr. Jefferson
  • 705
  • 1
  • 5
  • 7
  • 5
    I think it is more appropriate to ask when is disabling ICMP ping appropriate. In what threat environment should ICMP ping responses be disabled? What vulnerabilities does/might ICMP have? How can we limit exposure to ICMP vulnerabilities? – this.josh Jun 08 '11 at 21:31
  • 3
    If ping is a security risk to your network, it has bigger issues than security :P – Navin Jul 08 '16 at 00:19

7 Answers7

65

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

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    this is not completely correct, see @Ori's answer for some additional information. – AviD Jun 09 '11 at 21:18
  • 2
    I find it increasingly difficult to explain to network engineers the need for dest unreach for PMTU-disc, squench types, and other scenarios of "good ICMP". Also see -- http://rfc-ignorant.org – atdre Jun 10 '11 at 20:39
  • 1
    @atdre I agree there are types that are necessary, ICMP echo/reply was really where I was going. Unreachables are completely necessary. @Thomas I always love "Mostly Harmless" (re Douglas Adams) in any post, it's what made me want to respond in the first place. – Ori Jun 12 '11 at 06:23
  • 1
    Ping of death is actually a misleading name, since it is actually an attack on the IP layer rather than ICMP. In other words the attack could equally well be aimed at any other IP protocol which is not filtered. – kasperd Feb 04 '15 at 21:21
  • destination unreachable is not used for path MTU - fragmentation needed is. – antiduh Sep 01 '15 at 13:21
  • When using IPv6, you shouldn't block ping request and ping echo because it breaks support for people connecting to your server over teredo – Ferrybig Jul 11 '16 at 10:25
  • google.com accept ICMP package yes, but if package size isn't modified ! – albttx Feb 24 '17 at 08:13
  • `ping www.microsoft.com` now responds. – Carl Walsh Nov 09 '21 at 23:38
19

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

Ori
  • 2,757
  • 1
  • 15
  • 29
  • Would you please cite the researches who found ICMPTX in malware toolkits. – this.josh Jun 08 '11 at 21:17
  • It's been nearly a decade, I'll see if there's still something tangible. At the moment it's heresay but I have worked with people who had first hand experience in some early instances of it. – Ori Jun 08 '11 at 21:27
  • Ang Cui will be giving a demo of IOS attacks utilizing ICMP as the control channel. http://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html I'll do some research of existing exploit frameworks this evening to see if there is an ICMP payload commonly distributed as well. – Ori Jun 08 '11 at 22:47
  • Thank you. For further clarification: Ang Cui, [Killing the Myth of Cisco IOS Diversity](http://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html): Towards Reliable, Large-Scale Exploitation of Cisco IOS 'This ability allows the attacker to use the payload of innocuous packets, like ICMP, as a covert command and control channel.' – this.josh Jun 08 '11 at 22:55
  • 21
    So what if ICMP can be used to tunnel data? So can any other network protocol you choose. So can DNS -- are you gonna block all DNS traffic? So can HTTP -- are you gonna block all port 80? I think this is a bogus reason to block ping. – D.W. Jun 09 '11 at 07:29
  • 3
    It's one more "service" that could be available for an attacker to leverage in a multi-stage scenario. Why enable it if you don't need it? – Ori Jun 09 '11 at 16:28
  • @D.W. You're not going to allow DNS traffic *into* your network, right? You wouldnt consider allowing port 80 to any arbitrary server, right? In addition, if there is no operational or usability reason for it, it just enlarges the attack surface needlessly. – AviD Jun 09 '11 at 21:20
  • 4
    @AviD: however, the Ping packets _are_ useful -- if only as a diagnostic tool from outside. It is a trade-off. – Thomas Pornin Jun 09 '11 at 21:24
  • 3
    @D.W. the question's title is "Security risk of PING?" and this answer is a very good point that should be included. Though this is true, covert channel use isn't the sole reason for blocking ICMP (Frankly, the most common reason behind blocking ICMP is just to complicate reconnaissance attempts). Also, I would definitely bock DNS and HTTP... and i do, aside from my proxy. – Ormis Jun 09 '11 at 21:26
  • 19
    My point is that if you want to stop covert communication, you have to block ALL communication (in both directions, no matter which endpoint initiated the connection). That is clearly absurd. So it is silliness to block ping for purposes of blocking covert communication; even after blocking ping, people will still be able to communicate covertly. It's not a tradeoff between security vs functionality: it's the kind of thing that makes people curse security people, because it breaks functionality with no perceptible security benefit. – D.W. Jun 10 '11 at 03:58
  • ICMP isn't really useful unless you're talking somewhere in the realm of adjacent network infrastructure device or a remote network monitoring device, and in that case I would utilize a technique near what Daniel is responding with. I don't believe it should always be *completely* disabled, but if it's unnecessary, why let anyone use it? – Ori Jun 10 '11 at 04:11
  • 2
    I agree with @Ori - the rule should be "allow only that which is needed" to reduce your vulnerability landscape. Limiting the possible channels means it is easier to monitor them. – Rory Alsop Jun 10 '11 at 23:53
8

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
Daniel Miessler
  • 605
  • 4
  • 3
  • 2
    good answer. However, I don't see it as much of a tradeoff: blocking ping probably brings at most a negligible security benefit. Of course, if you don't need it, go ahead and block it if you want (hey, whitelists are better than blacklists). – D.W. Jun 10 '11 at 04:01
  • ICMP based traceroute isn't the only option though - you can use TCP based traceroute (see 'tcptraceroute' for example) or UDP (which is how Microsoft's tracert works - though this needs inbound ICMP). You can also whitelist some external ICMP targets for network testing and management. – David Scholefield Nov 15 '16 at 10:12
7

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.

While even Nmap Xmas scans are not picked up by Snort/Suricata, let alone SQLi or Javascript based attacks (in any direction), we need to recognize the importance of risks tied to network and application security attacks against modern infrastructure. We should deny, test, and verify any sort of footprinting traffic -- and I don't see why this wouldn't include ICMP but really it doesn't start or stop there.

atdre
  • 18,885
  • 6
  • 58
  • 107
5

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.

Konrad Borowski
  • 173
  • 7
Christopher Alfred
  • 51
  • 1
  • 1
4

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

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 1
    Very true, especially when you consider that ping's utility matters for availability, that oft-forgotten [brother of confidentiality and integrity](http://en.wikipedia.org/wiki/CIA_triad#Key_concepts). – Gilles 'SO- stop being evil' Jan 25 '12 at 20:46
-4

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.

Community
  • 1
TZubiri
  • 113
  • 6
  • 1
    `MUST` means nothing. What is the IETF going to do if I disobey? They probably don't have the budget to hire a lawyer or a hitman. Furthermore, a ton of consumer routers have default settings to drop incoming ICMP messages, and they all don't explode either. –  Mar 10 '20 at 08:58
  • We are talking about the group that designed and standarized icmp along with tcp, ip, dns, etc... Ignore at your peril – TZubiri Mar 10 '20 at 09:00
  • 3
    This answers exactly none of my points. What is the downside of disabling it? What is the downside of disobedience? You act as if the internet would break down, but it doesn't. –  Mar 10 '20 at 09:01
  • I understand your concern, it's an appeal to authority, but it works for me. I have no interest in digging deeper, an appeal to this authority seems like a good depth limit to any search of knowledge of mine. And it answers the original question, is it common practice to disable ICMP? no, is there any risk to ICMP? no. – TZubiri Mar 10 '20 at 09:03
  • 2
    The RFC is notoriously old though. This answer could be improved with the addition of https://tools.ietf.org/html/rfc5927 . There is no change to the MUST status, but it goes to lengths to describe the possible theoretical risks of icmp. – TZubiri Mar 10 '20 at 09:10
  • I added a link to RFC 5927 which links to more security risk discussion than you'll ever need. – TZubiri Mar 10 '20 at 09:16
  • 3
    Tomas - but you have written the false statement "ICMP is safe" - like anything else, it is not safe. It presents a risk that should be understood in any particular context. – Rory Alsop Mar 10 '20 at 11:46
  • We have to be able to label at least one thing as safe, otherwise the answer to any question "Is this considered safe?" will be "everything has a risk". I'm putting my foot down on ICMP. – TZubiri Mar 10 '20 at 12:08
  • 2
    This does not answer the question, and relies on a massive error in logic. And you are misinterpreting "risk" as "safe". We do ***not*** have to label *anything* as "safe". The question literally is "what are the risks?" You completely avoid that altogether. – schroeder Mar 10 '20 at 12:21
  • 2
    "Ignore at your peril" - ok - what peril? What's the ***risk***? – schroeder Mar 10 '20 at 12:23
  • 1
    RFC 5927 is ***not*** "more security risk discussion than you'll ever need". It lightly covers one small dimension of one type of risk. – schroeder Mar 10 '20 at 12:41
  • Perhaps a compromise is to make everything in a subnet pingable by virtual hosts or the router. – makerofthings7 Mar 10 '20 at 12:56
  • Safe is the absence of risks, they are antonyms. The risk of fearing safe features is that you will be diverted from true risks. It's like those terrible builds that yield 5 thousand warnings, you miss the important ones if you can't filter out the trivial ones. – TZubiri Mar 10 '20 at 13:00
  • @TomasZubiri you do not understand the concept of risk, and that still does not help to answer the question, "what are the risks?" This is a non-answer. – schroeder Mar 10 '20 at 13:24