Re: Should or shouldn't block public ping to a website

I think the answer should be a bit more nuanced.  The ICMP protocol offers some very useful and in some cases, required,
functionality, so you should probably have a stance of allowing some ICMP types and not others.  Here's a list of all
the types currently provided by ICMPv4 (condensed from this IANA XML registry
<http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml>):

*Type
* 	*Description
* 	*Reference(s)
*
Type 0 	Echo Reply 	(RFC792)
Type 1 	Unassigned 	(JBP)
Type 2 	Unassigned 	(JBP)
Type 3 	Destination Unreachable 	(RFC792)
Type 4 	Source Quench
	(RFC792, generation of deprecated in RFC1812)
Type 5 	Redirect 	(RFC792)
Type 6 	Alternate Host Address 	(JBP)
Type 7 	Unassigned 	(JBP)
Type 8 	Echo 	(RFC792)
Type 9 	Router Advertisement 	(RFC1256)
Type 10 	Router Solicitation 	(RFC1256)
Type 11 	Time Exceeded 	(RFC792)
Type 12 	Parameter Problem 	(RFC792)
Type 13 	Timestamp 	(RFC792)
Type 14 	Timestamp Reply 	(RFC792)
Type 15 	Information Request 	(RFC792)
Type 16 	Information Reply 	(RFC792)
Type 17 	Address Mask Request 	(RFC950)
Type 18 	Address Mask Reply 	(RFC950)
Type 19 	Reserved (for Security) 	(Solo)
Type 20-29 	Reserved (for Robustness Experiment) 	(ZSu)
Type 30 	Traceroute 	(RFC1393)
Type 31 	Datagram Conversion Error 	(RFC1475)
Type 32 	Mobile Host Redirect 	(David_Johnson)
Type 33 	IPv6 Where-Are-You 	(Simpson)
Type 34 	IPv6 I-Am-Here 	(Simpson)
Type 35 	Mobile Registration Request 	(Simpson)
Type 36 	Mobile Registration Reply 	(Simpson)
Type 37 	Domain Name Request 	(RFC1788)
Type 38 	Domain Name Reply 	(RFC1788)
Type 39 	SKIP 	(Markson)
Type 40 	Photuris 	(RFC2521)
Type 41 	ICMP messages utilized by experimental mobility protocols such as Seamoby 	(RFC4065)
Type 42-255 	Reserved 	(JBP)


Most of these ICMP types are not necessary for a website on the Internet to expose and several are quite dangerous
(which has led to the "block all ICMP" recommendations in security circles).  Several of the ICMP message types *are*
very useful and are also fairly safe to allow, a couple ICMP message types are required in some circumstances to make
the Internet work.  These are:

*ICMP Message Type
* 	*What it's good for
* 	*Risks for a public website IP
*
0
	Echo (ping) reply, allow incoming to let your server ping stuff on the other side of the firewall and allow outbound to
allow your server to respond to inbound pings.
	Protocol parsing errors, DoS, could make remote reconnaissance of your network easier.
3
	Required outbound for Path MTU Discovery to work for clients contacting your web server.  If your web server needs to
contact arbitrary sites on the Internet (not recommended), then you'd need to allow inbound as well.  Note: ICMP Type 3
has a number of "Codes" under it.  To enable PMTUD, you only need to allow Type 3, Code 4 "fragmentation needed and Do
not Fragment bit set" outbound.  If you have services that require access to arbitrary sites on the Internet, you should
probably allow some Type 3 messages inbound to those hosts or accept that the only way you can detect failures is a TCP
timeout or timeout in your application.
	Protocol parsing errors, DoS, if more codes are allowed outbound, remote reconnaissance of your network may be easier. 
If allowed inbound, spoofed unreachable packets could be used to block your server's responses to users by someone in
the path between you.
8
	Echo (ping) request, allow outgoing to let your server ping stuff on the other side of the firewall and allow inbound
to allow your server to respond to inbound pings.  Be sure to only allow pings to specific host IP addresses or ranges. 
The "Smurf Attack" uses an ICMP echo request to a broadcast address on your network to amplify the DoS attack.
	Protocol parsing errors, DoS (smurf attack), could make remote reconnaissance of your network easier.
11
	Allow outbound to enable others to traceroute to you, allow inbound to enable your server to traceroute out (not
recommended, you should use dedicated troubleshooting host, the firewall,  or a router to do these checks)
	Protocol parsing errors, DoS, could make remote reconnaissance of your network easier.


The risks listed are very minimal for these ICMP message types.  A "protocol parsing error" risk is very unlikely in
code that's been in service for many years.  The "DoS" potential is pretty minimal, since you'd only respond with a
single ICMP packet of about the same size as the attacker sent (except in the "Smurf attack" case).  Any attacker would
be looking for better amplification effects, such as spoofing an HTTP or DNS request which allows them to send a few
small packets and, if they choose the right URL or DNS record, make you send a huge response.  The remote reconnaissance
risk is generally small, as long as you only allow ICMP to hosts that are supposed to be publicly visible anyway.

The implementation of IPv6 makes the "no ICMP" stance unworkable, once you transition, since PMTUD is a required part of
the protocol, no longer optional.

One of the primary reasons for the "no ICMP" stance was the "Ping of Death" attack.  Unfortunately, this attack could
have been implemented using just about any IP based protocol, it was just first implemented using ICMP and, again,
unfortunately, several operating systems had severe bugs in fragmentation handling that could cause a system crash.  No
current operating system should be vulnerable to that fragmentation bug.

The actually dangerous ICMP message types that should be blocked on your borders:
*Type
* 	*Risk
*
4
	Source quench can be easily spoofed and it's use has been deprecated.
5,6
	Redirects are also easily spoofed and can be used to control routing on your network.
9,10
	Router advertisement/Solicitation can be used to control routing on your network.
18
	Address mask reply could be used to control routing on your network.


All of the other ICMP types should probably be blocked for safety's sake, unless you have a good reason to allow them. 
Many are reserved or rarely used and there may be bugs in the IP stacks software that just haven’t been found yet, or
they leak information about your network that nobody else needs to know.

JMH

On 09/06/2011 11:15 PM, ShiYih Lye wrote:
> hi,
>
> What Todd said is pretty true, and that is what playing in my mind,
> "what does blocking ICMP ping from public will buy me ?"
...
> I think there is not much benefit of dropping ICMP from the public
> compare with the bones it gives, at least for a ebusiness website,
> doesn't it ? Anyone having different view is most welcome to chip in
> your thought :)
>
> Regards,
> Lye



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------