> Part IIb / II
>This is message IIb. Hopefully, this one will get through. In any event,
>it seems that to me, this is a classic case of "IIb or NOT IIb - that is
>the question". 8^) 8^) 8^)
Boo! Received at 4:36 a.m. 4/11/98, Pacific time.
>>>o With proxies & logging enabled, it is *slower* than proxy
>>Hasn't been my experience.
>How do you know?
Ran a socks proxy for a long time. Heck, FW1 even kicks butt
compared to the Cisco access-lists I had in place at one point,
on a 7010 with RP/SSP cards. It wasn't any kind of controlled
experiment, so the results don't neccessarily match what everyone
else will get.
>>Strange, the report I've seen (mentioned in the
>>URL above) states that they were able to validate it.
>>The only part that wasn't validated was IPSec, which
>>FW1 doesn't do (or claim to.)
>According to pages 8, 11, and 45 of the NSA's report
>(as follows), your statement above is incorrect.
> "The vendor claims described below were selected from
> the product documentation, sales literature and the
> Check Point web site."
> "Manual IPSEC: Not Validated.
> IPSec with the AH header did not work."
My statement above is incorrect. I checked the docs, and
they do claim to support IPSec.
> "Exchanging the keys between firewalls was not
> straightforward. Numerous errors were encountered
> with no corresponding troubleshooting procedures.
> Rebooting and reinstallation of either firewall
> had no affect. Upon the advice of the Check Point
> representative, the workaround to problems with
> key exchanges was to delete both firewall objects
> from the network objects list and to recreate them.
> This seemed to "sync" up the firewalls and the key
> exchanges were then successful. While this method
> worked, it was not optimal. For example if numerous
> keys had already been generated, this could be a
> lengthy and troublesome rebuild."
>What about customers who have several hundred *thousands*
>of remote clients. Can you see them regenerating all of
>the keys? Perhaps even manually? Not likely. The first
>time it happened, a CIO/CTO would probably replace the
>firewall & use the old one as a boat anchor.
This is a fair critcism. That procedure could be much easier.
I think you're extending the difficulties of exchanging keys
between gateways to exchanging keys to VPN users,
though. I had no difficulty getting keys to VPN users,
and I don't think that's what the report is referring to.
>NSA's document further indicates:
> "The FWZ scheme encrypts all the data between
> the firewalls, but does not hide which services
> are being used. This simply means that the FWZ
> scheme does not support a "tunneling" mode in
> which the services are encapsulated within an
> encrypted IP packet. Knowing which services are
> being used between firewalls enables an attacker
> to perform traffic analysis and gives a starting
> point for choosing a particular service to attack."
Tunnelling wasn't supported in the version they tested,
it is now. You can do it either way.
>I do. Without exception, *none* of the companies I talked
>to (who had the Firewall-1), were aware of the SNMP problem
>until I told them.
>Out of curiosity, how did you find out about the SNMP
>problem? Through a friendly call or e-mail from
>Checkpoint, their hidden VAR/Reseller pages, or Bugtraq?
Bugtraq and the FW1 mailing list that Checkpoint hosts. They
posted a mail about how to work around it, but I'm not aware
of any kind of notification from them.
>>>The above are a few, but how many security problems
>>>does a firewall have to have before it is ultimately
>>>rejected. You have to remember, we are talking about
>>>a security product, not what type of car to buy. It
>>>should be evaluated primarily from a security point-
>>>of-view (it is, after all, a security product). It
>>>doesn't 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 dunno, how many basic facts does a security consultant
>>have to be wrong about before he's ultimately rejected?
>I don't know, but you're not doing very well so far.
>It appears that your last sentence above was supposed to be a
>personal affront to me. I wasn't planning on getting into this,
>but I have no problems defending myself. I thought you knew my
>background, but I'll refresh your memory just in case.
>In my case, I'm an Information Security Officer (ISO) with over
>8 years experience as a corporate ISO and @ 15-20 years additional
>security experience (nukes, intelligence, DoD contracting, Advanced
>Research Projects, etc.).
>My first job in as a full-time ISO was working for Digital Equipment
>GmbH (DEC's German subsidiary) where I managed the InfoSec Operations
>for the entire country. While there, we achieved the highest level
>of security of any country in the world (in a global network of
>120,000 employees, 100K systems) month-after-month for a couple of
>years - that continued even after I left. I don't know why, but I
>seem to have a (verifiable) knack of making security work well with
>business & turning security into a competitive advantage. BTW, all
>of the above is verifiable.
>I am NOT a "security consultant" who lacks "real-world" experience.
>If you want one, the phone book is full of them. Just hand us the
>And your "real-world" experience in securing corporations as an ISO
Didn't claim to have any. Your qualifications are impressive, but that
isn't a safeguard against being wrong occasionally. I assume that your
information regarding FW1 is from the evaluation under discussion,
and a review of some sort that you've done? That won't neccessaily
give you better infomation than someone who uses it daily over
a few years. It won't keep you informed about what improvements
have been made in later releases.
>>Always a good idea. I try to help by keeping people
>>from staying things that just aren't true for the products
>>that I'm familiar with.
>Truth is relative. I prefer the facts. I'll draw my own
>conclusions, thank you.
If you see a distinction between "truth" and "fact"
in this context, fine. I believe I've presented some
facts that contradict some of your statements. And for
someone who is interested in facts, you seem to
put forth a lot of opinion. For example, what does
Checkpoint's marketing have to do with how
secure the product is? Do you want the facts about
the product, or do you want to discuss whether their
marketing department is telling the truth?
>FWIW, I think Checkpoint's attempts to market stateful inspection
>as the firewall cure-all are doomed to failure. People are smarter
>now and they resent being led down the garden path. They're no
>longer buying into every bit of marketing hype that comes along.
>The stakes are too high. They can't afford to make a less-than-secure
>choice. They are *literally* betting their company on their choice of
>a firewall. They are (finally) taking the time to do the research
>themselves and to make intelligent, informed choices. It's a good
>start. I hope the trend continues.
Checkpoint & FW1 aside, I don't see that happening, unfortunatly.
>I admire your loyalty to Checkpoint. Personally, I think it's
>misplaced. Checkpoint may be good for protecting internal business-
>critical systems on an internal LAN from disgruntled employees.
>(IOW, it's OK for a relatively low-risk environment), but I
>wouldn't touch it to protect an organization from the serious
>threats from the Internet or other high-risk network.
I don't know if I'd call it loyalty, exactly. As I said before, I'm
with the product, and am willing to take the time to correct misstatements
made about it.
>My loyalties are to my customers. As you have probably gathered
>by now, there are very few firewalls that I deem "worthy enough"
>for my customers. Of the @ 70 firewalls on the market, there
>are about 5 that I feel are secure enough to stop a determined
>I take security products apart before I recommend anything
>(and have been doing so for years). Most recently, I tested
>an Operating System Security product. It failed. The main
>problem was the product failed on implementation issues. Of
>particular note, it is not an enterprise-wide solution.
I have no problem with being particular about which products one
uses or recommends. I do have a problem with broad, sweeping
generalizations and incorrect statements.
>May the (right) firewall be with you. 8^)
Received: from tunnel.sybase.com ([220.127.116.11]) by ibwest.sybase.com
(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 882565E3.0048CD6C;
Sat, 11 Apr 1998 06:15:11 -0700
Received: from smtp1.sybase.com (smtp1 [18.104.22.168])
by tunnel.sybase.com (8.8.4/8.8.4) with SMTP
id GAA24751 for <Ryan_Russell @
tunnel-w>; Sat, 11 Apr 1998 06:14:08
Received: from halon.sybase.com by smtp1.sybase.com
id AA25518; Sat, 11 Apr 98 06:14:08 PDT
Received: from relay5.UU.NET (relay5.UU.NET [22.214.171.124])
by halon.sybase.com (8.8.4/8.8.4) with ESMTP
id GAA24716 for <Ryan .
com>; Sat, 11 Apr 1998 06:14:25
Received: from honor.greatcircle.com by relay5.UU.NET with ESMTP
(peer crosschecked as: honor.greatcircle.com [126.96.36.199])
id QQekqm08136; Sat, 11 Apr 1998 09:07:05 -0400 (EDT)
Received: (majordom @
localhost) by honor.greatcircle.com
(8.8.5/Honor-Lists-970926-1) id EAA13535; Sat, 11 Apr 1998 04:31:54 -0700
Received: from su1.in.net (su1.in.net [188.8.131.52]) by
honor.greatcircle.com (8.8.5/Honor-980202-1) with ESMTP id EAA13517 for
com>; Sat, 11 Apr 1998 04:31:41 -0700 (PDT)
Received: from frankw.in.net (pm5-25.in.net [184.108.40.206]) by
su1.in.net (8.8.8/8.6.9) with SMTP id LAA08304 for
com>; Sat, 11 Apr 1998 11:35:01 GMT
Message-Id: <3 .
X-Sender: frankw @
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 11 Apr 1998 06:36:12 -0500
To: firewalls @
From: Frank Willoughby <frankw @
Subject: RE: socks versus fw-1 [Part IIb/II]
Content-Type: text/plain; charset="us-ascii"
Sender: firewalls-owner @