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?

Reply to
pachl
Loading thread data ...

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.

Reply to
Leythos

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.

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

True.

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

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?

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

Reply to
pachl

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.

Reply to
rounner

"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

Reply to
JJ

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
Reply to
Ansgar -59cobalt- Wiechers

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.