Great Circle Associates Firewalls
(April 1998)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: RE: socks versus fw-1 [Part II/II]
From: Frank Willoughby <frankw @ in . net>
Date: Fri, 10 Apr 1998 08:19:45 -0500
To: firewalls @ GreatCircle . com

				Part II/II

Continuing from Part I/II:

>>fw
>Ryan
fw


>>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?
>
>I haven't done the necessary research to determine whether 
>the security servers are more like proxies or more like SPFs, 
>so I can't really comment.

I'm sorry.  I was out of line on the "smelly" part.  (The 
combination of the pronunciation of SMLI & my displeasure 
with Checkpoint's application of it were too much to resist).  
At least they realized the wisdom of the pronunciation of 
their SMLI acronym and now refer to it as SPF (Stateful 
>> Packet Filter <<) which I think is more descriptive of 
what it *really* is.


Anyway, I *did* do the research.  One reference about security 
servers being proxies is contained in the NSA's report on page 56/98:

  "The Checkpoint Firewall-1 firewall is equipped 
  to perform rule base filtering based on the protocol 
  itself with the Stateful Packet Inspection / Filtering 
  or with a proxy which Checkpoint calls a Security Server."


>>o The only common encryption algorithm used in 
>>   User->Firewall & Firewall-> Firewall encryption is 
>>   their own (PROPRIETARY) FWZ1 encryption algorithm.
>
>Uh, wrong.  They support DES and whichever SKIP protocols 
>you like.  US only, of course.

I think you misunderstood me.  The operative word in my sentence 
above is "common".  I meant common to *both* User->Firewall *and* 
Firewall->Firewall VPN connections.



>>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 beginning InfoSec Analyst knows 
>>that proprietary encryption algorithms should be 
>>avoided 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 past, 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.
>
>All true.  That's why I have the DES version.

Bingo.  If you're aware of this fundamental principle of good 
crypto, don't you think that Checkpoint is aware of this also?  
- Particularly since they designed a couple of VPN solutions
into it?  I'll give them the benefit of a doubt and assume 
this was an oversight and not deliberately designed into the 
product.  Assuming they're smart and have no ulterior motives,
they'll probably drop FWZ1.  They don't need it and it 
destroy(s/ed) their credibility in the security arena.

Out of curiosity, why is Checkpoint being evaluated by the NSA?
One requirement for entrance into the MISSI club is that the
product must be integrated with FORTEZZA.  FORTEZZA is a 
PCMCIA card with extensive authentication/encryption/signature
capabilities.  FWIW, I think FORTEZZA is a little ahead of 
its time.  At some point in the next couple of years, a 
FORTEZZA-like product will be a standard & will probably
be very widely used.  Right now, it's a little expensive,
and I don't think that society is willing to absorb this
cost, but in large quantities, the price could come down
and it would be a VERY attractive option.  But I digress...

Perhaps I'm missing something, but I didn't know that 
Checkpoint had their own FORTEZZA solution.  If this is 
the case, then either the NSA has dropped this requirement 
(hopefully not), or Checkpoint is using someone else's VPN 
solution.  I don't know, but the secure VPN solution from 
V-ONE (their SmartGate VPN Server integrates on a number 
of vendor's firewalls) is a likely bet.  

If the long chain of IFs above is accurate, I find it pretty 
ironic that Checkpoint has to use someone else's VPN solution 
to get looked at by the NSA.  Speaks volumes, doesn't it?



>>o With proxies & logging enabled, it is *slower* than proxy 
>>firewalls.
>Hasn't been my experience.

How do you know?  



>>o The NSA (who is no slouch in getting crypto to work) 
>>couldn't get Checkpoint's VPN crypto to work.
>
>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."

Further:

  "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.


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."


>>o Checkpoint's lack of support in notifying their 
>>   customers about the vulnerability that Secure 
>>   Networks posted.
>>o Checkpoint's denial that the problem even exists 
     (as visible in their note in the Computer Security 
     Institute's Alert newsletter).
>
>I don't know the story here, so I can't comment.

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?  


>>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.  


I wasn't planning on getting into this, but your statement 
above forces my hand.  In my case, I'm an Information Security 
Officer (ISO) with over 8 years experience as a corporate ISO. 
While I was there, we achieved the highest level of security of 
any country in the world (120,000 employees, 100K systems) 
month-after-month for a couple of years - that continued after
I left.  I seem to have a (verifiable) knack of making security 
work well with business & turning security into a competitive 
advantage.  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 clean-up work.

If you need eye surgery, would you rather go to one who has 
successfully performed eye surgery hundreds of times - or a 
pre-med student who has taken a couple of courses and read 
a few books on the subject?  The choice is yours.

And your "real-world" experience is ...?



>>I would recommend that the audience at large do their 
>>*own* research and come to their own conclusions.  
>>'Nuff said.
>
>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.  

Look, no firewall is perfect.  I'll always find at *least* 
a handful of benign security problems with any vendor's 
application-gateway type of firewall and many more (mostly
very serious ones) with a packet filter type of firewall - 
no matter how well they are configured.  Some problems are 
security vulnerabilities and some are engineering design flaws.

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.

May the (right) firewall be with you.  8^)

Best Regards,


Frank
The opinions of the author of this mail may not necessarily be 
representative of the opinions of Fortifed Networks, Inc.

(c) 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


Indexed By Date Previous: Unsubscribing
From: rdew @ el . nec . com (Bob De Witt)
Next: RE: fw-1 stateful inspection vulnerabilities
From: Gordon LaSane <glasane @ gdsconnect . com>
Indexed By Thread Previous: Unsubscribing
From: rdew @ el . nec . com (Bob De Witt)
Next: Re: WatchGuard Security System
From: Brian Macke <macke @ telegroup . com>

Google
 
Search Internet Search www.greatcircle.com