Re: DMZ design

DigitalVinyl wrote:
> 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.

That would depend on the router/firewall topology. You may very well use
two or three firewalls in this setup, avoiding the risk you mentioned
at the cost of somewhat increased complexity, e.g. like this:

  Internet -- Firewall -- DMZ_1 -- Firewall -- LAN
                            |
                         Firewall
                            |
                          DMZ_2

> 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.

True. But who said maintaining security in complex scenarios was easy?

> 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

If that's necessary, I think the whole application and DB design should
seriously be re-considered. It is very likely to be flawed.

> or possbily in the reverse direction--although I imagine you wouldn't
> allow any such thing.

Unless being forced to allow it.

> And think about that... you may be placing a DB in a less-secure DMZ
> than INSIDE.

No. DMZ and DB are just as secure as the LAN in the scenario proposed by
Leythos. Only in my scenario the security of my LAN is *not* reduced.

> 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.

Wrong approach. You're looking at the hardware first and then consider
what security you can achieve with that hardware. I try to work out what
security I need first and then consider what hardware it would take to
implement this. I'll admit that in the real world you'll have to cut
back sometimes, but you should *never* restrict yourself from the
beginning. That's simply the wrong approach to security.

cu
59cobalt

-- 
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668