The use of multiple DMZ's is pretty standard practice for improving
security. Many times you will go as far as to have a web facing DMZ
that hosts web servers, mail relays etc, then an application DMZ that
hosts the actual intellegence behind the web sites.
This allow the application some protection from attack as the relatively
dumb web facing server will provide input sanitisation etc prior to
passing the data to the application in a standardized format.
The application then talks to the DB and other backend systems (e.g. crm
systems, connections to credit checking agencies etc). Depending on your
security requirements these systems will likely be on their own VLAN at
least or possibly their own DMZ.
Many businesses that require reasonable security mandate a three tired
architecture to prevent any web facing servers connecting into the
network.
Where the backend servers are not required to be in a DMZ this is the
scenario where you may see connections out of a DMZ to specific hosts on
the internal (trusted LAN).
Just my tuppence worth.
Cheers
Kevin
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Ansgar -59cobalt- Wiechers
Sent: 29 October 2007 15:53
To: security-basics@securityfocus.com
Subject: Re: DMZ - Question
On 2007-10-26 Daniel Anderson wrote:
On the DMZ we will have a Web Server that needs access back to the
Mainframe on the LAN, and a Mail server that need access to another
mail server on the LAN.
Bad idea. You don't want hosts in the DMZ to be able to establish
connections into the LAN. That would be breaking the concept of a DMZ
(allow connections from a network with higher security level to a
network with lower security level, but not vice versa).
There are several ways to deal with this problem, e.g. replicate the
information from the servers into the DMZ, use bastion hosts, or put
the servers from the LAN into a second DMZ.
Don't take general rules too far.
You don't want connections from the outside connecting directly to
systems on the inside at all.
Specific systems in the DMZ accessing specific systems/services on the
LAN is normal and acceptable.
The genral rule is: do not allow connections from a network with lower
security level to a network with higher security level. And I'd strongly
recommend against disregarding this rule unless you have some very good
reasons to do so.
Trying too hard to stick to this general rule usually results in worse
systems (replication impacting integrity, additional complexity
impacting availability, etc).
True. However, I don't think this applies to either of the three options
I mentioned above. Not necessarily at least.
These DMZ systems should be minimized and hardened so in effect they
are the bastion host.
Setting up bastion hosts is one of the approaches I mentioned above.
However, depending on which software the server should run, it may not
be possible to make it a bastion host. For example I'd never allow a
webserver running PHP as a bastion host ("Hardened PHP", my ass).
In some environments you would want additional segmentation on the
LAN, but it's probably not realistic or a good idea to move your
mainframe into a DMZ.
Why not? The second DMZ is not directly accessible from the Internet, so
for the mainframe there's no difference to the scenario where the
mainframe is located in the LAN. Only that in the 2-DMZ scenario an
attacker wouldn't have access to the LAN even if he manages to
compromise the (publicly accessible) server in the first DMZ.
Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
