<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: rtl;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bidimailui-detected-decoding-type="UTF-8" bgcolor="#ffffff"
text="#000000">
<p style="direction: ltr;">On 19/10/10 20:56, shimi wrote:<br>
</p>
<blockquote style="direction: ltr;"
cite="mid:AANLkTik-+Mkpd3B9oBuZJRyx5GcaCe5Hc8wA_WLiEW8D@mail.gmail.com"
type="cite">
<div style="direction: ltr;" dir="ltr">See inline,<br>
<br>
<div style="direction: ltr;" class="gmail_quote">On Tue, Oct 19, 2010
at 7:23 PM, Ron Varburg <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:linux-il@hotmail.com">linux-il@hotmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; direction: ltr;"><br>
<br>
A Hosting service is blocking pings from the Internet to the hosted
servers.<br>
It is possible to ping from the hosted servers to anywhere on the
Internet,<br>
assuming that the packets are not dropped somewhere else, ofcourse.<br>
1. Why would the hosting service bother with such a blockage?<br>
</blockquote>
<div style="direction: ltr;"><br>
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.</div>
</div>
</div>
</blockquote>
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?<br>
<blockquote style="direction: ltr;"
cite="mid:AANLkTik-+Mkpd3B9oBuZJRyx5GcaCe5Hc8wA_WLiEW8D@mail.gmail.com"
type="cite">
<div style="direction: ltr;" dir="ltr">
<div style="direction: ltr;" class="gmail_quote">
<div style="direction: ltr;"> 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...)<br>
</div>
</div>
</div>
</blockquote>
I think you are over estimating the amount of firewall resources
hosting is willing to allocate to your machine.<br>
<blockquote style="direction: ltr;"
cite="mid:AANLkTik-+Mkpd3B9oBuZJRyx5GcaCe5Hc8wA_WLiEW8D@mail.gmail.com"
type="cite">
<div style="direction: ltr;" dir="ltr">
<div style="direction: ltr;" class="gmail_quote">
<div style="direction: ltr;"> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; direction: ltr;">2.
Is it reasonable to assume that more ICMP packets are blocked?<br>
</blockquote>
<div style="direction: ltr;"><br>
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.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; direction: ltr;">3.
What are the implications of such a blockage? In particular,<br>
assuming that each hop in a random path takes care to assure<br>
connectivity to any nearest hop, one might think that ICMP packets<br>
are not important and hardly used.<br>
<br>
</blockquote>
<div style="direction: ltr;"><br>
The annoying ones: <br>
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.<br>
<br>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote style="direction: ltr;"
cite="mid:AANLkTik-+Mkpd3B9oBuZJRyx5GcaCe5Hc8wA_WLiEW8D@mail.gmail.com"
type="cite">
<div style="direction: ltr;" dir="ltr">
<div style="direction: ltr;" class="gmail_quote">
<div style="direction: ltr;"><br>
Hope I didn't miss anything :)<br>
<br>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Shachar<br>
<br>
<pre style="direction: ltr;" class="moz-signature" cols="72">--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>
</pre>
</body>
</html>