You've asked a lot of questions here. I don't have a lot of time to go into
detail, so I'll try to summarize...
FireWall-1 Inspect code has access to the entire IP portion of the packet.
Depending on how complex you want to get with the code, in theory you can
write Inspect code to filter any protocol that is not encrypted. With
protocols that undergo a number of state changes from packet to packet and
can't be qualified in the first packet, FireWall-1 supports add-ons in the
form of the OPSEC interface. Through this interface, you can route your
protocol to custom code, that then performs additional filtering.
As far as established TCP connections are concerned, some is handled at the
kernel level, or a protocol can be configured to pass through a limited
portion of the Inspect engine.
Inspect is a mathematically based programming language. You edit it as you
would any text file. The rulebase portion of the code is generated based on
rules set up on the GUI. It is then compiled into a proprietary instruction
format and executed.
I'm not certain I've answered your questions. With FireWall-1, there are
often a number of ways to solve a problem. What's implemented is often
determined by cost and needed coverage.
Jack Dingler
"Bayard G. Bell" wrote:
> 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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
