Are ICMP packets not important for a hosted machine?

[Shachar Shemesh]

On 19/10/10 20:56, shimi wrote:

> See inline,
>
> On Tue, Oct 19, 2010 at 7:23 PM, Ron Varburg <linux-il at hotmail.com 
> <mailto:linux-il at hotmail.com>> wrote:
>
>
>
>     A Hosting service is blocking pings from the Internet to the
>     hosted servers.
>     It is possible to ping from the hosted servers to anywhere on the
>     Internet,
>     assuming that the packets are not dropped somewhere else, ofcourse.
>     1. Why would the hosting service bother with such a blockage?
>
>
> Mitigating some of a Denial Of Service attack. If a machine replies to 
> ICMP Echo DoS attack, it doubles the amount of traffic it has to handle.
Despite an extensivish knowledge in DoS attack types, I have no idea 
what you are talking about. Are you referring to a traffic multiplying 
attack (in which case it is a third party that gets the multiple 
packets), which can be blocked by blocking the broadcast address, or is 
this some form in which the machine itself has to handle more traffic 
merely because "ping" is open?
> Since blocking ICMP Echo has no actual effect on any other thing 
> beside of checking if a machine is alive, they believe the benefit of 
> not "participating" in a DoS attack outweights the lack of ability to 
> ping-test the machine. (not to mention that it may be filtering just 
> *some* of the ICMP Echo packets, and may be responding to ICMP Echo if 
> sent from a limited set of IPs (for example a monitoring machine 
> and/or the sysadmin's IP pool...)
I think you are over estimating the amount of firewall resources hosting 
is willing to allocate to your machine.
>
>     2. Is it reasonable to assume that more ICMP packets are blocked?
>
>
> Yes, many people block ICMP alltogether, not realizing that ICMP Echo 
> and ICMP Echo Reply are not the only type of ICMP messages, and just 
> block any IP packet that has ICMP in it.
>
>     3. What are the implications of such a blockage? In particular,
>       assuming that each hop in a random path takes care to assure
>       connectivity to any nearest hop, one might think that ICMP packets
>       are not important and hardly used.
>
>
> The annoying ones:
> PMTU[1] breaks. If any router / medium in the middle cannot support 
> the client/server MTU (typically - 1500), and a packet with the DF[2] 
> flag is sent, it will be dropped "silently" and the sender wouldn't 
> know, and re-transmit the packet until the connection times out and dies.
>
I'm not sure "annoying" is the right word. This type of breakage is 
called "PMTU black hole", and prevents ANY type of traffic from arriving 
at the machine, under some circumstances. In fact, this problem is so 
prevalent that, when installing ADSL, you are instructed to squash the 
MSS, just so you can communicate with such broken setups.
>
> Hope I didn't miss anything :)
>
If they wanted to block traffic multiplying, blocking ICMPs to the 
directed broadcast address would have been enough. There are some 
dangerous ICMP messages (type 5 code 1 - ICMP redirect is one example 
that pops to mind - it's an ICMP message that alters the recipient's 
routing table), which it makes sense to block.

In general, some ICMP messages are entirely benign (type 8 - echo 
request or type 11 - time exceeded), some are required (type 3 - 
destination unreachable, of which blocking code 4 causes the PMTU black 
hole syndrome discussed above), some are dangerous (type 5), and some 
are both (type 4 - source quench). I have to admit setting up a firewall 
regarding ICMPs is not an easy task.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20101020/1d16882b/attachment.html>