On Fri, 31 Dec 1999, Dave Wreski wrote:
> Hi all. I'd like to investigate the security implications of the various
> types of ICMP and whether or not to allow them thru a firewall.
I assume you're using a packet filter, since if it was a proxy, you'd
only need to allow said packets to the external interface, and not
through to the internal network, but the following is as applicable to
screening routers around a proxy as it is to packet filters.
ICMP is just like UDP in the "can spoof, can flood" department, though
most of the unreachables need the original packet data to be totally
useful unless your IP implementation is completely broken.
Floods from bogus souce addresses is the most likely DoS attack for ICMP
datagrams. If you're downstream of a relatively slow link, worry about
that. If you're downstream of multiple T-3 circuits, worry less because
if the attacker is doing >90Mb/s you're DoS'ed no matter what.
> I understand many are based on policy decisions, but many (such as source
> redirect) are an obvious deny. Which ones are deprecated? What is the
> most secure configuration possible, yet still maintain the necessary
> services for normal network functionality?
The most secure configuration is to use an application layer gateway and
not allow external to internal or internal to external traffic that
doesn't traverse it. You can get away without any ICMP if you ensure
that you've fragemented packets to their lowest MTU somewhere that can
send ICMP in (and out for the opposite direction), so that TCP path MTU
discovery doesn't break. You'll miss the host/net/port unreachables,
which will mean that connections that aren't successful will hang until
timeout, which can be bad for systems that have a high connection rate
and will leave a boatload of sockets in SYN_SENT. If you use an
application layer gateway and then allow ICMP for unreachables, you'll be
ahead of the crowd and not have excessive risk. The lower PMTU will, of
course have an effect on how well traffic flows, and you'll want to watch
those devices for packet buffering and reassembly power.
"Necessary services" and "normal network functionality" are both network,
user and topology dependent. My ideas of them probably differ
significantly from yours.
When you're blocking ICMP, make sure you don't break path MTU discovery,
that's a killer. Everything else depends on topology. In my standard
designs, dual-screened proxy servers are a forced egress point, so PMTU
to/from them is my biggest worry. Unreachables depend on host IP table
saturation, timeouts, etc. Everything else is negotiable.
Block everything, and set up logging on your blocked ICMP packets, after
a while it should become pretty obvious what's getting blocked, then you
have to balance the risk of allowing it with the utility of unblocking
it. Host/Net unreachables can come from any routing device in the path,
port unreachables can only come from the device. Expect some load
balancing and multi-homed devices to act poorly, since they're the most
likely to hose up.
If you're blocking the RFC1918 reserved addresses at the border you'll
miss the occasional host or net unreachable anyway because someone's put
a router addressed with those on a link in the network path (I'm as
guilty as anyone for doing that.)
Happy New Year! (Hope you don't have to trapse in to work like I'm about
to.)
HTH,
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
