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]

Re: DMZ - Question

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>