DMZ host deployment and maintenance procedures

Greetings list,

Recent scrutiny has led us to a closer examination of our procedures
relating to deployment and maintenance of DMZ servers. Very few of our
DMZ hosts are static web-content servers. Some run specialized database
apps, some are managed by vendors, some serve web content but include
some layer of application logic running on them.

DMZ hosts exist in one of two screened subnets behind firewalls: one
public access network contains advertised web and email services;
another "private" access network contains specialized hosts with access
limited by the firewall to a few specific internet IP addresses
(generally vendors). A few of these are domain member servers. Though we
recommend strongly against this, it is argued that domain membership
greatly eases day-to-day administration. Our private enterprise network
of end-user workstations and internal use servers is behind another
firewall interface.

Our recommended procedure entails the full configuration of a DMZ host
while connected to a protected network. Once in production trim, the
host is evaluated by the security team, and change recommendations are
made. After final config, a ghost image is taken of the box and stored
in escrow. The host is then connected into its DMZ network. A log of
config changes is kept for minor changes made in day-to-day operation.
If a major update is required, the system is taken off-line, the stored
ghost image applied, all logged changes are applied, and finally the
major update is applied. After testing, a new ghost image is taken and
stored. The host is then reconnected into its production DMZ network,
and the process repeats.

This is of course what is recommended, but not necessarily how things
are done. As you can tell, it's a lot of work. Deadlines, expedience,
worry about functionality, and plain laziness all tend to work against
the recommended procedures.

My questions for the group:

- Is this amount of effort common?
- How is this level of care justified against the interests of project
managers and sys admins?
- What compromises are appropriate under what specific circumstances?

Thanks for any thoughts you contribute.

Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA

Relevant Pages

  • Re: Troubleshoot samba?
    ... Does your local network use DHCP and was recently re- ... or is the host itself even pingable from the other hosts? ... clients, new types of servers, and new vagaries added to the protocol ... a networking issue for the Samba server. ...
  • Re: registered domain name
    ... IIS servers. ... because of DNS heirachy structure name resolution and local dns ... You should never host a public website on your LAN - you could ... network, that is also a bad idea, in that you would need two DNS servers ...
  • RE: VMware ESX
    ... Because the VMware instances ... are not aware of each other inside the host, ... plugging each isolated VMhost network ... we've got a VMware ESX group of servers running on the inside of our ...
  • slow lookup to non-existent host
    ... When doing a nslookup of a non-existent host on the same network as the bind servers, ...
  • Re: 2 pc network - cant see host files from pc 2 on pc 1
    ... If the second card is lost on HOST PC then DSL Internet does not connect. ... Ditch the second network card in the one ...