"I wouldn't quite go as far to say that it is a "boot loader". It does
load Windows NT & then disables services and features which are not
firewall related or have been deemed to be insecure."
If it did that, and, integrated with the NT Security subsystems, I might
not agree with Chris. However, what I have seen are systems that implement
their own drivers and then link to them once NT has completed loading,
effectively by-passing much of NT's own code to get to the packets early
enough to work the Firewall's magic.
For the vendor, this has the advantage of making them less dependent on
code changes by Microsoft, but has the side-effect of making it more
difficult to integrate into an existing NT environment. If its not
integrating to the NT environment, then why would I be thinking of NT. The
only reason left, IMO, is that I want the familiarity of the NT environment
when it comes to administration of the Firewall. Once again, however, I
haven't seen one yet that truly looks like NT or provides me any real
leverage of my existing NT Administration skills.
Until both of these things are done well, then NT is just a boot loader.
"Personally, I see this as an advantage rather than a disadvantage. I
wouldn't want to use any NT features which may be critical to the use of
the firewall for two main reasons:"
Its an NT-based Firewall!!! Using this logic, I'm far better off with one
of their UNIX implementations. I'm paying an extra $600 bucks for an NT
Server license, why shouldn't I expect them to make some use of it? If it
doesn't make use of NT for its critical features, then its not an NT
Firewall, plain and simple. Hey, I like the guys at Raptor as much as the
next guy, but I've told them, and I'm telling you, its not NT until it uses
NT. If its not NT, then get their UNIX version.
1) You can't be sure that the software will be stable.
Micro$oft could accidently let a bug creep into their software
which could render the firewall insecure or inoperable - requiring
that the vendor "freeze" their version of Windows NT ("We will only
support NT version X.Y.") - leaving them in a strategically vulnerable
position.
True, and this is why its important to have a strong relationship with
Microsoft for these products. Microsoft does not go blindly off changing
code to suit their needs, despite what anyone thinks. There are quite a
number of vendors who reject changes as a result of the impact they will
have on their code. As we all know, there are many ways to skin a cat. That
said, Microsoft is also not going to prevent a code change just because a
vendor has too few programmers put into their NT efforts.
Many small vendors, Executive Software (Diskkeeper) for example, replace
the NT HAL with their own code, no small task. Yet these guys are able to
release NT service packs about 60 days behind Microsoft, consistently. This
is pretty good testimony to how bound and tied vendors really are to
Microsoft's changes.
Also, if the software is written internally, then you have full
control of the s/w development, you can provide better support,
and you can provide a quicker response to problems/bugs.
2) Security
Pretty much the same rasons as in #1. Further, it is never a
good idea to outsource Information Security. Relying on Micro$oft's
security mechanisms would place the vendor's product & reputation
at the mercy of Micro$oft's ability to write tight secure code.
I agree here, but you always have the ability to go the driver route should
your "real" implementation be found susceptible to a bug. Many people have
written work-arounds to accommodate problems that Microsoft either deny, or
have problems dealing with. Bob Denny wrote defensive code into Website for
3 service pack releases of NT, finally getting the problems resolved in NT
3.51 service pack 4. This is not good testimony to Microsoft's
responsiveness to problems, but it may also have been a matter of a
transient problem that was difficult to isolate. It caused server crashes,
so it was important, but it only affected a small number of machines, so
its importance was diminished. Bob found it made more sense to code around
the problem, and accept a performance hit in the process, than to wait for
MS to fix it. It was detrimental to his product, but he was the only one
that bothered to implement a patch, shows you where the market is. Website
was able to be more reliable than anybody else, with a cost of slower
performance.
This kind of problem is not a small one, and it has to be addressed
properly by Microsoft. I'm not privy to what was said between the two
parties in the above example, so who knows why it wasn't fixed sooner.
Would a stronger relationship between the two have been better? I doubt it.
Has Microsoft realized that these types of problems need to be fixed
faster, I think so. If the issue was one of security, would Microsoft deal
with it differently, the unqualified answer I have received is yes, and
believe me, I've been very vocal with them about this possibility.
Raptor have, in my opinion, taken an aggressive stance with respect to
Windows NT. The first NT implementation of their Firewall has its
limitations, and is more designed to keep customers demanding an NT
solution from buying into some other vendor's futures. Global Internet's
Centri has its own legs because of its TIS background, but the fact that
they are selling evaluation copies, rather than giving them away, will make
their story something less heard.
It will be very interesting to see where PPTP takes either of these
products in the future. Do you buy into VPN, or do you use PPP encryption?
VPN offers the flexibility of being accessible by most clients, whereas
PPTP is limited, for now, to a select few clients. As the deployment of
FEPs ramp up in Telco's, I suspect that PPTP is going to have greater
widespread use than VPN. Because of the way its implemented on NT, it
offers a pretty good security story, but that's for NDA and not for
here...Sorry Bill...;-]
Cheers,
Russ
Follow-Ups:
|
|
