Re: DMZ design

DigitalVinyl wrote:
> 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 doesn't make it impossible.

> That's what that says.

No. It's probably what you wanted to say, but not what you did say. And
not what I am talking about at all.

> Your ruleset set is ONE simple line a DENY SRC:ALL-DMZ-NETS DST:INSIDE
> ANY.

No, my ruleset isn't necessarily that simple, though this is the basic
rule.

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

Of course it is.

> Politically you won't win.

That's a completely different story. Of course you can't enforce this
without being backed by management. And guess what: sometimes you
actually get this backup.

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

There is no need to "restructure" Protocols. You "just" need to choose
the right protocols and the right topology. Yes, it's not always as
simple as it looks.

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

Wrong, because you are by no means limited to a single DMZ. Neither must
each DMZ be accessible from each other DMZ or even from the Internet.

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

This is exactly what I was saying, and why connections from DMZ to LAN
should not be allowed. Why do we argue about this, then?

> Load your DMZs up with non-internet servers and you've reduced all
> your security to that of an internet-accessible server.

Nope. There is no law forcing me to make a DMZ accessible from the
Internet. Think of something like this (single firewall setup to keep
the example simple):

         Internet
            |
DMZ_1 -- Firewall -- DMZ_2
            |
           LAN

DMZ_1 holds the webserver, DMZ_2 holds the DB server. The following
connections are allowed (plus established traffic, of course):

Internet -> DMZ_1 (e.g. only on port 80)
DMZ_1 -> DMZ_2 (e.g. only on the DB server port)
LAN -> Internet
LAN -> DMZ_1
LAN -> DMZ_2

Now tell me: where exactly did I reduce all my security here?

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

DB & servers which hold financial and legal information should be put
into separate networks with no access whatsoever to the Internet.

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

What the hell are you talking about? Of course I can do all of that. I
can use internal NTP server which get (pull!) their time from NTP
servers outside my network. I just described how an SMTP gateway would
be set up. I can have internal DNS servers for my LAN and forwarders to
resolve external addresses. I don't need print servers outside of my LAN
(much less print servers that are accessible from anywhere outside my
LAN). I don't need one central log host if I need to compromise my
network security for that. And of course I can have FTP servers for
anything I want. Though I usually don't want them.

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

I have never had such a setup myself and I haven't used Echange in a
while, so I am in no position to prove them wrong, though I would guess
there had to be better ways to OWA other than allowing access to the
internal network.

> It's likely that it is total hogwash but it sets up a common political
> problem.

True. But I wasn't discussing political issues here. I was talking about
the technical aspects and feasibility of DMZ setups. And especially in
the OPs case I don't see any real 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.

Only if you allow it to.

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