>I've been seaching for some documentation on how CGI scripting works
>in relation to setting up a WWW server on the outside of a firewall
>that would use CGI scripts to send and retrieve info from a database
>server on the inside of a firewall ... ...
>My thoughts since I'm new to this thing is to have the WWW server on
>the screened external subnet... the external users would access this
>server and the server initiate any requests for additional info from
>a database or other backend service on the internal side of the
>firewall... The server would pass these requests through the
>firewall to the internal resources via some sort of CGI script.
The external server is In Harm's Way since it can be directly accessed
by potentially hostile users. Therefore you should host it on a
platform that rapidly detects attacks and blocks them from directly
accessing your internal network. That calls for some form of mandatory
access control like an NCSC B level OS with 2 network boards, or a
Sidewinder. The inside network would be on an isolated subnet that
connected to your inside.
>And these requests could be facilitated via a Generic Proxy on the
The generic proxy only keeps non-database accesses from entering your
system. Use a strong host with 2 network boards with the generic proxy
on that host.
>How more secure is this than allowing all external users to go
>through the proxy server to the WWW servers on the other side of the
>I prefer the first option myself but some others prefer the second
>option becuase it is easier to setup but I think that it is less
>secure becuase if the WWW server is compromised then the intruders
>are already beyond the firewall...
The second option is like an airport security checkpoint without a
metal detector. It lets the honest people in, sure, but it doesn't
stop concealed weapons. Web servers have been compromised before and
it's probably going to happen again.
com secure computing corporation