Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Basics
[Top] [All Lists]

DMZ host deployment and maintenance procedures

Subject: DMZ host deployment and maintenance procedures
Date: Wed, 9 May 2007 11:14:56 -0700
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

<Prev in Thread] Current Thread [Next in Thread>
  • DMZ host deployment and maintenance procedures, Dan Lynch <=