Marcus writes:
> >So you believe that OS security has nothing to do with network security?
> Actually, in this case I think that's a reasonable
> position to take. I wouldn't expect any of the readers of this
Good to hear from you again Marcus.
> I wouldn't expect any of the readers of this
> list who have a vested interest in secure operating systems to
> agree with that view, of course. :)
I admit freely to having worked on a development team that produces a
secure version of UNIX. The product is AT&T SV/MLS. It has been
evaluated at B1 with some portions of higher level functionality.
Now that doesn't make necessary make me secure OS bigot. But it does
make me question claims about security w.r.t. OS's.
>
> Network-1's box acts like a super-smart bridge, just like
> a SunScreen. It's hard to attack because it's not there. The "not
> there" effect is, against network-based attacks, infinitely
> stronger than any host-based security I can imagine. Basically,
> firewalls that operate in the super-smart bridge mode are going
> to look at the contents of packet headers and data but don't
> execute anything *from* the contents. So you're not able to
> send it a packet that will trigger a sendmail hole, or any of
> that nonsense - the box itself doesn't listen to packets directed
> to itself.
Finally an intelligent arguement. 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. It adds a
layer to the security model. I like layers :)
Now the only questions are:
1) Can I break the model by sending it ill formed ethernet
frames etc? I don't know. Bringing it down might be
doable. Getting it to excercise foreign code...sounds
tough. Getting it to alter its own state so that it
enforces a different set of rules...tough but
maybe not impossible.
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.
Now I agree that a packet filter *can* be made as
secure as a proxy. Face it: both approaches have
packets entering one nic and leaving on another. The
what's in between thing can become as complicated as
one desires.
When all is said and done, they will become
equivalent. But all's not said and done yet.
>
> Consider a CheckPoint or a SunScreen. CheckPoint's
> product runs in kernel space, as does SunScreen. Neither
> of them is running in a protected virtual address space.
> They are in the kernel, they are below the application
> interface. Literally speaking, they are below *UNIX* and the
> fact that they are running on a "UNIX box" is completely
> irrelevant. Both CheckPoint and SunScreen protect all that
> flimsy UNIX stuff by hiding it from the attacker. In
> CheckPoint's case, the UNIX stuff is screened using their
> in-kernel screening engine. In SunScreen, ditto, plus the
> SunScreen can also do the "invisibility trick" to further
> protect itself from direct attack. What's the difference?
Another good point. In fact IP filtering occurs below userlevel
on every unix OS. Even secure OS's gain here only w.r.t proxies.
Implementing a packet filter on a secure OS is of limited benefit
unless the kernel has been modified to be more modular. Even then,
if the services of an OS are not needed, it would be unecessary.
>
> >DOS is a giant step backward in terms of security.
>
> You're conceptually locked into the idea that you're
> comparing two operating systems. You're right that DOS'
> security sucks, but that's not the point, here. DOS is acting
> as a program loader for a program that is, essentially "firmware"
> for something that looks and acts like a smart bridge running
> a "firmware" kernel that isn't concerned about attack from
> over the network because it, literally, isn't talking to
> the network: it is just sucking chunks of memory back and
> forth, after checking an in-memory truth table, updating it
> as necessary, and that's it.
Yes I understand this. That's why I caveated the whole posting with:
Are we talking simple packet filter or application level gateway here?
For the latter, if they replace DOS with their own application, what
does the scheduling, memory management, I/O etc?
It turns out that they are talking about the former + stateful packet filtering.
> >So FireWall/Plus has now *become* an operating system.
>
> Not quite, really, it's just a program. "Operating
> system" assumes a lot of baggage about multitasking, multiuser,
> daemons, dragons, different permission states, etc. My understanding
> of how it works is that it's a just a big program that acts
> a lot like firmware except it boots from a primary loader called
> DOS.
If they don't try to implement "tasks", then I agree with you,
it's not really an OS. It is however a big program capable of
communicating with interfaces connecting the corporate LAN to the
internet. So it does need analysis. As you state later in this
posting, you have participated in that analysis. Now that means
something to me!! Why didn't we start there?
>
> >Agreed, its not a bad idea. Is it as secure as a proxy on a gateway? No.
> >Why? I can put the proxy in a can and watch it run.
>
> Here I have to disagree with you, which is a weird
> position to be in as the "inventor" of proxy firewalls. :)
> Debuggers for DOS programs are a dime a dozen and we're
> talking about a DOS program.
I find myself in wierd positions all the time, guess it comes with the
teritory. ;)
>
> Most importantly, though, the fact that it's not
> running a full kernel with all those daemons and multiprocesses
> and a full protocol stack and all that stuff - that makes it
> a HELL of a lot easier to get right than a UNIX machine.
Yes you can "get it right", but can you put it in a can and watch it
run?
Now believe me, I place a lot of stock in "getting it right" to
start with, but being a belt and suspendors type of security guy, I
like to have some way to know when I "got it wrong."
>
> >W/o some independent third party doing analysis,
> >all I have is your word "trust me its secure."
>
> Here I have to step forward and confess to being an
> independent third party who once did an in-depth red-team
> analysis of Firewall/Plus. And I have to say that the
> design is damn nice and I like the fact that they got rid
> of UNIX. As an independent consultant, I spent several days
> cooking up magic packets and tossing them at a Firewall/Plus
> on my home LAN, and let me tell you, it was a bOring lesson
> in futility. Basically, the thing isn't there to attack. It's
> not unlike trying to break into a bridge or repeater. I
> spent more time trying to tickle the rules tables and overload
> it with packets. A fast BSDI machine was able to bring it
> to its knees with packets and it did what any self-respecting
> smart bridge would do: it threw them away and let TCP retries
> do their thing.
I'm *much* more impressed with this than with any claim that its more
secure because it boots DOS instead of UNIX.
>
> >Now if one were to start from the ground up to build a special purpose
> >OS just for firewalling, you could design something incredibly secure.
>
> Special purpose progrem just for firewalling is pretty
> much what they built. You're catching on. It's not an OS because
> it doesn't have to be.
>
> >But it would be a lot of work.
>
> Only if you tried to add deamons and a protocol stack
> and all that crap that multiuser multitasking systems are
> saddled with. Your conceptual fixedness is frustrating.
Sorry, I'm not fixated here, the original posting did not make it
clear whether they were supporting a stateful packet filter or a
proxy like interface. Although I kinda thought the former.
If they intend to reach the same level of trust as that of a proxy
running on a secure OS, they'll still have a lot of work to do.
Being able to do externally monitor the program independently w.r.t
connections that it allows or packets that it processes, is hard to achive
without some form of encapsulation, and then it starts to look like an OS.
The down side is that while UNIX does provide the ability to run a
proxy in its own address space, UNIX comes with a lot of insecure
baggage. Getting rid of the baggage or securing it makes sense, and
getting rid of it is easier than security it. However out with that
baggage goes the notion of a proxy running in its own address space,
modeling a particular service. Making a stateful packet filter as
secure as a proxy is going to be a challenge.
>
> >And it would require third party
> >evalutation.
>
> Any vendor who is producing a firewall product, if they
> are not completely insane, will have knowledgeable third parties
> red-team their products. But even that boils down to who is a
> knowledgeable expert and whether or not they are credible.
> Pissing contests of "whose expert is bigger" is a waste of
> time. Third party product evaluation (unless you are in
> orange book la-la land) is for the benefit of the vendor,
> not for giving the customer warm fuzzies. I red-teamed
> Firewall/Plus for Network-1, and I'll leave it to you to
> decide whether or not I'm qualified to evaluate the technical
> merits of firewall implementations. That's a matter of
> opinion.
If you're not qualified, who is?
I come away from this posting much more impressed with the effort put
into Firewall/Plus. They've done third party eval work and someone
that I trust puts faith in their archiecture.
In your opinion, is the architecture guaranteed to always fail safe?
In your opinion, have stateful packet filters reached the same level
of trust as proxies?
How well do they model the application level semantics?
Also, what do they do to assure that the program that boots is the program
that they began with? And how do they determine when the
program goes south?
I will never be satisfied with the "it boots DOS , what could go
wrong" theory. However I could become acclimated to the "it boots
safely, takes over the box, and models application level stuff to make
decisions; furthermore its code has been independently tested by top
level security experts respected in their field."
Thanks for all the info.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
References:
|
|
