Re: DMZ design

From: Ansgar -59cobalt- Wiechers (usenet-2005_at_planetcobalt.net)
Date: 11/29/05 

Date: 29 Nov 2005 19:22:31 GMT

Leythos wrote:
> In article <3v3d40F13iu6tU2@individual.net>, usenet-2005@planetcobalt.net says...
>> 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.

It does work in the real world, though many people seem to be reluctant
to do it right, because the other way is so much easier. In fact I
pointed out two ways how to make it work.

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

LAN nodes connecting to a server in the DMZ don't break the DMZ. A DMZ
does not mean to prohibit any traffic between LAN and DMZ, it just means
that no connections can be initiated *from* DMZ *to* LAN. That's what
stateful filtering is for.

> A FE/BE design for exchange would be better.

It's possible to have setups like that.

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

Both setups are more or less equivalent. Having two firewalls gives a
little more protection to your LAN (because the inner firewall, running
a different system on different hardware, isn't vulnerable to the same
exploits as the outer firewall), but adds some more complexity, because
you need to maintain two different systems. A three-way setup is a
little easier to maintain (and thus probably a little less prone to
configuration glitches), but if an attacker manages to compromise the
firewall he has access to either DMZ and LAN.

However, you still don't want any server in the DMZ to be able to
initiate connections to hosts inside tha LAN.

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

Relevant Pages

  • Re: Web portal security
    ... win2003 standard server with IIS, SSL enabled and will be placed on ... So I will be fwding port 443 in firewall to my DMZ port. ... Well, assuming you are going to use teh SQL database from SBS, you can ... subnet than my LAN and map one to one from firewall to dmz. ...
    (microsoft.public.windows.server.sbs)
  • Re: 2 NICs Configuration Problem
    ... Servers on the DMZ are public, ... provides NAT for the LAN machines, allowing them to reach the Internet ... effectively bypassing firewall filtering to that server. ... Ethernet adapter Server Local Area Connection: ...
    (microsoft.public.windows.server.networking)
  • Re: Where to put the server
    ... Put the 2003 IIS Server in the DMZ. ... SBS box or another LAN server. ...
    (microsoft.public.backoffice.smallbiz2000)
  • RE: fedora-list Digest, Vol 6, Issue 266
    ... Re: OT: Setting up a forwarding mail domain in DMZ without ... Re: Sound Problem ... downloaded the yum.conf for fedora from Redhat's website. ... Server: Fedora.us Extras ...
    (Fedora)
  • Re: Groklaws "Bias" and the SCO DDoS Attack
    ... >on the same local LAN your office machines are you can congest that ... routers, with port 80 redirected to a web server on the LAN side. ... I've also used Sonicwall DMZ routers. ...
    (comp.unix.sco.misc)