Re: DMZ - Question

["kevin fielder" <kevin.fielder () gmail com>]

> 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