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: | Re: DMZ - Question |
|---|---|
| Date: | Sat, 27 Oct 2007 02:58:55 +0200 |
On 2007-10-26 hol64@hotmail.com wrote:
DMZ address range 192.168.x.x Internal LAN 10.x.x.x
Route between those networks, and do NAT only on the router bordering the Internet.
The web server needs to have access to a mainframe. How would you increase security if not with a DMZ?
I already mentioned three possible approaches. 1) Data replication: Replicate the data your webserver needs to access from the mainframe into the DMZ. That way the webserver has access to nothing but the data it needs to access. Disadvantages: replication of large amounts of data takes time, usually no live updates when data on the main- frame changes, updates from the webserver must be pulled. 2) Bastion host: A host that belongs physically to the DMZ, but logically to the LAN. It must be locked down and monitored closely. Laying out the web- server as a bastion host would allow it to be accessible from the outside, but still have access to hosts on the LAN. Downsides: bastion hosts are very critical, because when they're compromised, the attacker has immediately access to the LAN. Therefore they need very much attention (hardening, monitoring of logs, etc.). 3) Second DMZ: Create a second DMZ and put the mainframe into it. Allow access from the first DMZ and the LAN to the second DMZ, but not from any DMZ to the LAN. Dan Lynch elaborated on this quite a bit, so I'll just refer you to his mail for details. Which of the above is most appropriate in your case depends on the particulars of your scenario. For example: using PHP on the webserver would rule out the second option, the webserver updating the mainframe in realtime might rule out the first option, etc. Regards Ansgar Wiechers -- "All vulnerabilities deserve a public fear period prior to patches becoming available." --Jason Coombs on Bugtraq
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: PHP/MySQL image gallery penetration testing, Daniel Jana |
|---|---|
| Next by Date: | Re: RE: NAT external/Public IP, smarts_buy |
| Previous by Thread: | Re: Re: DMZ - Question, hol64 |
| Next by Thread: | Website\Tool listing version numbers of sec tools ?, kisho |
| Indexes: | [Date] [Thread] [Top] [All Lists] |