Hi, Starting my way into firewall consulting on a regular basis. I am often encountering situations where other consultants or internal people have recommended a DMZ model and I find this in conflict with my advice. The reasons for doing or not doing a DMZ are logical, but often I find DMZ is considered "standard" and I am forced to consider the reasons. Especially smaller companies where duplicate servers just for public interfaces are expensive in support, licensing, and equipment terms. First off, a couple of disclaimers: -- I do a lot of work with Microsoft products. This isn't religion, this is customer's preference. I approach Microsoft products based on my experience and reality in working with them, I don't always follow the Microsoft vision .. unless I see it in the product and it appears to be initiated by their developers (and not their marketing department). I do respect good developer vision, regardless of the brand slapped on the box. -- I do not wish to hear Microsoft bashing about security issues. I am well versed in the realities of it. It is my job to make it work, and their bugs are my opportunities. -- I am not talking about all cases, I am talking about the case where a company has their OWN internet connection. Obviously I advise my customers about the advantages of co-locating, multiple links to the Internet, etc. -- but often we are talking core corporate systems like email. That out of the way? <grin>. ================================================ == My $0.10 view of WHY DMZ was a good thing === ================================================ History is a good place to start. To me, a DMZ made perfectly logical sense when they were devised in the early days of Internet. They made sense for what most were doing: 1) Co-location sites didn't exist yet, or weren't readily available, so it was common to put public sites on the same connection as corporate one. Hence the need to split the "outside only" from the "inside feeds". 2) Many companies started out with only a public web site and email. This meant one or two servers on the Internet, nothing more. They did NOT connect their user workstations to the Internet (indirectly or directly). I have worked with large companies as recent as 1998 who did NOT give their everyday office workers Internet access (heck, some still aren't using TCP/IP I presume). 3) Intranet did not exist much in the very early days, it was pretty much outsiders connecting to your "published information" - your own people had the same data in other (legacy) formats. 4) VPN technology, where an employee using cable modem or DSL at home would come in over public Internet, was likely not even a dream. Dial-up was JUST becoming an option, heck - most employees didn't have home computers in the early days. ======================================================= == Situations where I find DMZ often no longer fits == ======================================================= In my consulting practice, I have found at least a few examples of where a DMZ does not fit: 1) Intranet server that requires user authentication and is used both by "inside" and "remote" users. Often these are tied into standard corporate userid/password database. In practical sense, in a Windows NT environment, this may mean that the server has to be a domain controller (or be near one) to have transparent and integrated authentication. 2) Extranet - especially when the mix is equal among outside and inside users. 3) Email systems where the data storage is centralized (on the server). For example, a IMAP4 server of even Microsoft Exchange Server using Outlook 2000. They support a user having multiple clients (laptop, desktop, palm pilot, web interface) that merely touch a centralized database. The mail isn't stored on a user workstation; true client/server email. So the user actually needs to be able to connect into a corporate system, not just your traditional SMTP input/output box. Think of Hotmail for a minute, clients must connect to their mail server... The basic problem is that the system is equally an "inside only system" as it is a "access from the Internet" system. Putting it on a DMZ makes little or no sense, as the system isn't just Public content ---to--- Public users, but Private content ---to--- Public (authenticated) users. Companies like Microsoft are only moving further and further in this direction, allowing integration of all services on fewer and fewer systems (aka, Mainframe). In this model, security and so forth is integrated, making "stand alone DMZ" security model pretty obsolete for anything bout the "wide open public web site." ========================================= == Servers on Public IP's === ========================================= I am frequently encountering situations where it just seems to make sense to encourage the customer to rethink the role of the Internet. Especially in terms of replacing dial-up access for access to public resources. In this design, I often come up with recommendations: -- Put client workstations on separate subnets / VLAN / etc from the servers. Treat ALL clients as undesired until known. -- Put PUBLIC IP addresses on the servers. -- Put firewall between servers and everything. Multiple paths if that makes rule logic easier and lowers risk of mistakes. In this model, you trust that the firewall is the only gatekeeper. "Private IP's" aren't the way to hide your servers. This also greatly simplifies integrated things like DNS (which Windows 2000 Directory does not favor mixed private/public for servers). The bottom line is that you have to trust your firewall and consider it an integral part of your environment. =========================================== == Final words == =========================================== Obviously a DMZ has a place, as do co-location sites and other separation of systems. However, I'm trying to deal with the "integrated corporate world". Also the cases where the customer desires to share information with their employees, not hide it away and protect it at all costs. Are there books / articles / names to go along with these "public IP on corporate server" models? I realize that this issue is not all that new, just my focus on articulating it to my customers. Thank you. Stephen Gutknecht Renton, Washington - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
Am I wrong to think of DMZ as Old Fashioned? In the Microsoft corporate customer world?
Stephen Gutknecht \(firewalls\) Mon, 22 Jan 2001 13:27:42 -0800
