-----BEGIN PGP SIGNED MESSAGE-----
Olga> Date: Tue, 23 Dec 1997 16:28:34 +0300 From: "Demina Olga"
Olga> <olga @
spbex .
ru> Subject: Online Information & WWWServer
Olga> Hello all. We are going to put our "public access" WWW Server in
Olga> DMZ. On the other hand, we have to public online information from
I assume that DMZ == network between firewall and border router. An
increasing number of documents use the term to describe a network attached to
a third network interface.
Olga> the secure LAN serment on "public access" WWW Server. So the
Olga> problem is: Public WWWServer have to get online information from
Olga> secure network. How to organize connection between DMZ and our
Olga> secure network? Any suggestions are appreciated.
There are two options:
1. allow WWW server to access master database server
2. replicate database to slave server and use that
Which option is best depends on the relative sensitivities of your networks
and the information involved.
In general, putting the WWW server behind the firewall, on a third
interface is my first recommendation. That allows the WWW server to be
protected from attacks, and prevents other nodes from trying to
impersonate the WWW server to the firewall.
Having done that, I say:
1. if the data doesn't need to be up-to-the-instant (for appropriate
definition of "instant"), the consider replicating the database. A
number of commercially available databases can replicate in both
directions with good security on what can be updated. Doing it under
NT in my experience, without Microsoft file sharing, is a major
pain. Give me SSH and/or Perl's FTP module and Unix please. Now that
SSH win32 command line utilities are available, and another year
(since I tried) of NT perl5 development, and it would be easier.
2. if the data does need to be up-to-the-instant, then can the
master database live on the service network (third interface) with
the WWW server, or on the same box? If you need to access the
database from the private network, can you proxy it from the private
network to the service network? That is safer than allowing the
service network to inititate to the private network.
3. encrypt. I have no confidence in any encryption done by any
database vendor I have seen.
4. is the database the most important thing on your private network? If
so, then your security policy should perhaps be rethought.
:!mcr!: | Network and security consulting/contract programming
Michael Richardson | I do IPsec policy code for SSH <http://www.ssh.fi/>
Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html";>mcr @
sandelman .
ottawa .
on .
ca</A>. PGP key available.
Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/";>sales @
sandelman .
ottawa .
on .
ca</A>.
ON HUMILITY: To err is human, to moo bovine.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNKCzS6ZpLyXYhL+BAQFoqQL/S0TF/H9k7FUIPDD8UL6wEBPYPoXJNFpA
uy7ps0pbZpZzOO7Ek1yYSPnBKwX/zprX2kFfa2DZZtznQKrrRYLTQSzGmRB5An+m
RxvssyUyoZgCd5qBYdjVO4gnqb/9LlU0
=/x3k
-----END PGP SIGNATURE-----
|
|
