Firewall Wizards mailing list archives
Re: Rationale of the great DMZ
From: Paul Robertson <proberts () patriot net>
Date: Wed, 10 Jul 2002 13:40:24 -0400 (EDT)
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.
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.)
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.
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.
Some of the issues: (1) If the SSL connection is terminated prior to the servers inside the DMZ, network sniffing is far easier to perform than application hacking to obtain sensitive data, traversing from the Internet in to the DMZ and fro the DMZ to the inside corporate network.
Typically, application compromise must be performed to get to the point of being able to sniff, so it games out pretty evenly.
(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.
(3) As a sites functionality becomes more tightly integrated to the business, the DMZ notion is weathered to form a perimeter security barrier and the DMZ part of the internal network.
This should be offset by tighter maintenance cycles and greater vigilance on DMZ servers.
(4) The lack of support for SSL on the servers within the DMZ mean s that more often or not, data is transmitted insecurely from the DMZ to other networks, be it, Internal or back out the DMZ.
Sniffing is normally the lowest order of problem unless you're transiting in the clear from a colocation facility.
(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...
Is anyone else seeing this trend, particularly as e-commerce strives to fulfill the management and marketing expectation of reporting functionality?
"Reporting functionality" is what brought us SNMP (I'm pretty sure billing off of it came later.) Just like real-time machine profiling several years ago, it adds complexity, load and potential vulnerabilities. The biggest problem though is that nobody wants to pay to do reporting right. I've always been of the opinion that stats should be gathered off the network by a machine that doesn't have transmit capability (either the cable doesn't have a TX wire, or the Ethernet driver for the listening NIC doesn't have that code.) Oddly enough- decrypting SSL early helps obtain a good listening post. I'm hoping that IDS systems grow up to fill that void easily. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts () patriot net which may have no basis whatsoever in fact." probertson () trusecure com Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Rationale of the great DMZ Scott, Richard (Jul 10)
- Re: Rationale of the great DMZ Paul Robertson (Jul 10)
- <Possible follow-ups>
- RE: Rationale of the great DMZ Noonan, Wesley (Jul 10)
- Re: Rationale of the great DMZ Steven M. Bellovin (Jul 13)
- Network "tap" (was Re: Rationale of the great DMZ) firewalls (Jul 18)