At 03:05 PM 4/6/98 -0400, Stout, William wrote:
I'll be exceedingly kind and say that the Checkpoint Firewall-1 firewall
does not meet my level of expectations and I do not deem it worthy enough
to recommend to any of *my* valued customers.
I agree with the NSA's report on the stateful inspection. The NSA does
good work. (I also like their style of report-writing, but that's beside
the point). 8^)
I think that many people are overlooking some important criteria when
evaluating firewalls. The Stateful Inspection is just the tip of the
iceberg. A few criteria are listed below, others are available in the
*free* Firewall Evaluation Checklist which can be downloaded from my
company's web site.
Here are a few of my *many* crows to pick with the Firewall-1.
o You have to put a deny all at the last of the rules to make up for
its default stance of being wide open
o It encourages people to do stupid (from a security point-of-view)
things like permit dangerous (unproxied) services through the
firewall - a la' if they support it, it must be OK).
o I don't like the security architecture of the firewall
o Checkpoint came out and stated that proxies were bad and that SMLI
(pronounced "smelly" - IMHO, appropriate somehow) 8^)
is much better than proxies. I find it interesting that Checkpoint
uses "security servers" (which the rest of us mere mortals call proxies)
as this is an apparent reversal of their previous position. If proxies
were not secure as Checkpoint previously indicated, then why do they are
they on the firewall now?
o The only common encryption algorithm used in User->Firewall & Firewall->
Firewall encryption is their own (PROPRIETARY) FWZ1 encryption algorithm.
To my knowledge, the source code to FWZ1 has *not* been published, nor has
it been subjected to a peer review of expert cryptographers. And this from
a company which is supposed to provide security? Bah Humbug. Any
InfoSec Analyst knows that proprietary encryption algorithms should be
like the plague. Only encryption algorithms which have been published and
reviewed by expert cryptographers should be used. If the algorithm hasn't
been published and reviewed by expert cryptographers, then how do we know
it is strong enough & that there are no backdoors into it??? In the
several companies would claim to have a secure (homegrown) encryption
algorithm and would post a challenge to the cypherpunks mailing list for
someone to crack it. If they were to do so, they would sell their company
for $1.00. 2-3 days later, someone would crack the supposedly unbreakable
algorithm and state that the company can keep their dollar.
o With proxies & logging enabled, it is *slower* than proxy firewalls.
o The NSA (who is no slouch in getting crypto to work) couldn't get
VPN crypto to work.
o Checkpoint's lack of support in notifying their customers about the
that Secure Networks posted.
o Checkpoint's denial that the problem even exists (as visible in their
the Computer Security Institute's Alert newsletter).
The above are a few, but how many security problems does a firewall have to
before it is ultimately rejected. You have to remember, we are talking
security product, not what type of car to buy. It should be evaluated
from a security point-of-view (it is, after all, a security product). It
rate a high rating in my book or that of other Information Security Officers I
have talked to. But hey, what do we know? We're only Information Security
Officers - not Checkpoint marketing dweebs.
I would recommend that the audience at large do their *own* research and come
to their own conclusions. 'Nuff said.
>State vs. proxy is a religious issue for some, but then again, some
>swear by MS-Proxy as a firewall.
>I've seen the problem first hand, and the Checkpoint-1 report from the
>NSA points this out also.
>The NSA pointed out state-based specific vulnerabilities (which their
>report admits they did not fully test):
> Exploitation of an allowed service
> Insider threat - opening up ports to the outside
> Exploitation of ports opened by a legitimate user
> Subversion of the stateful packet filtering mechanism
>The test "Test 6: Overflow of internal tables" describes the overflow,
>results, and DOS attack. The problem should be fixed by now. Staunch
>defenders of the packet filter faith deny it ever happened. See
The opinions of the author of this mail may not necessarily be
representative of the opinions of Fortifed Networks, Inc.
Fortified Networks, Inc. - http://www.fortified.com/
Home of the Free Internet Firewall Evaluation Checklist
Expert (vendor-neutral) Computer and Network Security Solutions
Phone: (317) 573-0800 Fax: (317) 573-0817