RE: Rationale of the great DMZ

["Noonan, Wesley" <Wesley_Noonan () bmc com>]

> -----Original Message-----
> From: Paul Robertson [mailto:proberts () patriot net]
> Sent: Wednesday, July 10, 2002 12:40
> To: Scott, Richard
> Cc: firewall-wizards () nfr net
> Subject: Re: [fw-wiz] Rationale of the great DMZ
>
> On Wed, 10 Jul 2002, Scott, Richard wrote:
>
> > Readers,
> >
> > It comes obvious in many situations that these days the interpretation
> of a
> > DMZ and its implied security has changed.  Originally, DMZ's were the
> zoned
>
> While I'll agree that the level of security has changed, I'm not sure the
> original zoning concept has- let's not forget that what's allowed in and
> out of the internal network has changed as well.

I have been involved with numerous conversations with folks who no longer
see the value and need of DMZ's given the nature of the application
filtering proxies that exist today. I personally can't seem to get my hands
comfortably around that statement and environment, but apparently some
can... either way, it makes for an interesting perspective on the points
that Paul and Richard are bringing up.
 
> > area where systems were placed, that, if they were compromised, wouldn't
> > directly comprise the internal system.  The idea is that systems were
> placed
> > in the DMZ were that they should not contain sensitive access points in
> to
> > the internal network.  More so, data would be pushed to these systems in
> the
> > DMZ and data obtain via some proxied effort.  Network activity wouldn't
> > necessarily begin from the DMZ and be tunneled in to the internal
> network.
>
> More pointedly, it's that traffic coming from the outside be controlled
> and cordoned (for instance, SMTP traffic has almost always come from
> outside-- except in really paranoid places that UUCP out to get mail from
> a DMZ SMTP server.)

Like I mentioned, I know of numerous folks who are starting to contend that
(for example) with SMTP proxy capabilities, there is less and less of a
reason to offload SMTP inbound to a DMZ system then have it come into the
network from the DMZ since the firewall can filter clear up to layer 7
anyway... 

> > From what I have seen, the advent of SSL accelerators, hybrid firewalls
> and
> > data encryption technology the traditional DMZ is being depleted for a
> more
> > trusted zone environment.
>
> This seems to be true overall, where people take time to seperate by
> function, access control or sensativity.

Like mentioned, I am seeing it the other way as well - simplifying the
design to encompass an application proxy only as the line of delineation...

> > Some points I have noted:
> >
> > (1) Commonly SSL accelerators terminate the SSL end point prior to the
> > web services receiving the HTTP data.
>
> True, but typically on a DMZ, the exposure is the accelerator and the Web
> server- and it's not like the  Web server's exposure is lessened in any
> case.
>
> > (2) Firewalls are placed between servers and are more passive between
> > the DMZ and the internal network.
> > (3) Certain data like credit card data is encrypted, and since this is
> > perceived as being secure, more trusted and sensitive data is placed in
> the
> > DMZ. without thought to the very nature of how this data could be easily
> > decrypted, or captured prior to it being stored encrypted.
>
> This is unfortunately one of the bigger problems out there.  You'd think
> the lessons of Egghead, et al. would have shown people the errors of
> placing CC data on servers outside the perimeter.

Agreed. What really frightens me is the stance that "since the DMZ is an
'archaic' solution", that the "perimeter" is effectively the firewall doing
application filtering. A point that I have made is that a compromised host
on a DMZ only has network access (typically) to other hosts on the DMZ, as
opposed to a compromised host on the internal net having access everywhere
(and this doesn't even get into issues regarding sites that have no outbound
filtering rules...)
 
<snip>
> > (2) The implicit trust between applications and databases between the
> > DMZ and the internal network means, that once a compromise has occurred,
> > tunneling in to the corporate network becomes more easily penetrable.
>
> THis depends on the exposure allowed inside- typically only DB traffic at
> the sites I've looked at/been involved in designing.

True, and taking it further, I know of a number of sites that are extremely
restrictive of what passes between the two. Compromising the DMZ host does
not necessarily mean that "free and easy" access can now be gained to the
internal net.

<snip>
 
> > (5) Cyclical redundancies in network traffic, as VPN's are set up to
> > obtain data feeds but the feeds terminate on different hardware that is
> > insecure both at the network through to the application levels.
>
> Not sure I get this one...

I think he might be talking about terminating VPNs in such a manner that
concern is not paid to what traffic can go between VPNs, but only what
traffic may come into the internal net, thus one could jump from VPN1 to
VPN2 and potentially gain access to resources that they otherwise should not
be able to...


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards