Re: DMZ design

sc_wizard29@hotmail.com wrote:

>Hi everyone, I would like to install a web-server on a DMZ. This
>web-server will access a database hosted on the private network.
>In a book called "The Practice of Network Security", the 2 following
>DMZ design are suggested :
>
>Design #1 (private network and DMZ connected to same FW) :
>
>internet -> FW -> private network
> |
> +--> DMZ
>
>Design #2 (2 FW) :
>
>internet -> FW -> DMZ -> FW -> private network.
>
>The author says that "The most notable problem with design #1 is that
>there is no way to securely update information on the servers. There
>are also no facilities in place to secure the database transactions
>between the web server and the database server, or any of the backend
>servers".
>
>I'm afraid I don't understand what the author means... if I use design
>#1 and if the FW is correctly configured, what can prevent me from
>securing the database transactions ?
>
>Thanks for helping...

The difference between these two is that there are two physically
different firewalls. And really that is the ONLY practical difference.
You would setup all the same rules. In design #2 if the first FW is
compromised, by that I mean the hacker has admin control over the
firewall, the second FW is intact. You would write all the rules in
the same ways, and you would still have to open the same ports through
the firewall for Web->DB connectivity.

The second advantage to 2 firewalls is administrative complexity.
Writing rules can be easier when you don't have a lot of interfaces
especially if you divide functional traffic across different boxes.

-------OUTSIDE------
   | |
  FW1 DMZ3--FW2--DMZ4
   | |
--------INISDE------

In the above example you can divide rules up across the two firewall.
General Internet access can be handled by FW1, while FW2 focuses on
DMZ related access only. People can easily create INSIDE->ANY rules
that mistakenly give access to DMZs when the Internet rules mix in.
Ifind it easier to screw up rules on the PIX, especially if you try to
use their GUI. Checkpoint had better tools for avoiding those kinds of
mistakes.
Received on Sat Dec 3 04:18:46 2005