crow!rik @
uunet .
uu .
net wrote:
>
> The CheckPoint solution is in the same class as ANS Interlock--but provides
> more control for the product's owner. It is also in the same price
> range. ANS, a few booths over, claim to have a software only product under
> development (their RS/6000-based system goes for $18k to $25 A YEAR, depending
> on configuration).
It appears that Checkpoint's goal was to provide the transparency of a
screening router, but at the cost of not performing user authentication.
This would be a fundamental difference from most application gateway class
approaches (like the InterLock.) Its a user friendly vs. security tradeoff
that will be attractive to some portion of the Internet population but not
others. Not authenticating the user has ramifications through out a firewall,
for instance loss of user accountability in the logs. Also comparing pricing
models is difficult since our offering includes hardware, software and
7x24 support, not to mention a stratum 1 NTP and optional NNTP feed.
I don't know what Rik had in mind when he says "more control", but from my
*admittedly limited* understanding of the Checkpoint product it seems to have
LESS control and flexibility. The InterLock offers per-user controls,
control over how users are authenticated in each direction (SecurId, Pinpad,
Passwd...), when encryption will (optionally) be used and many other
combinations of granular security policies criteria.
Did anyone else notice that the Checkpoint marketing literature mentioned
support for passing a number of the dangerous protocols (eg. NFS, RPC). Has
anyone heard their position on forwarding these protocols?
As for their discussed GUI, its alittle disturbing that they provide a
*potentially* large X client which could open up vulnerabilities at a very
dangerous time (during security policy definition). IMHO, it is important to
have some type of user friendly interface for novice network and security
administrators to define and manipulate rules (access controls) for many
customers. This interface should also allow for the verification of the
effect of the rule changes prior to putting them into effect on the firewall.
This can be accomplished without graphical widgetry which has the benefit of
being able to run in non X environments.
As most people know, after fighting the internal battles of what security
policy should be enforced, its frequently very tough to communicate and then
verify that policy to a firewall. Due to this difficulty, administrator
configuration mistakes due occur on many filtering router firewalls (as seen
on this list) which can lead to breakins.
>
> Neosoft was demonstrating in the BSDI booth. Another kernel-based
I didn't get to see their product, but did get their nifty bumper sticker...
"I'd rather be NetSurfing" :-).
Paul
____________________________________________________________________________
Paul Sangster
Advanced Network & Services Software Engineer
1875 Campus Commons Dr. sangster @
reston .
ans .
net
Suite 220, Reston VA 22091 (703) 758-7706
____________________________________________________________________________
|
|
