How to create a manageable DMZ architecture?

My problem is that there are services on my internal LAN, such as
Kerberos, NTP, DNS queries & xfers, etc, that I need my servers on my
DMZs to access. I am thinking of building 2 DMZs; one for my web
servers and the other for my DB servers. After doing a little DMZ
design research I found two threads that make me wonder:

1) Never let a server on a public accessible DMZ segment initiate a
connection to a server on a higher security segment (i.e. server in
the LAN).

2) To allow administrative access to servers in the DMZ, create an out-
of-band management subnet by installing another NIC on each of the DMZ
servers. This dedicated NIC would allow administrative access,
Kerberos, NTP, etc. None of these servers would allow packet
forwarding.

With #1 being stated, how do you allow DMZ'ed hosts to access these
internal services that are cannot be easily replicated? Replicating
all of these services for each DMZ as well as the LAN sounds like an
administrative nightmare.

#2 made me wonder whether security is really gained. Couldn't all of
this service and administrative access take place over the main
communications channel (i.e. in-band) with less hardware and
configuration? It seems like the only thing gained would be access to
the servers via the out-of-band channel in the event of a DoS on the
in-band channel.

What are some of your DMZ design guidelines and best practices?

Would it be so bad to just poke a few holes through the firewall from
the DMZ to the LAN and then really lock down those internal servers,
not allowing them to initiate connections outside of their local
segment?

Re: How to create a manageable DMZ architecture?

In article 579b081ce7ce@p69g2000hsa.googlegroups.com>, clintpachl@gmail.com says...
> My problem is that there are services on my internal LAN, such as
> Kerberos, NTP, DNS queries & xfers, etc, that I need my servers on my
> DMZs to access. I am thinking of building 2 DMZs; one for my web
> servers and the other for my DB servers. After doing a little DMZ
> design research I found two threads that make me wonder:

Is sounds like your web server is part of your windows active directory
or domain structure in the lan - BAD MOVE.

As for SQL - your application should be connecting over TCP 1433 using a
user/password connection, not a Windows Authentication connection.

NTP - no need to allow it to access the LAN, have it sync with the same
public NTP server as your main NTP server.

DNS - again, you could open TCP 53 between the DMZ and LAN, but the web
server has no reason to know the name of any node in the lan, so you
don't need DNS.

You appear to think that you can have a AD/Domain server in the DMZ and
still call it a DMZ - you can't.

The server in the DMZ should be a stand alone server, not part of your
LAN network or AD.

--

Leythos
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@rrohio.com (remove 999 for proper email address)

Re: How to create a manageable DMZ architecture?

On Nov 20, 4:38 am, Leythos wrote:
> In article > 579b081ce...@p69g2000hsa.googlegroups.com>, clintpa...@gmail.com says...
>
> > My problem is that there are services on my internal LAN, such as
> > Kerberos, NTP, DNS queries & xfers, etc, that I need my servers on my
> > DMZs to access. I am thinking of building 2 DMZs; one for my web
> > servers and the other for my DB servers. After doing a little DMZ
> > design research I found two threads that make me wonder:
>
> Is sounds like your web server is part of your windows active directory
> or domain structure in the lan - BAD MOVE.

All of my servers and firewalls are running OpenBSD. There are no
Windows machines on the entire network, only some FreeBSD and Macs.
All use Kerberos for sign-on.

> As for SQL - your application should be connecting over TCP 1433 using a
> user/password connection, not a Windows Authentication connection.

I'm using Postgresql, which uses Kerberos as the authentication
mechanism. I guess I could use username/password.

> NTP - no need to allow it to access the LAN, have it sync with the same
> public NTP server as your main NTP server.

True.

> DNS - again, you could open TCP 53 between the DMZ and LAN, but the web
> server has no reason to know the name of any node in the lan, so you
> don't need DNS.

You make a good point. I thought of that right after I hit send.

> You appear to think that you can have a AD/Domain server in the DMZ and
> still call it a DMZ - you can't.

I don't even know what this means. Are you saying that AD/Domain is
like Kerberos for Windows? If so, are you basically saying I should
not use Kerberos on my DMZ?

> The server in the DMZ should be a stand alone server, not part of your
> LAN network or AD.

Thanks Leythos, I'll make a note of that.

Re: How to create a manageable DMZ architecture?

The original points 1 and 2 are sound.

1)
The DMZ servers should not initiate any traffic. DNS and NTP are
excluded because they would normally only be asking the firewall for
these. If you are having trouble with something specific, let us know
and someone will come up with an alternative.

2)
A larger network would have a NOC with multihoned servers so they can
manage the DMZ servers remotely. The 2 networks would be seperate.
A smaller network would just manage DMZ servers at the console and not
allow remote management.
I have seen small networks that allow terminal services from the LAN
to the DMZ but I wouldn't recommend it and it would not meet several
security standards, but I don't know whos data you are trying to
protect.

Re: How to create a manageable DMZ architecture?

"A larger network would have a NOC with multihoned servers so they can
manage the DMZ servers remotely."

This can be a really, really bad idea. A decade ago people did this
regularly because they thought the separate networks equaled security. As
soon as attackers figured out how to root a DMZ server, they had console
access to both networks as well as the ability to reconfigure the attached
network cards (think about how changing the IP address or routing table
could bypass protections you set up).

Yes, DMZ servers should not initiate inbound connections to the LAN but
sometimes the risk is better than not doing it. For instance, I run Tripwire
on my DMZ servers, checking them every fifteen minutes. The Tripwire agent
does initiate an inbound connection to a particular IP address on specific
ports. The early warning feature of Tripwire more than offsets the risk of
this inbound connection.

If DMZ servers need to initiate inbound connections, do not expose those
servers directly to the Internet. Let Internet-exposed web server "A" write
to a database on DMZ-2 server "B". Let "B" write to the internal LAN.

Or better yet, have LAN database server "C" initiate a connection to DMZ-2
database server "B", replicate with it, and then delete all data in the
DMZ-2 server "B".

There are almost always ways around a problem. It just depends on whether
the cost of the protection is less than the cost of the risk. If you use the
reasonable figure of "$100 in direct and indirect costs for each customer
record exposed", it makes this calculation easy and somewhat frightening if
you decide not to do it right. :-)

JJ

wrote in message
news:91fbbb85-81ea-4729-af09-71ad23f7c714@e23g2000prf.google groups.com...
> The original points 1 and 2 are sound.
>
> 1)
> The DMZ servers should not initiate any traffic. DNS and NTP are
> excluded because they would normally only be asking the firewall for
> these. If you are having trouble with something specific, let us know
> and someone will come up with an alternative.

> 2)
> A larger network would have a NOC with multihoned servers so they can
> manage the DMZ servers remotely. The 2 networks would be seperate.
> A smaller network would just manage DMZ servers at the console and not
> allow remote management.
> I have seen small networks that allow terminal services from the LAN
> to the DMZ but I wouldn't recommend it and it would not meet several
> security standards, but I don't know whos data you are trying to
> protect.

Re: How to create a manageable DMZ architecture?

JJ wrote:
> Yes, DMZ servers should not initiate inbound connections to the LAN
> but sometimes the risk is better than not doing it. For instance, I
> run Tripwire on my DMZ servers, checking them every fifteen minutes.
> The Tripwire agent does initiate an inbound connection to a particular
> IP address on specific ports. The early warning feature of Tripwire
> more than offsets the risk of this inbound connection.

Nonsense. Although I've never used Tripwire I suppose the program is
able to write its results to a file. That file can be polled from the
LAN. No need for inbound connections at all.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich