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