[271] in WWW Security List Archive
Re: Secure W3 Server
daemon@ATHENA.MIT.EDU (Ken Shores)
Wed Dec 14 19:15:08 1994
Date: Wed, 14 Dec 1994 15:27:07 -0500
To: hallam@dxal18.cern.ch, smb@research.att.com, www-security@ns1.rutgers.edu
From: Ken Shores <kshores@draper.com>
Cc: hallam@dxal18.cern.ch
Reply-To: www-security@ns1.rutgers.edu
At 05:12 AM 12/14/94 +0900, hallam@dxal18.cern.ch wrote:
>
>The point about firewalls is well taken though. httpd is not a firewall proxy.
>TIS have one of those. Really what a firewall achieves is what chroot attempts
>to provide - a safe partition.
Phill,
I agree with most of your comments, but I really have to take exception
to the above. A firewall (attempts to) provide a safe wall, which divides
an administrative domain from another administrative domain (typically a LAN
from the Internet). A chroot partition (attempts to) provide an encapsulated
environment, where weaknesses in access controls can't be used to affect/view
the outside environment. You could build a partition by putting the server
between two firewalls (although that still wouldn't help the host it's on)
but putting the server inside your firewall (using a proxy like TIS) won't
protect you if the server itself is not "secure". Puting the server outside
the firewall seems to be fairly common practice right now (for those of us
with firewalls), but leaves the host vulnerable in other ways.
I see server security has having two parts (in addition to the protocol
security itself):
1. controls in the server which restrict the server to defined actions.
The controls in the CERN server, which can be used to partition the
directory in which executeable items live from the the directory tree
in which fetchable items live are an example of this. As noted by
others, such controls are inherently complex and hence potentially
vulnerable to both bugs and misconfiguration.
2. controls in the host OS which protect the host from flaws in the
server. File system access controls (run the server as "www" or
"nobody" and don't give them read access to /etc/passwd) are an
example of this, as are system specific controls such as chroot.
These controls are hopefully simpler that server based controls, and
more proven.
A firewall provides a form of item 2, provided that you regard the whole
server host as expendable, and located it either outside your firewall or
between two of them.
Optimally I think you'd want to locate the server inside the firewall, both
for ease of management and to ensure that you gained the full benefit of the
firewall for protecting the server host. This is especially true if you are
going to maintain commercially sensitive information on the server. To do
this you really need a strong sense that the server is not going to provide
some access path through your firewall. Server code alone (IMHO) can't do
this, you need host based controls as well.
Given current technology, I'd put the server between two firewalls, but
that's probably not cost-effective for a small organization, and doesn't
address data confidentiallity issues on the server either. We need better
host OS security (to allow use inside the firewall), as well as servers with
good controls (to allow serving information which has distribution
restrictions).
Ken
-----
Ken Shores, Sr. Network Analyst The Charles Stark Draper Laboratory, Inc.
kss1376@pop.draper.com 555 Technology Square, Cambridge, MA 02139-3563
(617) 258-2529 Mail Stop 33
