|
While I like Mr. Silberberg's reference, it doesn't say in plain English the important thing about a DMZ: it requires TWO firewalls, however they are implemented. It does mention "any two policy-enforcing components of your architecture" but it took me a second to figure out that a policy-enforcing components is in effect a firewall. That is, you need a some sort of firewall between your DMZ and the Internet, and a SECOND firewall between the DMZ and your internal network. If, like many people, your access router is also your firewall, then you need a second firewall in order to implement a DMZ. That's how my layman's understanding of it works, anyway. In fact, here's my understanding of it - anybody chime in and correct my mistakes: A DMZ is a sort of go-between between two known entities. In the strictest sense of the word, a DMZ requires two firewalls - one between the DMZ and the outside world (outer firewall), and one between the DMZ and your internal network (inner firewall). The outer firewall is less restrictive than the inner one. You set up a DMZ to allow only certain trusted outside entities access to machines in the DMZ. The DMZ normally would not allow unrestricted Internet access, so it would be behind its own firewall (the outer firewall). So in that sense, it would be "inside" the outer firewall. On the other hand, the DMZ is further segregated from your internal network by your inner firewall. So in that sense, it is "outside" your inner firewall. In theory, only "good" people would be on machines in the DMZ, but even so they would still not be able to get into your private network. A typical situation is a company allowing its distributors access to a private web application. So, in theory, a DMZ is a pretty secure environment. Remember, though, that the DMZ is only as secure as the connection to the outside entity, because you have no control over the outside entity. If the outside entity is compromised and there is no firewall between them and your DMZ, then the DMZ is compromised. Code Red, for example, can easily propagate over an open connection between a trusted (but infected) outside entity and a DMZ - in fact, I may be wrong, but I'm pretty sure it could even propagate over a VPN connection, provided the correct ports were open, and since only port 80 is required, I suspect that many a VPN connection designed to allow HTTP access would indeed be vulnerable. That's a little beyond my area of expertise, though. Where it gets more confusing is that some people think that anything "outside" their inner firewall is the DMZ, even if it's completely unsecured. However, if you have no outer firewall, you don't really have a DMZ. I don't know if this is the case in the original post, but even if the poster has two firewalls, the caveats about the DMZ still apply: your DMZ is only as secure as the connections you allow to it. Joe > -----Original Message----- > From: midrange-l-admin@midrange.com > [mailto:midrange-l-admin@midrange.com]On Behalf Of srichter > Sent: Tuesday, August 14, 2001 9:44 PM > To: midrange-l@midrange.com > Subject: Re: IIS to as/400 odbc > > > Jeffery or anyone, > > DMZ - is that inside or outside the firewall? > > What is the degree of difficulty of spoofing the ip addr of the > accessing system? > > Thanks, > > Steve Richter
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.