I've been having a look at Checkpoint's INSPECT engine and the claims
around it and have a few technical questions that I was hoping this list
might help me answer or at least think about with greater coherence.
My first set of questions: to what extent is the INSPECT engine a
application-level gateway put in series after the dynamic packet
filtering part of Firewall-1's stateful inspection? (To judge from the
INSPECT fix Checkpoint provided for the non-SYN packet-initiated state
table entries, INSPECT can cause state table entries to be dropped,
although this does negate Firewall-1's ability to regain state after the
firewall is bounced.) I'm still confused by the comment in the BUGTRAQ
database that:
"Check Point has developed INSPECT code changes that provides a
solution for this type of attack. This code change enables Check Point
gateways to drop non-first TCP packets instead of matching the rule
base." (see
http://www.securityfocus.com/vdb/bottom.html?section=solution&vid=549
for details)
"Instead of matching the rule base"? Where does this happen in or
outside of the rule base? After? Before? In the beginning or end?
I've seen some comments by Frederick Avolio about serial firewall
technologies in a single box, and I'm wondering if Firewall-1's behavior
matches this description or not. I've also read the Avolio paper that
argues that Checkpoint is a dynamic packet filter and not an
application-level gateway, but I was wondering what attempts had been
made at empirical validation. (I understand Avolio's argument that
content inspection clearly cannot be performed on services that are
added simply by opening a port or otherwise defining a packet-filtering
rule for them, but to be fair to Checkpoint, they do have a list of
services that INSPECT can examine. Clearly content inspection doesn't
happen by virtue of adding what is very clearly a packet filtering rule;
the question is how distinct this is from the packet filtering
capabilities of Firewall-1.)
Second: is anyone aware of any white papers on Firewall-1's content
inspection features other than dynamic packet filtering? I've taken a
look on the web but haven't found a great deal of information on this.
I've read Lance Spitzner's excellent paper on the state table for
Firewall-1, and what this tells me is that Firewall-1 is not the most
thorough implementation of dynamic packet filtering that one could
imagine (e.g. it ignores TCP header information such as sequence numbers
-- this may seem trivial, but one never knows how a bad IP stack will
handle this kind of unexpected protocol nonconformity, and that's why
you at least expect your firewall to be thorough about network layer
controls) but not much of anything about the content inspection features
that Checkpoint puts front and center in their marketing materials as
the thing that makes Checkpoint so fabulous and unique. How extensive
are Checkpoint's abilities to control applications that listed for
INSPECT coverage?
Third: how well does the Checkpoint GUI manage INSPECT code? I
understand that the GUI is very effective in controlling standard
INSPECT rules, but what happens when you decided you need to modify your
INSPECT rules to handle new protocols or extend controls over a given
application? Are you "stuck" working with text files (fearless perl
programmers may charge on ahead) when adding or modifying capabilities?
Just how flexible are the INSPECT rules? Has anyone worked directly
with the rules as text files? What have your findings been?
These are the questions on the top of my mind as my organization takes a
serious look at buying Firewall-1. Behind all this (somewhere around my
visual cortex, I suppose), I'm recalling a comment by Marcus Ranum a
while back about vendor's putting out protocols that are [at least from
a security perspective and too often more generally] brain-damaged and
noting a growing trend to tunnel these protocols and other liabilities
through HTTP (as if ActiveX weren't bad enough), an insistence on
mediocrity that demands more protection than your average packet filter
can provide. Any information you might have on Firewall-1's capability
to deal with the latest in bad product design and quality control is
deeply appreciated. I don't mean to offend anyone's religious
convictions in asking these questions...
-Bayard Bell
Emory University
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
