mdr @
vodka .
sse .
att .
com writes:
>The box is basically modeling
>connections, examining the packets contents, driving a state machine, making
>pass/drop decisions. This is similar to the Java virtual machine idea
>of evaluating OP codes rather than executing raw native binaries.
Not at all. You missed a really important distinction.
"Op codes" implies you are executing part or all of the data
or packet as a command. That is not how it's done: the packet
is mere data which is *examined*, not *executed*, and either passed
or not passed based on a truth table. That is, conceptually, the
same as what any other firewall does.
> 1) Can I break the model by sending it ill formed ethernet
> frames etc?
I couldn't when I tried but maybe you should try too.
> I don't know. Bringing it down might be doable.
What's such a big deal about that?? I've
crashed many versions of UNIX with sprays of packets with the
ipdst==target and a valid checksum around otherwise random
data. Unless they've fixed the stack, any firewall built
on SunOS, for example, will panic if sent a packet with an
ip_options with invalid size..
> 2) Is it sufficient for enforcing network security?
> To reach the current state of the art as far as
> fielded systems go, it has to show me that it is capable
> of the same level of trust that I can achieve with a proxy.
I'll make a meta-argument: ALL firewalls have modes
in which they can be configured to let nothing through. Most
firewalls have modes in which they can be configured to let
everything through. Therefore, any firewall that fits that
profile is approximately equal, if configured approximately
the same way. What is more important in all firewalls
is the access control policy the administrator keys into it.
Can you tell me, please, how a proxy firewall
with a plug-gw plugging all USENET news to an internal news
host is ANY different from a router configured to do
the same thing?? I can't see a difference except that
the O/S' involved are different. Now, if you told me that
your proxy did something magic with news then that'd be
another story.
In practical terms it offers the same kind of
functionality as a Checkpoint or a Sunscreen or whatever.
If you're not comfortable with them then you're not
comfortable with this, either. But that's up to you.
The only reason I am weighing into this discussion
is because I don't think people are thinking the problem through,
and are knee-jerk reacting to implementation details. I should
also mention that I am a presently competitor of Network-1's
and was paid to look at their product when I was an independent
consultant. I'm not being paid to defend them; I'm just
trying to clear up some mistakes I think people are making
in how they think about these technologies.
>In your opinion, is the architecture guaranteed to always fail safe?
I'm an engineer, not a theoretician, and I would
never say anything was "always" anything or "guaranteed"
anything. :)
>In your opinion, have stateful packet filters reached the same level
>of trust as proxies?
They're real close.
What I see happening in firewalls these days is that
the remaining outstanding problem is the "incoming data
problem" -- what to do with unsolicited stuff that did
not return in response to an outgoing request. Firewalls
generally aren't very good at that. Proxies (and I have
written a few) *TRY* to help protect against data driven
attacks in incoming data but the floodgates are opening with
Java, etc, etc, etc. That's the biggest problem, and I
think no firewalls handle it very well. [Which is why
we're doing some of the things we're doing at V-ONE]
>How well do they model the application level semantics?
They don't; they model connection states, much
like a CheckPoint or Sunscreen.
>Also, what do they do to assure that the program that boots is the program
>that they began with?
The same way other firewalls do: they try to make
sure that the parts that talk to the network don't do a
lot of file access/modification, and never under control of
a remote user/attacker. Same design criteria as other
firewalls.
> And how do they determine when the
>program goes south?
It's a PC. It hangs. :) You can't tell you're hung
once you're hung. :)
UNIX is better, I suppose: it panics. :) I recall
a number of in-kernel firealls for UNIX which have wedged
or crashed machines. Proxy firewalls don't do that, admittedly.
mjr.
Follow-Ups:
|
|
