how to disable ICMP: "Echo Request" (ping)

On Wed, 20 Jul 2005 12:20:19 +0200, Michael Heiming <michael+USENET@www.heiming.de> wrote:
>
> A problems is breaking PMTUD (Path MTU Discovery) as it needs
> ICMP (type 3+4 or so) to work probably.

Some of us are stuck behind ISPs that kill ICMPs, there are ways
around MTU discovery, a search will find them. For example my
access to 'net has 'blackhole' for packets in a particular size
range of about 20 bytes, so one discovers that range and adjusts
their system, not difficult. Or simply go to the Cisco low end
of the MSS range. Less trouble than discovery?

Then we have:
# RFC-1122 3.2.2.6 "Echo Request/Reply: RFC-792: Every host
# MUST implement an ICMP Echo server function that receives
# Echo Requests and sends corresponding Echo Replies."

Discover the answer, killing ping does not reduce 'noise' hitting
the firewall. On the other hand it is prudent to limit the response
rate to pings, one extra rule in the firewall, again, not difficult.

Grant.

In article <9bdee5f7.0507200131.53ad3b1a@posting.google.com >,
Hans Schulze <hans_schulze98@yahoo.de> wrote:
:Michael Heiming <michael+USENET@www.heiming.de> wrote in message news:<j99vq2-eoc.ln1@news.heiming.de>...
:> In comp.os.linux.security John Peach <jpeach@globix.com>:
:> > On Tue, 19 Jul 2005 13:38:41 +0200, Michael Heiming wrote:
:>
:> >> In comp.os.linux.security Hans Schulze <hans_schulze98@yahoo.de>:
:> >>> title says it. Have already configured firewall to disallow everything
:> >>> but ICMP still coming thru. How do I stop it? All side effects of
:> >>> disabling ICMP desired.
:> >>
:> >> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
:> >>
:> >> Alternatively, 'man sysctl' + "SEE ALSO".
:> >>
:> > You really do not want to block all ICMP traffic - at the very least you
:> > should allow type 3, otherwise you may get strange effects.
:>
:> Sure, but the OP asked for it and I can't be bothered to talk
:> about the same things over and over again, perhaps he'll get a
:> clue once he suffers from possible effects.;)
:
:Now that you made me curious - what strange effects? There is no
:incoming traffic, just outbound-initiated. Maybe someone can point me
:to a web page or so with adverse consequences.

ICMP types 3, 11, and 12 are error responses. If you disable those any
connection errors will result in a rather lengthy timeout rather than an
immediate, meaningful response.

--
Bob Nichols AT comcast.net I am "rnichols42"

Hans Schulze wrote:

> Michael Heiming <michael+USENET@www.heiming.de> wrote in message
> news:<j99vq2-eoc.ln1@news.heiming.de>...
>> In comp.os.linux.security John Peach <jpeach@globix.com>:
>> > On Tue, 19 Jul 2005 13:38:41 +0200, Michael Heiming wrote:
>>
>> >> In comp.os.linux.security Hans Schulze <hans_schulze98@yahoo.de>:
>> >>> title says it. Have already configured firewall to disallow
>> >>> everything but ICMP still coming thru. How do I stop it? All side
>> >>> effects of disabling ICMP desired.
>> >>
>> >> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
>> >>
>> >> Alternatively, 'man sysctl' + "SEE ALSO".
>> >>
>> > You really do not want to block all ICMP traffic - at the very least
>> > you should allow type 3, otherwise you may get strange effects.
>>
>> Sure, but the OP asked for it and I can't be bothered to talk
>> about the same things over and over again, perhaps he'll get a
>> clue once he suffers from possible effects.;)
>
> Now that you made me curious - what strange effects? There is no
> incoming traffic, just outbound-initiated. Maybe someone can point me
> to a web page or so with adverse consequences.
What you're trying to avoid is called a Path MTU Discovery Black Hole. You
can find out quite a bit about it with a quick google. I know there was a
good paper on it from a Usenix LISA conference a couple or three years ago.

Basically, you should be allow ICMP type 3 code 4. These packets are safe.
Pretty much nothing else in ICMP is.

In the Usenet newsgroup comp.os.linux.security, in article
<Hk1Ee.102$CS2.16463@news.uswest.net>, Greg Metcalfe wrote:

>What you're trying to avoid is called a Path MTU Discovery Black Hole. You
>can find out quite a bit about it with a quick google. I know there was a
>good paper on it from a Usenix LISA conference a couple or three years ago.

1191 Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990.
(Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
STANDARD)

1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles.
March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL)

2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
(Format: TXT=30976 bytes) (Status: INFORMATIONAL)

>Basically, you should be allow ICMP type 3 code 4. These packets are safe.

You may want to look at the Bugtraq mailing list for the past couple of
days. There is "a discussion" of a denial of service attack relating to
this. If you don't want to subscribe, grab a list of news groups from
your news server and look for the word bugtraq - there are several groups
that mirror the lists, such as mailing.unix.bugtraq or muc.lists.bugtraq.

>Pretty much nothing else in ICMP is.

I don't know if I'd go quite that far.

Old guy

Moe Trin wrote:

> In the Usenet newsgroup comp.os.linux.security, in article
> <Hk1Ee.102$CS2.16463@news.uswest.net>, Greg Metcalfe wrote:
>
>>What you're trying to avoid is called a Path MTU Discovery Black Hole. You
>>can find out quite a bit about it with a quick google. I know there was a
>>good paper on it from a Usenix LISA conference a couple or three years
>>ago.
>
> 1191 Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990.
> (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
> STANDARD)
>
> 1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles.
> March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL)
>
> 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
> (Format: TXT=30976 bytes) (Status: INFORMATIONAL)
>
>>Basically, you should be allow ICMP type 3 code 4. These packets are safe.
>
> You may want to look at the Bugtraq mailing list for the past couple of
> days. There is "a discussion" of a denial of service attack relating to
> this. If you don't want to subscribe, grab a list of news groups from
> your news server and look for the word bugtraq - there are several groups
> that mirror the lists, such as mailing.unix.bugtraq or muc.lists.bugtraq.
>
>>Pretty much nothing else in ICMP is.
>
> I don't know if I'd go quite that far.
>
> Old guy
Thanks for the bugtraq references. I haven't been by there in a few days. A
couple of ICMP references from SANS (first two are the ones I was thinking
of a couple of days ago):

The LISA paper
http://www.usenix.org/events/lisa02/...nderberg_html/

Descriptions of many ICMP attacks, by type:code
http://www.giac.org/practical/gsec/L..._Eden_GSEC.pdf

Another good reference to ICMP to Bad Things that can be done via ICMP. I
would argue that some of the items here can useful, though. The old
argument of any tool may be used for god or ill.
http://www.sans.org/resources/idfaq/icmp_misuse.php

In the Usenet newsgroup comp.os.linux.security, in article
<Z8zEe.57$9C5.16319@news.uswest.net>, Greg Metcalfe wrote:

>A couple of ICMP references from SANS (first two are the ones I was
>thinking of a couple of days ago):
>
>The LISA paper
>http://www.usenix.org/events/lisa02/...rs/vanderberg/
vanderberg_html/

Looks good.

>Descriptions of many ICMP attacks, by type:code
>http://www.giac.org/practical/gsec/L..._Eden_GSEC.pdf

I can't seem to reach that.

>Another good reference to ICMP to Bad Things that can be done via ICMP. I
>would argue that some of the items here can useful, though. The old
>argument of any tool may be used for god or ill.
>http://www.sans.org/resources/idfaq/icmp_misuse.php

That paper is a bit dated, though still good reading. It does depend on
ICMP being open at the firewall, something that a lot of places don't
quite permit. There _used to be_ a web page at NSA that gave firewall
recommendations - http://www.nsa.gov/snac/index.html which is 404
compliant now. The page actually was based on page 89 of an unspecified
version of the Cisco Security Guide. Briefly, it said:

deny icmp any any echo
deny icmp any any redirect
deny icmp any any mask-request
permit icmp any
(allow pings where needed obviously)

Translated, that is block Type 8, 5, 17. I disagree, suggesting that you
_ALLOW_ 0, 3, 4 and 11 INBOUND, 3, 4, and 8 OUTBOUND, while denying all else.
Some may consider type 4 (Source Quench) as undesirable (possible DOS). YMMV
Likewise, some may wish to restrict the Codes of Type 3 in and/or out.

We also block a _LOT_ of UDP (basically allowing DNS outbound only from the
DNS servers, and not allowing external queries of the internal DNS servers.
One trick I am aware of is that our perimeter firewall port shifts outbound
UDP to source ports above (perhaps) 1050 or 1100. This allows our upstream to
drop inbound 1025/udp and friends, which eliminates microsoft messenger spam.
There's more obviously, but I'm under NDA. My home setup allows UDP DNS out,
and back, and that's it.

Regarding operating system fingerprinting - if you can connect to the host,
there are a number of really dumb things that can be observed to get a good
idea of what the remote is - way beyond the Ofir Arkin paper or the
documentation in nmap. "p0f" comes to mind.

Old guy