> I guess no-one really wants to touch this subject. Is it perhaps
> because NT really is "very secure" and we can trust it to do security
> firewalling? grin;-)
In some firewall architectures, if reasonably implemented, the
operating system on which the firewall runs is irrelevant, from
a security perspective. Let me try and explain why I believe
this - and please bear with a kind of lengthy explanation because
it is subtle. I'll use product names as examples but this is
not a product plug nor am I saying any approach is better or
worse - just different.
Firewall software running on an O/S can exist at different levels
within the O/S. For example, a FWTK firewall exists purely above
and outside of the O/S. A Checkpoint firewall exists (except for
its user interface) between the packet input/output queueing code
and the routing layer in the kernel's IP stack. A Firewall/Plus
replaces the packet input/output queuing code and talks directly
to the network interface cards. Those are 3 totally different
approaches, and each approach, you'll notice, is "closer to the wire"
and takes increasingly less advantage of the O/S. Early versions
of Firewall/Plus ran on DOS and used to completely replace the
"kernel" while it was running.
In the case of a FWTK firewall, the kernel is providing complete
services up to the applications. Indeed, the person setting the
firewall up needs to know enough to make sure that the hand-off
between kernel services (connect system call) and application
services (inetd) is coordinated with firewall services (proxies).
It's not hard, fortunately, to get that right, because the mechanism
in question is simple, well-understood, and reasonably "trustworthy."
In the case of a Checkpoint, the kernel is providing a virtual
interface to packet buffering and network cards. Other than
that, the only thing the kernel does for the Checkpoint is supports
logging (filesystem) and user interface (X). What's interesting is
that the firewall software, if it works correctly, should be able to
completely protect the layers above, using the same technology
and code that it uses to protect the network behind the firewall.
Unless you tell the firewall layer it's OK for outsiders to talk to
the X server on the firewall box, they can't. So, if the firewall is
configured sanely, it's a non-issue whether the firewall has an
X server running, or even an old buggy version of sendmail. There
is a big advantage in this approach because you develop a
service/network screening ability for the firewall, which protects
the firewall as well. Assuming it's implemented right and configured
so nobody can talk to it, you could be running the buggiest,
holiest O/S on the planet above that firewall layer, and still be safe.
Firewall/Plus (and probably SunScreen) takes matters a step
farther down the stack and deals with packets directly. This
case is very similar to the Checkpoint approach. From a security
perspective, the only major difference is that it doesn't even rely
on the O/S having gotten the packet queuing/dequeuing layer
right. I don't think that's a big deal, but who knows? Another nice
thing it lets you do is not have an IP address for the firewall at
all -- it's more like a bridge. In that case, you *REALLY* know
an outsider's not going to mess with the applications on that
firewall -- it won't recognize packets destined for it, and even if
it did it won't propagate them up the IP stack to an application
that's listening. In this case, the O/S is really a program loader
and file system and GUI sitting above a packet queuing filter.
What does this have to do with NT or any other O/S for
that matter? Well, depending on where the firewall sits in
relation to the O/S, the O/S may be irrelevant to the
security of the system. So it could be NT, DOS, UNIX, or
whatever, and make no real difference. The one area where
the choice of O/S makes a difference is that each firewall,
depending on where it sits, relies on the layers below it,
as they are provided by the vendor. That means, I suppose,
that a clueless vendor *might* have a hole in their packet
queuing/dequeuing layer. Suppose Microsoft had a hook in
their packet driver that recognized certain packets as
undocumented remote management packets. Then, that
would be a Bad Thing. Of course the same could happen in
UNIX. This is why I worry that a firewall vendor who supports
every platform under the sun may not be taking the time
to diligently research the peculiarities of the implementation
below their firewall level. The only approach that makes the
O/S completely, totally irrelevant is the firewall at the packet
driver level. As you move up the stack to the purely application
firewalls like FWTK then the O/S becomes increasingly
relevant.
Another issue, of course, is whether the O/S is "ready for prime
time." Since the firewall is relying on services below the level
where it sits, kludginess and performance flaws at those levels
may affect its normal function. A memory leak in the connect() system
call with eventually crash a pure application layer firewall like
FWTK but won't bother a Checkpoint. A buffer overrun in the mbuf
routines will crash both FWTK and Checkpoint-type firewalls but will
not affect a packet driver level firewall. And so it goes. I'm not
convinced that NT's IP stack is "ready for prime time" yet so I'd
hesitate to try to build a pure application level firewall on it. A
routing/queueing level firewall would probably be OK since the
only things NT would be doing is GUI and filesystem and it doesn't
have to do that particularly well. A packet driver level firewall
will not give a darn about any of the implementation flaws in the
O/S above it -- as long as it stays running.
I hope this helps clarify some of my thinking on this matter.
A lot of you have grabbed me at conferences and asked this
same question and gotten (probably less organized) variations
of this response. I know that a number of people have felt that
I was somehow repudiating an earlier stated position that
"application level firewalls are the best" -- I still believe that
with all these things, marketing aside, the key factor is the
skills of the people who build them, how well they know their
platform, and how clean/generic the design is.
mjr.
-----
Marcus J. Ranum, Chief Scientist, V-ONE Corporation
Work: http://www.v-one.com
Personal: http://www.clark.net/pub/mjr
|
|
