RE: iSeries FTP security -- MIDRANGE-L

Hi Joe

Thanks for your comments - a few responses inline.

Here's an interesting take on it: you might want to understand how FTP
works before you open up your mission critical machines to it.
Seriously, the ".." exploit is known to just about every script kiddie
who ever set up an FTP server only to see somebody go rifling through
their files.  The problem is not that the iSeries is allowing access,
but that people are allowing FTP access to their iSeries without really
knowing how FTP works.

I am fairly sure I understand how FTP works, although I will confess to not being particularly aware of the ".." exploit. Of course, the issue is not about FTP specifically it is more about understanding what the path returned via the FTP exit API represents and coding to avoid the ".." exploit. Going by some of the other posts I am in good company.

Every time somebody posts something about how they "must" allow FTP
access, or "must" allow ODBC access to their data, I cringe because I'm
almost certain that they haven't gone out and investigated how these
utilities work.  There are similar exploits with ODBC too numerous to
mention, especially for people with authorized access to your machine.

If access via these methodologies is requested/demanded by the user community then it would be foolish to deny them out of hand just because I didn't know how they work. Especially when some NT guy is more than happy to claim he can provide the required service(s). The way I see it I can read the books available get some assistance where necessary, subscribe to forums like this and learn how to manage these utilities. Then I can run them on a machine I know I can secure.

The alternative would be to never learn anything and never do anything and watch the iSeries replaced at an even more rapid rate by Windows boxes that are not really up to the task of running an enterprise.

The right answer is to create separate, low-access user profiles with
access only to sandbox areas, and then to put data in those areas only
on demand.  Unfortunately, some of those same people who are opening
their machines to ODBC and FTP access will be the first to say this is
too much work.


I agree in principle but experience tells me:

1. People with an existing profile will balk at having a second user profile 2. People will balk at waiting for a copy to be made of data they know is already there and waiting

The real solution to this problem is to go back and fix the access to data properly, particularly on those systems where it has been bastardized by a vendor package with badly though out access methodologies and end user rights, especially packages or home grown apps that confer *ALLOBJ on all end users to make it easy to manage. If I had *PUBLIC *READ or *PUBLIC *EXCLUDE on all my data libraries this wouldn't be the problem it is, but the number of packages and homegrown applications that have started out requiring *ALLOBJ or something equally ill conceived means I simply have to try and secure around it.

Another answer is to get a security tool to help get around this or even to write an exit program if the funds to purchase are not forthcoming. But now we might be right back where we started.

Anyway, my .02 on this is that you need to know how the tools work,
warts and all, BEFORE you implement them.  The ".." technique is a good
one to guard against, and I guess if you have to learn it from the guy
in question, then that's better than nothing.  But you might want to
talk to a local twelve-year-old before you open your production data to
FTP access.

I am not particularly bothered who I learned it from, the point for me is that now I do know. I do know that I am never going to have the luxury of knowing every detail of every utility I am asked to implement, but I do know I will make every effort to find out what I need to know and keep on questioning what I do know in case things have changed or I have missed something. I'm old enough now to know that the only certainty is there is always something to learn. I'm not too proud to learn it wherever I can.

Joe

P.S. Among the many ways around this particular issue is to a create
special IFS folder with limited access and disable access to that
folder's parent folder, then create symbolic links to the data in
question.

How would this help with access to my inventory table, or would you propose that I keep a copy in CSV format, or even better that I make people wait while I generate only the data they want and then wait again while they extract the data from the safe area ?

Perhaps I should just go tell the NT guy to fire up his SQL Server and make copies of the iSeries data so it will be "accessible" to the end users instead of having to deal with the legacy iSeies.

Regards
Evan Harris