Re: DMZ design

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

>DigitalVinyl wrote:
>> Ansgar -59cobalt- Wiechers <usenet-2005@planetcobalt.net> wrote:
>>> 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.
>>
>> In reality this is next to impossible in any real world scenario.
>
>Wrong.

Go into any decent sized enterprise and you will not find that all
inbound traffic from the DMZ is blocked. That's what that says. Your
ruleset set is ONE simple line a DENY SRC:ALL-DMZ-NETS DST:INSIDE ANY.
In a small company with almost no servers that could be possible
largely because you don't do much. But once your shop starting
developing apps and you have dozens of DMZ servers that concept is not
enforceable. Politically you won't win. I wonder if the financial
world manages to maintain that standard. Where SMTP, DNS, NTP, and
every other protocol is restructured to only permit pushes into the
DMZ.

>> What this would mean is near 100% of your servers would be DMZ'd.
>
>Yeah. So?

So one comprimised server in the DMZ could lead to a hundred. It could
increase the layer 2 security requiremnt in the DMZ to be
administratively painful. The rule I use is if the Internet must
reach in and touch the server it should be in a DMZ. Everything else
should be further in. This is a fairly safe thing, since the DMZ must
protects your company from IT'S OWN SERVERS. This is sometimes
forgotten. The Firewall is protecting your inside network from
compromised DMZ servers. Load your DMZs up with non-internet servers
and you've reduced all your security to that of an internet-accessible
server.

DB & servers which hold financial and legal information should be
reviewed if there is a legal obligation to up the protectio even
further (FW'ing the DB from the Inside network as well).

>> If you put SMTP servers in the DMZ they MUST reach in and deliver mail
>> to exchange/notes.
>
>No. It can easily be *pulled* from the SMTP server and fed to Exchange.
>Outbound mail is sent through a smarthost. BTDT. Don't know about Notes,
>though.

I've never heard of that setup. But you'd have to do the same with
every protocol and transfer in existence. You can't use internal NTP
servers, or SMTP gateways, or DNS, or printservers, or sysloggers, or
FTP servers. It all has to be reversed or you need to establish all
those services within the DMZ.

>> DMZ these and you open more problems then you solve because RPC uses
>> 10s of thousands of high ports as service ports.
>
>There's no need to DMZ them.

The exchange team here insists that OWA (the web-access server for
Exchange) must be in the same network as Exhcnage and domain
controller. It's likely that it is total hogwash but it sets up a
common political problem. The network/security group is pitted against
other departments trying to reasearch/prove/discredit what tehy say is
true to justify that the above guidelines are adhered to. That's
where this stuff falls apart over time. The human element makes it
impossible.

>cu
>59cobalt
Received on Sat Dec 3 04:18:47 2005