Brad,
We are trying to address the same problem, however we have expanded a
little beyond you initial scope, we feel there is a need for the WWW
to interactively access internal databases.
Our thoughts thus far: would like to discuss a model for running
applications across the Internet, utilizing the world wide web.
We feel that in the near future (1-2) years, we will have a business
need to allow outside access to
certain specific internal data bases. This model would be able to
address these needs through the common gateway interface (CGI)
mechanism used in the http protocol, which is the protocol used by the
world wide web. This would allow for device independent client
platforms (Windows, Mac, UNIX, OS/2, etc), while maintaining control at
the server. The customer only need have access to the internet and have
Web browser software (i.e. Spry, Netscape, etc).
We think this model would be sufficient to insure secure access to data
behind our firewall.
Currently we do not allow any inbound (from the internet side of the
firewall) access to an internal web server. This model would not change
that. In fact, the current proposal for a web server, is to place a web
server on the outside segment of the firewall (see diagram 1).
Diagram 1: Current Firewall
The model We would propose is that the outside web server would utilize
CGI programs to access internal databases through network routers,
bypassing the firewall. It would seem that this would negate the
firewall. But if a router were to allow traffic only between the
exterior webserver and an internal database gateway and the
communications between these two devices were confined to specific
sockets (ports), then even if the external web server were compromised,
it would be very difficult for an intruder to penetrate the internal
database gateway (see diagram 2).
Diagram 2. CGI access between Web Server
and DB Server
This model would prohibit any access on the internet interface
of the Web server, beyond http. This means that no telnet, ftp, or
remote access could be achieved on the Web server. Further, the CGI
interface would be compiled programs only. No scripts would be
allowed, because scripts require the usage of a shell program, which
could allow external users to escape to the shell program. Once in the
shell environment an external user could manipulate the shell command
to commandeer the Web Server machine.
The router between the Web server and the DB server would allow only
traffic between these two devices. Thus, even if the Web server were
compromised, it would only be able to communicate with the DB Gateway.
The DB gateway would provide its own CGI program that would 'talk' to
the CGI program on the Web Server. This interface program would only
talk on certain sockets and would establish it own OXY specific
protocol procedure. This protocol would include an authentication
algorithm designed to defeat access by outside users. Again there would
be no UNIX script or equivalent usage. Had anyone penetrated the Web
server, they would have to be aware of the protocol and its
authentication algorithm to gain access to the DB server. The DB server
would be a non UNIX box, that would not support ftp, telnet, or any
remote unix access.
Thanks,
Bill
______________________________ Reply Separator
_________________________________
Subject: Securing Web data.
Author: Brad Smith <brad @
cse .
ucsc .
edu> at internetoxy
Date: 6/19/95 12:05 PM
Hello,
Is there any accepted wisdom for, or even first attempts at a solution
to, resolving the conflict between wanting to put a Web server on the
DMZ, outside of a firewall, and wanting to keep some of the data
accessible via the Web server inside the firewall.
Based on my understanding of Web servers and firewalls, this conflict
comes up when you have valuable data that you want to e.g. sell via
the Web. You don't want the Web server inside because it's difficult
to really secure, but you don't want the data outside because it's not
something you can throw to the wolves.
The one thought that comes to my mind is a mechanism that involves a
simple file transfer protocol that is well authenticated and encrypted
between the Web server machine and an internal machine... perhaps even
a long-standing TCP connection that is setup when either host reboots.
Any answers, or corrections to my construction of the problem appreciated.
Brad Smith
Computer Sciences, UC Santa Cruz
brad @
cis .
ucsc .
edu
|
|
