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



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.