On Tue, 22 May 2001, Jason Lewis wrote:
> No one has asked what platform you are running FW-1 on. NT or Solaris. PIX
> is not layered on top of another OS.
(A) or BSD or Linux...
(B) IOS layered on top of a proprietary system probably isn't much of a
win from layering firewall stuff in between the OS and its drivers,
certainly turning a NAT device into a firewall has to have had its
challenges- since you're comparing two predominately packet filtering
products the challenges are about the same.
I think Checkpoint has only rarely had problems with OS level issues, and
that's been when they've taken the easy path of not touching the OS code
for things like remote management and VPNs.
The major problem I see with "appliance" type firewalls is that people
seem to not want to upgrade them at all. Just this week I saw another
SMTP problem report on a mailing list that was attributed to a bug in PIX
that's been fixed for a while.
The major advantage of "appliances" is that a moron at the keyboard can't
fire up a game on them, or run something else completely inane.
It'd be interesting to see bugs/LOC stats for shimming in over the drivers
versus writing your own OS-alike routines though. My guess is that by
this time both products have enough code in the critical path to be
equally scary (Especially given the remote access/remote management
creature feep.)
To be fair, I'm not a big fan of packet filtering based firewalls as
general purpose firewalls anyway (I don't mind them on the edges of
firewall systems, but I like real proxies in the middle), so salt to
taste. Both vendors seem to have historically had issues dealing with
application layer checking as a result of being a packet engine based
technology. Since nobody seems to care about application layer protection
anymore, that's probably moot too though.
It'd be really interesting to know what the crossover is between IOS FFS
and PIX- as in if Cisco is really developing both independantly or if IOS
is creeping into PIX from the top down...
I've always been wary of the "We didn't use a general purpose {stack, OS}"
argument since eventually you have to add remote access/management, memory
management, multi-tasking, fragment handling, state tables, etc. Clean
implementations are rare, and not recreating the same old bugs rarer
still.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
