Nico Kadel-Garcia wrote:
> Yup. That's why it's common to drop at external firewalls and blocked
> by NAT from reaching inside your network, to protect less thoroughly
> protected and critical hosts from distributed denial of service (DDOS)
> such as the now classic "ping flood" attack. There is generally no
> good reason to allow external ICMP packets into your local network,
> except maybe to allow an external monitoring system or VPN connection
> to verify the presence of a few exposed hosts.
This is a widely held opinion that I strongly disagree with.
Blocking all ICMP is not only not needed, but it is not
conforming to Internet protocol requirements (RFC 1122, 3.2.2)
and makes headaches for sysadmins who have to troubleshoot
network issues. Wikipedia puts it succinctly:
Many network security devices block all ICMP messages for
perceived security benefits, including the errors that are
necessary for the proper operation of PMTUD. This can result in
connections that complete the TCP three-way handshake correctly,
but then hang when data is transferred. This state is referred
to as a black hole connection.
Some implementations of PMTUD attempt to prevent this problem by
inferring that large payload packets have been dropped due to
MTU rather than because of link congestion. However, in order
for the Transmission Control Protocol (TCP) to operate most
efficiently, ICMP Unreachable messages (type 3) should be
permitted. A robust method for PMTUD that relies on TCP or
another protocol to probe the path with progressively larger
packets has been standardized in RFC 4821.
http://en.wikipedia.org/wiki/Path_MTU_Discovery
--
Charles Polisher