RE: IIS to as/400 odbc

Joe,

While I agree with your assessment of A, B and C I think you are making a
flaw in what a command is. It looks as if you are assuming that a command is
"select * from file..." or "update file set..." or "delete from file..."

What if the commands allowed from the web server are limited to "call ..."
These stored procedures can return result sets satisfying the need for
select and can obviously update and delete rows. Whenever I add a new table
I need a new set of stored procedures (in RPG, Cobol, C, whatever) that
allows me access to them and I don't need to change the list of things in my
exit point. 

The other advantage to this is that the user (web server) is isolated from
data layout changes on the AS/400. If I want to split a table, or change
something so when a record in inserted into one table an audit record is
inserted into another all I have to do it change the stored procedure. There
is ZERO impact on the web server.

-Walden


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


No, not paranoid.  If the target machine has an exit program, that's good.
I didn't get from the original poster that one was in place.  In fact, I
sincerely doubt that even a simple majority of machines using ODBC have exit
programs in place.

But let's say you do have an exit program with IP filtering AND user profile
protection AND command filtering.  I guarantee that a VERY small minority of
shops implement this level of protection, but let's say you do.  Just how
secure is that?

A. If the machine in the DMZ is compromised, IP filtering is compromised.

B. Once that is done, it is only a matter of brute force password hacking to
get past the user profile protection.

C. You're left with only command filtering.

But in order to implement command filtering, you remove the flexibility of
SQL access that is the primary motivation for using ODBC.  Every time a new
file or a new command is required, you have to write that into the exit
program.

At this point, I would take the time to write a true server.  Because once
you've gotten to the point of command filtering, a server provides superior
protection (because it can also address database integrity issues and
user-defined security at a more granular level) while at the same time
insulating between the client program from database changes.  A server is
far more flexible than an ODBC approach, which relies on the table and
column layout of your database.  The only downside to a server is
programming, but you're doing the same level of programming in your exit
program anyway, so why not apply it to a server?

Of course, architectural issues like this are beyond the scope of the
security question that I originally raised, and you are correct that a
sophisticated exit program can indeed provide a reasonable level of security
for ODBC.  My point is not that you can't secure ODBC, but instead that by
the time you program all that sophistication, you'd be better off expending
that effort writing a true server layer and moving to a more powerful
object-oriented database design.

Joe


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Jeffrey Silberberg
> Sent: Tuesday, August 14, 2001 9:03 PM
> To: midrange-l@midrange.com
> Subject: Re: IIS to as/400 odbc
>
>
> 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.

_______________________________________________
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