Security Incidents: Re: Idiotic question

[woods () MOST WEIRD COM (Greg A. Woods)]

[ On Thursday, March 2, 2000 at 08:49:06 (-0500), Donald McLachlan wrote: ]
> Subject: Re: Idiotic question
>
> This topic is of interest to me.  What are those other ICMP type/codes,
> and why are they important?
I think ICMP_SOURCEQUENCH is useful, though it can probably be abused.
It should probably be rate filtered instead of blocked.

Certainly all of the ICMP_UNREACH group are necessary for fully correct
functioning of TCP stacks.  Their arrival should probably be rate
filtered, but the rate might need to be adaptable to match the rate of
outgoing SYN packets or something similar.  Obviously the NEEDFRAG
responses are the most important and the most commonly needed type of
ICMP traffic.  I always find it particularly frustrating when some
remote firewall allows ADMIN_PROHIBIT through from its servers but won't
let my ADMIN_PROHIBIT packets back through to them.

The ICMP_TIMXCEED group are probably necessary for some stacks too.

ICMP_TSTAMP and its reply should be of no harm (unless they are part of
a DoS, so they should be rate filtered).

Some people will argue that ICMP_MASKREQ and more specifically its reply
would reveal sensitive information, but I would argue this information
is potentially public anyway.  Similar for ICMP_IREQ and its reply where
implemented.  I'm fairly certain I've seen the former generated
automatically (though I don't know by what or for what purpose) but
never the latter.

ICMP_REDIRECT might be necessary but you don't want to accept them
arbitrarily of course (probably only on inside interfaces).

(BTW, I'm using the names from a BSD <netinet/ip_icmp.h>.)

> I suspect there are other people wondering this so replying to the list
> might be good.
That's quite likely, though I continue to be surprised and dismayed by
the number of people operating firewalls who don't understand even the
basics of the protocols they are using.

What's important to keep in mind w.r.t. ICMP is the risk analysis.  I
think most people will agree that biggest threats of ICMP continue to be
with DoS attacks, not with actual penetrations or loss of privacy due
directly to ICMP, or even with ICMP as accomplices to more complex
penetrations and theft of secrets.  As such the appropriate response to
this threat isn't to block all such traffic but rather to ensure that it
cannot pose a DoS (by rate filtering, for example).  Certainly some
types of ICMP packets can also pose a threat to normall traffic (such as
a timely ICMP_UNREACH, a faked ICMP_REDIRECT, etc.) and dealing with
these while not blocking all traffic is of course much harder if you
only focus on the ICMP layer.  However some types of attacks that might
occur can easily be mitigated at the application layer (and some might
be automatically mitigated either by the current default behaviour of an
application or even by the expected behaviour of a user who gets an
unexpected runtime failure).  Given this I would say that ICMP_UNREACH
at least poses a quite low risk.

The other thing to keep in mind is the difference between handling these
kinds of threats on a firewall and with handling them on the server(s).
Many people take a one-dimentional view of network security and
mistakenly believe they can secure themselves with the "simple"
application of a firewall and leave it at that.  Blocking all ICMP on
the firewall while allowing TCP connections through from inside hosts is
clearly where the most trouble occurs (esp. with path-MTU-discovery).
On the other hand blocking all traffic at the firewall and using the
firewall as a bastion host or using application-level gateways on the
firewall will pose an entirely different scenario and so long as the
firewall itself continues to accept appropriate ICMP packets then things
should work reasonably well.

Hopefully someday soon the types of built-in response rate filtering,
such as is already available in FreeBSD, will be more commonly available
and will help reduce the paranoia about ICMP.  I'm hoping to see rate
filtering in firewalls to control the passage of this kind of traffic
through to internal hosts, but I'm not holding my breath for it....   :-)

--
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>