ICMP problems with Firewall-1 (long)

["Ryan Russell" <ryanr () sybase com>]

I want to highlight some of the issues that have been brought up in the
past regarding ICMP and Firewall-1 from Checkpoint.

Recently, I got a call from a technician working for an ISP.  He informed
me that one of my sites was acting as a smurf relay, and was causing
one of his clients a great deal of trouble.  I looked through the
logs of the Firewall-1 machine that was protecting that site, and
was quickly able to verify his claims.  Since the attacks were still
going on at the time, I went to the properties screen, and checked
off "allow ICMP" and installed my rulebase.  A little overkill,
but effective for the moment.

After sending a note to my internal support personnel letting them
know ping wouldn't work for a while, I went about investigating what
would be the best mechanism to restore functionality for my
users, but prevent my site from being a smurf relay.  After some
further checking, I also decided that I didn't want the Internet to
be able to ping any of my inside hosts, which I hadn't realized could
happen.

I should point out here, that some of this can be attributed to
misconfiguration on my part, and I can't say I haven't been warned.
I had been warned quite well by Bill Burns, but it didn't sink in.
I'm writing this note in the hopes that, for other FW1 admins, it
will sink in.

Let me give a little background about this network.  It consists of
a few ranges of class C's that had been given to them by the ISP. In
the past they didn't use NAT on their FW1, and so all the machines in
the class C's would keep their real IP addresses when they hit the
net.  So, there were routes to all of these class C's that pointed
at the FW1 machine.  Later, I upgraded the version of FW1, and
configured the inside machines to use NAT.  I couldn't remove the
routes yet for other reasons I won't go into.  So, I had NAT on, but
the routes were such that it looked a lot like a non-NAT config.

When you install FW1, you have two choices for making ICMP work
without writing your own Inspect code (more on that later.)
The first is to leave the "Accept ICMP" property check on.  The second
is to check that off, and put in a rule that allows ping requests
out, and ping replies, unreachable, and TTL exceeded in.  In
retrospect, the latter is the much better choice.  In practice,
probably too many people do what I did, and left "Accept ICMP"
on, without fully investigating the implications.

Another default helped to make my site a smurf relay, and that was
the Broadcast: Allowed default.  This is defined on a per-network
object basis.  At the time, I was thinking in terms of inside
hosts broadcasting.. and couldn't think of any problems that would make
me want to have it off.  Bad attitute when it comes to security
applications, and I should know better.  When this is combined
with the fact that any ICMP is let through, anyone on the Internet
could send packets to x.x.x.0 or x.x.x.255, and bang, perfect
smurf relay.

So, what happens if you don't bother unchecking "Accept ICMP?"  This is
where I could have used a little more black-and-white statement before.
Bill Burns gave me all the information I needed to figure this out myself
in the past, but I wasn't paying enough attention.  I suspect he was
trying to not be super critical of Checkpoint.  I'll spell it out.

If you don't uncheck that box, you will likely be usable as a smurf
relay, will likely have inside machines vulnerable to the ping-of-death
(unless you follow the recommendations here:
http://www.checkpoint.com/products/firewall-1/descriptions/pingattack.html
,)
people will be able to ping map your inside nets, they'll be able to
send ICMP host unreachable messages, possibly ICMP redirects to send
traffic
to places you really wouldn't want it to go, ICMP source quenches to slow
you down, and probably a lot of other things I can't think of off the top
of my head.  It's really a bad idea.

If you use NAT, it may or may not help you.  If the attacker has a way
to get the packets to your firewall, it will let them through.  It
won't NAT them.  It doesn't really matter if your rules don't let
the outside in, and you use 10.x.x.x .  If you have the "Accept ICMP"
checked on, and the packets can get to your firewall, it will let
them right through.  The only exception is if you have the setting
for "Accept ICMP" set to before last or last, and specifically deny
ICMP in the rulebase.  As near as I can tell, you have to put ICMP
in explicitly... "ANY" won't catch it in this circumstance.

So, what's the fix?  Well, if you listen to Checkpoint, it's to implement
the second option above.  The problem is, as Bill pointed out in the past,
is that, currently, FW1 doesn't handle ICMP statefully.  So, if as
I've outlined above, you're only allowing in a small set of ICMP
types, I can send those inside your network all day long.  You don't
have to have asked me for an ICMP reply for me to send it in.  I can
send you ICMP host unreachables or TTL expireds and make a general
problem of myself.

So, is this an actual security problem?  I don't know.  I don't
know of any exploits from these.  However, hopefully I've demonstrated
that just because the problem isn't apparant now, it won't be painfully
obvious later.

So, what can you do?  Go here:

http://people.netscape.com/shadow/work/inspect/fw1_icmp.html

You'll find Bill's stateful ICMP code.  Not only will it do intelligent
things, like: only allow ICMP replys in if you've requested an ICMP
echo, but MS tracert will now work.

I consider this code mandatory.  If there are any issues with the code,
more people installing it will bring those out.  Hopefully, when
the code is shown to be stable, Checkpoint will roll it into the
release version.  Bill has given them permission to do so.  Everyone
should request that Checkpoint do so.  I can't think of any reason that
they wouldn't want to give us all a higher level of security when
Bill has done the work for them.

I'd like to thank Bill Burns for doing the research on this issue, and
going as far as developing a fix.  I claim no credit for finding
the problem or the fix, I'm just trying to help educate other
FW1 admins so that they can benefit from my mistake.

                                Ryan