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)?
-
5I 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.joshCommented Jun 8, 2011 at 21:31
-
3If ping is a security risk to your network, it has bigger issues than security :P– NavinCommented Jul 8, 2016 at 0:19
Add a comment
|
7 Answers
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).
answered Jun 8, 2011 at 18:22
-
1this is not completely correct, see @Ori's answer for some additional information.– AviD ♦Commented Jun 9, 2011 at 21:18
-
2I 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– atdreCommented Jun 10, 2011 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.– OriCommented Jun 12, 2011 at 6:23
-
1Ping 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.– kasperdCommented Feb 4, 2015 at 21:21
-
1
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
-
22So 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.Commented Jun 9, 2011 at 7:29
-
3It'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?– OriCommented Jun 9, 2011 at 16:28
-
4@AviD: however, the Ping packets are useful -- if only as a diagnostic tool from outside. It is a trade-off. Commented Jun 9, 2011 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.– OrmisCommented Jun 9, 2011 at 21:26
-
19My 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.Commented Jun 10, 2011 at 3:58
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
-
2good 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.Commented Jun 10, 2011 at 4: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. Commented Nov 15, 2016 at 10:12
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.
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
answered Jan 25, 2012 at 17:08
-
1Very true, especially when you consider that ping's utility matters for availability, that oft-forgotten brother of confidentiality and integrity. Commented Jan 25, 2012 at 20:46
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.
-
3This 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.– user163495Commented Mar 10, 2020 at 9:01
-
2The RFC is notoriously old though. This answer could be improved with the addition of 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.– TZubiriCommented Mar 10, 2020 at 9:10
-
3Tomas - 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 ♦Commented Mar 10, 2020 at 11:46
-
2This 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 ♦Commented Mar 10, 2020 at 12:21
-
2"Ignore at your peril" - ok - what peril? What's the risk?– schroeder ♦Commented Mar 10, 2020 at 12:23