Joe,

The only thing to keep in mind is that a NAT server can act as the
"policy-enforcing component" between the DMZ and the inside world. In our
particular case many of our employees are out of the office. We've put our
"intranet" in the DMZ. It has a publicly addressable IP address but is
behind the firewall, only port 80 access is allowed. My personal machine is
behind a NAT server however (IP 10.100.10.6) so there is no way for you to
get here from there (but I can get there from here). In our case the NAT
server acts as the second "policy-enforcing component" in our network.

-Walden

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Tuesday, August 14, 2001 11:50 PM
To: midrange-l@midrange.com
Subject: RE: IIS to as/400 odbc


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

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.