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

| 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> |
|---|---|---|
| ||
| Previous by Date: | Vulnerability assessment certification, neo anderson |
|---|---|
| Next by Date: | RE: CISSP Question, Craig Wright |
| Previous by Thread: | Vulnerability assessment certification, neo anderson |
| Next by Thread: | What happens when you fudge your resume., Craig Wright |
| Indexes: | [Date] [Thread] [Top] [All Lists] |