RE: IIS to as/400 odbc

["srichter " <srichter@xxxxxxxxxxxxxxxxxx>]

Jeffery and Joe,

Great answers!!

I dont like it, a little too cowardly for me, but it makes sense.

ps: I asked a "why do you need a firewall" question on the ignite list and the 
pro's over there made a good point:  a firewall protects your as400 from 
wasting cpu fighting a denial of service attack.

Thanks,

Steve Richter
 

---------- Original Message ----------------------------------
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
Reply-To: midrange-l@midrange.com
Date: Tue, 14 Aug 2001 22:50:00 -0500

>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
>
>