Ok to let all ICMP traffic through firewall?

My question is Should a firewall let all ICMP traffic through because
there is no real risk if they do?

+++++

Here is the thinking behind my question: Robin Walker's cable modem
webpages at
<http://homepage.ntlworld.com/robin.d.h.walker/cmtips/index.html>
look to me as if they are technically sound. But they are a few
years old. I would like to know what people think about the advice
he gives about ICMP traffic and if it is still true these days.

He suggests that firewalls should let all ICMP traffic through and
that there is no real risk if they do that. At
http://snipurl.com/hvox he writes the following section. I have cut
it down a bit.


------------------- START QUOTE -----------------

STEALTH-MODE FIREWALLS CONSIDERED HARMFUL

Some firewalls have a hiding mechanism they call stealth. ... In
stealth mode, the firewall causes the PC just to ignore incoming
connection attempts, rather than rejecting them, as would be normal
for incoming connection attempts to closed ports.

.... causes some difficulties. For a start, Internet standard RFC 1122
states categorically about ICMP Echoes (ping):

"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."

So you are strongly advised not to apply stealth techniques to the
ICMP protocol.

A commonly heard objection to allowing ICMP Echo Replies is that it
gives away information to hackers that there is a live connection on
this IP address. Such objections are not well-founded, and can be
safely ignored.

There is no evidence in practice that any hacker has been aided by
the presence of an ICMP Echo Reply.

Hackers do not typically write code that tests an address with ICMP
Echo before launching a hostile probe: they always send the hostile
probe directly: either it works or it doesn't, and information from
ICMP adds nothing to the analysis.

------------------- END QUOTE -----------------

So Should a firewall let all ICMP traffic through? Is it ok to do
that?

In article <96D9EC61DFA1E71F3M4@66.250.146.159>, (E-Mail Removed)
says...
> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?

The common sense rule is to LET NOTHING IN that doesn't have a good
reason to be let in.

Why do you want to take a minimal risk if you don't have too?

--

(E-Mail Removed)
remove 999 in order to email me

On Thu, 22 Sep 2005 22:19:07 UTC, Leythos <(E-Mail Removed)> wrote:

> In article <96D9EC61DFA1E71F3M4@66.250.146.159>, (E-Mail Removed)
> says...
> > My question is Should a firewall let all ICMP traffic through because
> > there is no real risk if they do?
>
> The common sense rule is to LET NOTHING IN that doesn't have a good
> reason to be let in.

In practice, you need to let a few ICMP messages through, then. For
example, source quench and destination unreachable.

--
[ 7'ism - a condition by which the sufferer experiences an inability
to give concise answers, express reasoned argument or opinion.
Usually accompanied by silly noises and gestures - incurable, early
euthanasia recommended. ]

Franklin <(E-Mail Removed)> wrote:
> My question is Should a firewall let all ICMP traffic through
> because there is no real risk if they do?

No, because some ICMP messages aren't useful. However blocking all
ICMP is throwing the baby out with the bathwater and will cause more
bother than not blocking anything.

I would suggest allowing ICMP Echo and Echo Reply (so ping works),
Destination Unreachable (which includes "fragmentation required",
essential for PMTUD to work) and Time Exceeded (so traceroute works.)
Everything else looks to be fair game to drop.

While I'm suggesting firewall rules, can people also not silently drop
SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
stall while waiting for a response. The firewall user is usually the
first to complain that it's taking ages to connect to a certain remote
server.

--
PGP key ID E85DC776 - finger (E-Mail Removed) for full key
/:.*posting.google.com.*/HX-Trace:+j

In article <176uZD2KcidF-pn2-(E-Mail Removed)>,
Bob Eager <(E-Mail Removed)> wrote:
:In practice, you need to let a few ICMP messages through, then. For
:example, source quench and destination unreachable.

In practice, crackers will send you unsolicited source quenches,
either as a side effect of them DoS'ing the host with forged packets,
or else with the hope of DoS'ing you by interfering with your flow
of traffic to other locations.

In practice, you don't need to listen to source quench. If you
are sending data too quickly for a router, the router will drop
some of the traffic. If the traffic was TCP then the normal TCP
recovery mechanisms will kick in and will act to slow down your
rate of transmission. If the traffic was UDP or anything other
"unreliable" protocol, then by definition the transmissions are
expected to be unreliable so dropping the traffic should not be
important. [If it -was- important, then you shouldn't be using an
unreliable transmission protocol.]
--
Goedel's Mail Filter Incompleteness Theorem:
In any sufficiently expressive language, with any fixed set of
email filtering algorithms, there exists at least one spam message
which the algorithms are unable to filter out.

Franklin wrote:

> My question is Should a firewall let all ICMP traffic through because
> there is no real risk if they do?
> [...]
> ------------------- START QUOTE -----------------
>
> STEALTH-MODE FIREWALLS CONSIDERED HARMFUL
> [...]
> So Should a firewall let all ICMP traffic through?

No.

> Is it ok to do that?

No. While the example you quoted from the web page is still correct and
there is nothing wrong with echo request and echo reply and the various
destination unreachable messages the are other icmp messages that should be
filted.

http://seclists.org/lists/bugtraq/2005/May/0122.html

Wolfgang

In article <433331d9$0$32652$(E-Mail Removed)>,
Peter <(E-Mail Removed)> wrote:
:However blocking all
:ICMP is throwing the baby out with the bathwater and will cause more
:bother than not blocking anything.

"more bother" depends on whether you are being deliberately attacked
or not.


:I would suggest allowing ICMP Echo and Echo Reply (so ping works),

Typically, outsiders have no business mapping out exactly which
of your systems exist or are up right now, so dropping most incoming icmp
echo is a common security precaution. Whether to allow icmp echo
to public-facing servers varies with circumstance.

--
If you like, you can repeat the search with the omitted results included.

In article <176uZD2KcidF-pn2-(E-Mail Removed)>, rde42
@spamcop.net says...
> On Thu, 22 Sep 2005 22:19:07 UTC, Leythos <(E-Mail Removed)> wrote:
>
> > In article <96D9EC61DFA1E71F3M4@66.250.146.159>, (E-Mail Removed)
> > says...
> > > My question is Should a firewall let all ICMP traffic through because
> > > there is no real risk if they do?
> >
> > The common sense rule is to LET NOTHING IN that doesn't have a good
> > reason to be let in.
>
> In practice, you need to let a few ICMP messages through, then. For
> example, source quench and destination unreachable.

Wrong, you don't NEED to allow anything. You may FEEL that you do, but
we've got almost 100 networks that don't allow ICMP or anything else
inbound and they work just fine, and we'll not change them.

--

(E-Mail Removed)
remove 999 in order to email me

In article <433331d9$0$32652$(E-Mail Removed)>,
(E-Mail Removed) says...
> Franklin <(E-Mail Removed)> wrote:
> > My question is Should a firewall let all ICMP traffic through
> > because there is no real risk if they do?
>
> No, because some ICMP messages aren't useful. However blocking all
> ICMP is throwing the baby out with the bathwater and will cause more
> bother than not blocking anything.
>
> I would suggest allowing ICMP Echo and Echo Reply (so ping works),
> Destination Unreachable (which includes "fragmentation required",
> essential for PMTUD to work) and Time Exceeded (so traceroute works.)
> Everything else looks to be fair game to drop.
>
> While I'm suggesting firewall rules, can people also not silently drop
> SYNs to port 113 please? All sorts of servers try RFC1413 lookups and
> stall while waiting for a response. The firewall user is usually the
> first to complain that it's taking ages to connect to a certain remote
> server.

There is NO BOTHER - you set the rules and then let them work. You don't
need to allow PING, in fact why the heck would you want to allow PING,
it's not like it's a valid test that your network is alive - we've got
tons of commercial networks that block PING and none of the users even
notice.

Allowing anything inbound, even to the firewall, that doesn't
specifically need to be let in is a bad move.

Allowing in minimal traffic that "might" not be a threat is like
trusting Windows Firewall with File/Printer sharing enabled on a
computer directly connected to the Internet with all of your financial
data stored on it in a text file that is name "ALL MY FINANCIAL
DATA.TXT" sitting in the root.

--

(E-Mail Removed)
remove 999 in order to email me

"Leythos" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <433331d9$0$32652$(E-Mail Removed)>,
> (E-Mail Removed) says...
> > Franklin <(E-Mail Removed)> wrote:
> > > My question is Should a firewall let all ICMP traffic through
> > > because there is no real risk if they do?

<snip>

> You don't
> need to allow PING, in fact why the heck would you want to allow PING,
> it's not like it's a valid test that your network is alive - we've got
> tons of commercial networks that block PING and none of the users even
> notice.

Undoubtedly the case. Although one could quote lots of instances where it's
been damned useful.

Well, *I* certainly can - usually when the web server has had a bit of a
funny turn, and one needs to tell if it's the server behind the firewall
(fat chance of fixing something from an adjacent continent), or whether it's
the ISP playing silly buggers with the connection (marginally more hope of
getting something sorted).

As goes firewalls - I'm sure that most have already seen it, but:
http://www.dilbert.com/comics/dilber...3960050912.gif

--

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!