On Fri, 5 Nov 1999, Nathan Long wrote:
> Disclaimer: while I do not work for Check Point, I have purposefully chosen
> to work only with Check Point firewalls. My following comments will reflect
> this educated bias.
Or perhaps "miseducated bias."
>
> >>packet filters are often very fast ( could even be just a router with
> firewall software ). For example a basic Cisco PIX.
> >>Stat.. like FW-1 offer more security, but are not as fast.
> >>Proxy, are slower then stat... but offers even more security.
> >>App... are the slowest, but most secure.
> Bunk, complete and total bunk. Well, that's a bit harsh. The first two
> lines are accurate but the last two lines are not.
Bullshit.
> Yes, proxies and application gateways are slower than stateful inspection.
> That having been said, they are not more secure than true stateful
> inspection. Lance Spitzner had written a great paper, detailing what
A proxy has a reference implementation of the actual client code
(hopefully written with security in mind.) It can make very complex
choices about application layer data that payload inspection can't
without re-creating the client's packet reassembly routines, stack
behaviour *and* application code. That makes a *lot* more code, and offers
an increase in bugs/line for the resultant code. Blocking active content
such as ActiveX is one example of a difficult to solve problem in
filtering and maintaing state that's fairly easy to solve in a proxy.
Let's look at the MSG_OOB bug for an example of a problem waiting for a
solution that Stateful anything doesn't fix.
Put 100 vulnerable clients on the inside of the firewall.
Make them connect via FTP or telnet to a server outside the firewall that's
been compromised. There is no pre-knowlege of the bug and the
application protocols allow the valid use of MSG_OOB.
Scenerio 1: Stateful inspection firewall.
Result 1: Firewall is alive. Clients are all dead.
Scenerio 2: Proxy firewall where the proxy's OS is vulnerable.
Result 2: Proxy is dead, clients are alive but unable to communicate
through the proxy.
Scenerio 3: Proxy firewall where the proxy's OS is not vulnerable.
Result 3: Proxy is alive. Clients are alive.
So, we have zero protection in the case of a packet filter and a "failed
safe" and "no failure, no exposure" result in the case of a proxy.
That's an _actual_ example of a scenerio where *all* stateful inspection
firewalls _failed_to_protect_their_clients_, and is why not everyone buys
into the idea that the protection model offered by stateful packet
filters is as good as that of a proxy without recreating the proxy's
behaviour completely, which negates the advantages stateful filters have.
> semi-intelligent Stateful Inspection really is and how it really works,
> (http://www.enteract.com/~lspitz/fwtable.html) so I won't belabor that here.
> (By the way, nobody makes truly intelligent Stateful Inspection)
I believe that paper was authored to show the differences between the
academic value of stateful inspection and the implementation of it in
Firewall-1. It's nowhere near a glowing review of FW-1's abilities at
the time, in fact it's value seems more in debunking FW-1.
> (Incidentally, check out all of Lance's white papers at
> http://www.enteract.com/~lspitz/pubs.html)
> IMNQSHO Check Point Firewall-1 (particularly now that they have developed
> the SVN architecture) is the most secure, most reliable, and definitively
> most enterprise scalable, not to mention manageable firewall on the market.
You probably thought that when they shipped the product configured so
that RIP would pass through by default too. You probably don't see the
discord in not maintaining state out-of-the-box for ICMP even though the
code is perfectly capable of doing so. You may not even worry that the
host IP stack was used for management and VPN access breaking the model
of not having to secure the stack that the product originally touted.
Firewall-1 does some things very well, and INSPECT makes it quite
flexible if you happen to have a staff of firewall-clueful programming
people who understand where the product's flaws are, but it's hardly the
"most secure" firewall on the market in terms of its initial configuraion and
its protection model.
*Every* commercial and non-commercial firewall product I've seen has had at
least some flaws in design, implementation and functionality. That's
*and*, not *or*, and all the rabid advocacy in the world won't change that.
Quite a lot of people who bought the "Stateful Inspection is everything"
model seemed to overlook the addition of "Security Servers" as an
admission that the product they chose *didn't* provide the level of
security its marketing department wanted everyone to believe when they
originally purchased it.
Reverse telnet over ICMP trojans worked at almost every FW-1 installation
I've seen. The product is capable of blocking such abuse, but isn't
inclined to do so by default.
There is no "most secure" firewall when it comes to firewalls that pass
traffic, only some with the ability to block more than others.
I've proposed a real-world scenerio where stateful inspection (FW-1,
PIX's filtering varient, etc.) provides less protection than an
application-layer gateway (proxy). Feel free to provide a counter-example
where the _security_ of a proxy is less than that of a stateful inspection
engine in regards to protecting the systems on the internal network from harm,
which is after all the job of a firewall.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
