William Stout supposedly wrote:
>
> What a strange thread. Everything else in the list concerns protecting the
> network behind the firewall, this thread is concerned about protecting the
> firewall itself.
It's that hard to imagine that the two are related? Sorry, but the
existance of the that opinion and the number of otherwise informed
persons who seem to hold it really continues to amaze me.
>
> Firewall software is separate from the platform it runs on. The platform
> (O.S.) should be administratively hardend already. Since there are no user
> accounts on a firewall, security ratings based on ability to protect the
> O.S. from users is irrelevant. Firewall software runs as root as designed
> by ultra-paranoid firewall programmers.
>
"Administratively hardened" usually refers to a combination usually
including (but not limited too):
chroot jails for proxies
stripping unneeded binaries like /bin/cc
detuning the kernel to remove unneeded modules such as NFS
no user accounts
removing unnecessary services such as rlogind etc.
code review for proxies other portions of code that
send/receive from the net.
read-only filesystems to hold trusted code
crypto-hash sums on binaries periodically reviewed (eg tripwire).
waving a dead chicken over it
These are all *good* things to do! [the dead chicken approach has been
a documented as commercially successful by several vendors :( ]
This all falls short on the following points
1. Incomplete Auditing
2. Incomplete Assurance
3. Incomplete Control of privileges
4. Incomplete Control of data flow.
1. Incomplete Auditing. Auditing by proxies occurs only if the proxy is
working as designed. Secure OS's are able to audit the actions of unmodified
binaries. Each system call such as 'open, exec' etc will be
recorded. That makes it possible to detect when sendmail forks a root
shell or opens /etc/shadow. Incomplete auditing implies incomplete
intrusion detection.
2. Incomplete assurance. "Administratively Hardened" is a vague term
that means what ever the vendor says it means. Secure OS's have a
formal model of security against which the implementation is evaluated
by an independent party. Unfortunately assurance never gets to be
"complete", just more thorough and measurable.
> O.S. from users is irrelevant. Firewall software runs as root as designed
> by ultra-paranoid firewall programmers.
Even ultra-paranoid firewall programmers make mistakes.
The argument "the proxy is small, well written, thorougly analyzed" is
fine as far as it goes, but the syslog buffer problem tripped up a
number of these. Of course secure os's also have bugs and their much
larger and harder to analyze. My point is this: two layers of
protection are better than one.
3. Incomplete Control of privileges. Root is root is root.
Without sufficient control over privileges such as the ability
to open network connections, proxies on "Administratively
Hardened" OS's still have to run as root to listen on low
ports and do other parts of their jobs. If such a proxy is
compromised it may well overwrite portions of the OS code, create new
OS code, or just setup unauthorized connections that bear no relation
to its original service.
A trusted OS (with some networking extensions) will be able to
control which binaries are able to bind to which ports and which
programs can create/modify system software etc.
I do admit that Chroot does protect the OS from the proxy to some degree.
And read-only file systems surely do that job. And you could control
to some degree what a proxy does, if the proxy can bind *before* it
does the chroot. But neither of these adequately controls the privileges
of the proxy to establish new and unauthorized connections.
Furthermore, it will take special kernel extensions to prevent the
proxy from breaking out of its chroot jail.
If the OS provides an additional layer of security mechanizms,
overall firewall security is improved.
4. Incomplete Control of data flow. Assuming that data on one side of
the network is either more trusted or more sensitive (confidential) than
the other or in some way distinguished from the other data, can the
firewall trace the data flows from one to the other? Secure OS's can
be configured to handle this in several ways. Mail and ftp can be set
up to be unidirectional by separating its duties into a reader process
and a writer process. The writer process creates mail files, the
reader then forwards them. The privileges (access rights) of the reader
and writer can be taylored so that mail only flows in one direction.
For example the writer could create files that are manditorially read-only
to the reader process.
This could serve any number of purposes, for example mail and ftp data
could be scanned before forwarding. The point is that no other program has
been authorized to both read and write mail or to forward mail or to
establish sufficient connections to perform such a task. The Secure
OS allows you to assert with greater confidence that all mail is
flowing via the intended mechanizm. Futhermore, a compromised reader
or writer program will not be able to reverse the flow of data. Sorry
if this point is confusing, maybe I should have picked a different
example. :(
Now a valid question would be "is all this extra work on the OS worth it?"
Answer: it all depends on what your protecting, what its worth, and
against what risks.
However as a researcher, I'm interested in anything that advances the
state-of-the-art in firewall security. The use of trusted OS's, MLS,
DTE, all improve firewall security. But they are not an end in
themselves--only a means to an end.
Mark Riggins
Secure Systems Engineering
AT&T Bell Labs
PS: I do admit to being heavily biased toward secure OS's, but not
without reason.
References:
|
|
