Re: DMZ design

Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:

>Leythos wrote:
>> In article <3v3o3nF13n3meU1@individual.net>, usenet-2005@planetcobalt.net says...
>>> However, you still don't want any server in the DMZ to be able to
>>> initiate connections to hosts inside tha LAN.
>>
>> Again, it's not going to hold in a web to database design. You should
>> never put the database server in the DMZ and you would never put the web
>> server in the LAN -
>
>Please tell me: why would I punch a hole into the firewall protecting my
>LAN rather than putting a DB server into a (separate) DMZ and opening
>that hole only between the two DMZs? Or (if the requirements allow this)
>do put a DB server into the DMZ, and have the "real" DB server in the
>LAN from where only the required subset is pushed to the DMZ-DB?

The only problem I see with putting a critical DB in a DMZ off the
Internet-edge firewall is that it is now on the doorstep of the
internet. If the firewall is comprimised you've lost the DB already.
Further in, you can have a critical DB behind a second firewall or
implement acl control. Also combining DMZs on one firewall is common,
but can result in rule confusion and unintended opening of access.

Other than that you can do exactly that. However it is common for DB
to interact with multiple backend servers and applications, not to
mention admin/desktops. Rather than open one rule WEB->DBport, you now
have to open many more to allow all the different internal servers to
access the DMZ-DB or possbily in the reverse direction--although I
imagine you wouldn't allow any such thing. And think about that...
you may be placing a DB in a less-secure DMZ than INSIDE. In a PIX all
inside hosts would have access to the DB by default. The DB would be
consider an insecure network by definition. Typically the DB is
considered the most secure element so the DB would run batch jobs and
reach out to other servers. This is a common structure. However, if it
had to reach out to an Internal server that wouldn't be permitted,
because the DMZ-DB is less secure.

>> so, you punch a IP:PORT hole through the DMZ>LAN for 1433 between the
>> exact two IP, and then your web app can access the MSSQL Server in the
>> protected LAN.
>
>No, I don't think I'm going to do this.
>
>> Port 1433 isn't going to allow access to Enterprise manager, and as
>> long as your DB Server is patched, then allowing 1433 from the DMZ to
>> LAN vial IP:PORT>IP:PORT won't compromise the network.
>
>And with one of the setups I described above, my network wouldn't be
>compromised even *if* the webserver got compromised *and* there was an
>unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
>Defense in depth.
>
>cu
>59cobalt
Received on Sat Dec 3 04:18:51 2005