Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
3  
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 8 '11 at 21:31

5 Answers 5

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

share|improve this answer
    
this is not completely correct, see @Ori's answer for some additional information. –  AviD Jun 9 '11 at 21:18
1  
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 -- rfc-ignorant.org –  atdre Jun 10 '11 at 20:39
    
@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 6:23

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

share|improve this answer
5  
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 9 '11 at 7:29
2  
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 9 '11 at 16:28
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 9 '11 at 21:26
4  
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 3:58
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

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
share|improve this answer
    
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 4:01

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.

share|improve this answer

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

share|improve this answer
    
Very true, especially when you consider that ping's utility matters for availability, that oft-forgotten brother of confidentiality and integrity. –  Gilles Jan 25 '12 at 20:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.