Are ICMP packets not important for a hosted machine?

[shimi]

On Wed, Oct 20, 2010 at 7:00 AM, Shachar Shemesh <shachar at shemesh.biz>wrote:

>  On 19/10/10 20:56, shimi wrote:
>
>
> 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?
>
>
No, merely wasting upstream bandwidth, for every packet being received, an
(almost) equal packet is being sent back. Why waste upstream bandwidth and
help the attacker saturate your bandwidth / CPU resources?

(and yes, there is the more severe type of amplified attack, but I was
talking on even more trivial stuff...)

>   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.
>
>
I may be. This type of filtering is probably standard in every dedicated
server hosting package offering I have received on the past 5+ years... it's
usually called "shared firewall service".

>
>
> 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.
>
>
That's a POV. For me, anything I can solve without requiring "a favor" from
the ISP (when was the last time an ISP did what you wanted?), is "annoying".
Especially when the behavior is easy to detect... That's contrary to stuff
that gets imposed on you that you can't do anything about[*]; For example: a
QoS policy dedicating 99% of the ISP Intl's bandwidth to HTTP/S traffic, and
the rest %1 for everything else, including SSH, rsync, CVS etc. (starting
6pm until 1am, forget on running TCP connections for non web traffic...).
‎That's far beyond annoying :)

-- Shimi

[*] Yes, I know that you can use httptunnel to pipe SOCKS requests to a
machine outside the country to escape such a QoS limitation. But that costs
you more money (unless you have some generous friend abroad...), and you
paid for "Internet", not just "HTTP service".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20101020/d6236f5d/attachment.html>