Marcus,
>
> 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.
Not really, op codes aren't executed they're evaluated. A Java VM machine
reads the op codes and changes the values of its internal
representations (models) of an instruction pointer, memory, etc.
For modeling a ftp session, a stateful patcket filter does essentially
the same thing, it examines an op code in the data (get) and changes the value
of an internal representation (model) of a ftp connection to allow
a data channel to pass thru the filter.
If the modeling code in either the Java VM or the stateful packet
filter has errors, then bad things can happen. Both models are driven
by the data being transferred!
Whats more complicated to model, Java's VM or a hodge-podge of
protocols never intended for modeling in the first place?
>
> 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..
Pretty sad huh? But your right, no big deal.
>
> > 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
check.
> firewalls have modes in which they can be configured to let
> everything through.
check.
> Therefore, any firewall that fits that
> profile is approximately equal, if configured approximately
> the same way.
maybe. But then why do we have more than 2 firewall vendors? Are
they all selling the same wares? Or are some more secure than
others? One selling point to me is the level and type of analysis
that went into the design. That's why I was more impressed with
Firewall/Plus's independent review by you than with any claims that
they make themselves.
But I will say this: the difference between the security of one
firewall vs another probably has more to do with their configuration
than their geneology.
> What is more important in all firewalls
> is the access control policy the administrator keys into it.
check.
>
> 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.
It might stop packet fragmentation based attacks.
But in general a good point. A proxy that just forwards packets
blindly is not much better than a router. Its just slower.
[No, I haven't bench marked that :)]
>
> 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.
Agreed: but were not comparing plug-gw vs stateful packet filter,
we're comparing state-of-the-art proxy vs state-of-the-art packet
filter. (Actually this started out as why not boot DOS)
Right now state-of-the-art proxy is better. Why?
1) because I can put it in a can and watch it run. That's
because its running in its own address space and has to
request connections via a system call interface.
2) it is specific to a given service such as telnet, ftp etc
and can easily model the service.
3) authentication can be done in stream.
4) No packet from the outside ever makes it to the inside.
This limits packet fragmentation attackes etc to
attacks against my well-written proxy.
Now admittedly, the packet filter can eliminate packet
fragmentation attacks by rejecting fragments or by
examining offsets etc, but suppose a new packet
options attack arises. I assert that the proxy will
protect the internal machine better because it will
set up a vanilla connection to that internal host w/o
any special options.
Of course, its kinda silly listing these things, you are obviously
aware of the merits of proxies :) and could make a better list yourself.
So I'm listing these for other readers, not for you.
Of course *all* of these items can be done with a sufficiently complex
stateful packet filter, but I'm not aware of any that *does*
accomplish all this. Notice that item #4 shows that even plug-gw
might be marginally better than the router.
Is the difference in security between proxy and stateful packet filter
enough to worry about? It depends.
>
> 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.
I'm always glad to hear your opinions, they've always provided a lot
of insight. What you've helped me see is that the stateful packet
filters are making good progress. But I don't see them as yet
equivalent.
>
> >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. :)
Right! My experience tells me that everything that can't happen will
happen.
>
> >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]
Where can I find your white papers and stuff?
Executable data content is a huge problem. Java is just the tip of the
iceburg. Microsoft is going to add weberized (did I just make a new term?)
verions of visual basic, OLE, COM etc.
> > 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.
Not all south bound programs hang.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
PS: When I first joined the list I posted that application level gateways
and packet filters could be made equivalent in terms of security, and
that the primary difference was one of performance and versatility.
You've since been doing some work with firewall performance metrics and
obviously have a great deal of experience with the security of both
approaches. What do you think? Are there significant performance
differences in the two approaches? What causes the performance differences?
I assume by your latest posting that you concur that packet filters
can be made as secure with sufficent effort.
Follow-Ups:
References:
|
|
