× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


---------- Original Message ----------------------------------
From: "Jeffrey Silberberg" <jsilberberg@mindspring.com>
Reply-To: midrange-l@midrange.com
Date: Tue, 14 Aug 2001 22:03:20 -0400

>Joe,
>
>        A bit paranoid here are we !  Since the system is in the DMZ and can
>be controlled with a specific map for the two systems in the firewall,  and
>an Exit program can be sure that the ODBC connection is from the target
>system with the restricted to USER profile, and that the commands being
>executed are only those allowed. Why develop a proprietary protocol.  Just
>define the risks and eliminate them....
>
>Jeffrey M. Silberberg
>Independent Consultant
>CompuDesigns, Inc.
>
>AS SOON AS I KNOW THE ANSWERS
>THEY CHANGE THE QUESTIONS
>
>----- Original Message -----
>From: Joe Pluta <joepluta@PlutaBrothers.com>
>To: <midrange-l@midrange.com>
>Sent: Tuesday, August 14, 2001 8:20 PM
>Subject: RE: IIS to as/400 odbc
>
>
>> Certainly there are a number of excellent ways to strengthen security with
>> OS/400, exit programs among them.  We're learning more about them as the
>> machine grows from the old green-screen only machines (where security was
>> simply a matter of not allowing users access to a command line) to a fully
>> active member of the networked community.
>>
>> On the other hand, there is no reason to design systems that weaken
>> security.  While you can indeed create an exit program, exit programs are
>> only as good as their designers.  A typical exit program simply checks to
>> make the user ID is on a list of valid users; this isn't going to be much
>> help against a brute force password attack, and that's exactly what an
>open
>> ODBC connection allows.  And the only excuse for using raw ODBC is that
>it's
>> a little easier to code than a more secure message based architecture -
>the
>> person that uses ODBC to finish a project isn't likely to want to spend
>the
>> time to create a nice set of exit progams to go with it.
>>
>> Personally, I think every access to a production machine should go through
>a
>> pipe of some kind, be it a TCP/IP socket with a proprietary messaging
>scheme
>> or even (gasp!) an APPC connection.  Very few hackers these days are up on
>> SNA communications; creating an APPC bridge from the DMZ to your
>production
>> machine is a very simple and effective second layer - much cheaper, in my
>> mind, than the amount of work required to create a set of sophisticated
>exit
>> programs.
>>
>> Then again, if you're in the business of selling exit programs, then my
>> opinion ain't worth much <grin>.
>>
>> Joe
>>
>> P.S. I don't sell TCP/IP messaging systems or SNA tunnels.  I just don't
>> like ODBC access to production data.
>>
>>
>> > -----Original Message-----
>> > From: midrange-l-admin@midrange.com
>> > [mailto:midrange-l-admin@midrange.com]On Behalf Of srichter
>> > Sent: Tuesday, August 14, 2001 6:52 PM
>> > To: midrange-l@midrange.com
>> > Subject: RE: IIS to as/400 odbc
>> >
>> >
>> > Joe Pluta said:
>> > >
>> > >There should be no "standard" access from the DMZ to protected
>machines.
>> > >There should always be some manner of proprietary protocol.
>> > Without that,
>> > >you've degraded your security to the point of simple password hacking.
>> >
>> > Joe,
>> > Are there exit pgms on the as400 that control odbc access to the system?
>> >
>> > I dont know much about internet access to systems, but dont exit
>> > pgms provide a good 2nd line of defense against hackers? Is not
>> > an as400, outside the firewall, still well protected by passwords
>> > and exit programs?
>> >
>> > 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
>>
>
>
>_______________________________________________
>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-Ups:

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.