Re: DMZ design

Leythos <void@nowhere.lan> wrote:

>In article <3v3d40F13iu6tU2@individual.net>, usenet-2005
>@planetcobalt.net says...
>> sc_wizard29@hotmail.com wrote:
>> > 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".
>>
>> The mere network topology doesn't support this opinion in any possible
>> way.
>>
>> > 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 ?
>>
>> You don't want *any* host in the DMZ to be able to establish connections
>> into your private network, since that would break the DMZ. Put the
>> backend servers into the DMZ (or a separate second DMZ). Replicate
>> (push!) the relevant data from your backend servers to servers in the
>> DMZ. But *never* *ever* allow connections from the DMZ to the internal
>> network.
>
>The never allow the DMZ to reach the LAN doesn't work in the real world
>for Web/Database applications. In the case of a web server with a
>database backend, you don't want the DB in the DMZ, you want the DB in
>the DMZ. What you setup in the firewall is what makes the difference. In
>these cases you allow (for MSSQL) DMZ:IP:1433 to LAN:DB IP:1433 but only
>for that port and only those two IP. You don't do Windows
>authentication, only SQL User authentication (and you don't use SA).

This is what makes sense. What you *never* want to do is open
administrative ports(RPC, RDP, telnet, SSH, X-windows) inward.
Insecure servers should never have an opportunity to administrate more
secure servers. This can be difficult to get across to programmers and
operators who will not consider security when deciding where to build
scripts and jobs to run. You want to design communication so secure
servers reach INTO the DMZ as much as possible. FTP Get on a secure
server to pull files, not FTP Put from the insecure one.

>There are other instances, where you create a rule that allows Nodes in
>the LAN to reach the Mail server in the DMZ (exchange in this example),
>but the rule also permits the mail server to reach the Nodes, BUT only
>if the nodes contact the exchange server first. A FE/BE design for
>exchange would be better.
>
>We've used both design #1 and design #2 and I like to have the firewall
>appliance setup with the LAN on jack 1 in a subnet like 10.4.0.0/16 and
>the DMZ in a subnet on jack 2 like 192.168.4.0/24. The jacks are not
>connected like the cheap NAT routers, they require rules to map between
>them.
Received on Sat Dec 3 04:18:46 2005