RE: iSeries FTP security -- MIDRANGE-L

Hi Joe

I had hoped this wouldn't happen but, of course it did.

At 01:01 a.m. 19/05/2005, you wrote:

> From: Evan Harris
>
>
> I am fairly sure I understand how FTP works, although I will confess
to
> not being particularly aware of the ".." exploit.

These are somewhat contradictory statements.  If you don't know the
basics of the IFS (or any hierarchical file system), then you really
don't know much about how the FTP server or any of the other Unix-like
utilities works.  You may know how to use the FTP client, but you really
don't know that much about FTP.

The contradiction is that you equate not thinking through one point with not knowing the "basic's" or (in your other email) the entire utility.

These statements - and the others like these that you include in this email and elsewhere - are disappointing as they are of course intended to establish what (in your opinion) I know or don't know rather than address what I actually said and also to disparage my skills while establishing you as an expert (which you don't really need to do - your technical skills and knowledge are more than enough to do this)

That aside, I see your dilemma.  You have an NT guy who says he can make
data available simply and easily, and you have to compete with that.
However, the more I look at that argument, the more I have a problem.

Your primary argument boils down to this: if I don't do what the NT guy
says HE can do, then I will lose the iSeries.  That's really the crux of
the biscuit: you have to keep up with the NT guy or else your company
will abandon the iSeries.

No, this was part of one of my points about why it is required and why it was foolhardy to simply respond with an "I don't know how to do that" instead of implementing FTP or ODBC in response to an end user or management request. It was also responding to your blanket assertion that we shouldn't implement utilities we know nothing about.

You simply chose to ignore the other points and the context and jumped onto (one of) your favourite hobby horses.

If this were entirely true then you would have no control over security
and access to your data.  You simply have to do whatever the NT guy says
he can do.  This to me is frightening.  Since the SQL guy can also just
as easily update the data, do you have to allow update access as well?
If not, why not?  Probably because you can make a reasoned argument that
you need business rules to protect the integrity of the data.  But the
point is that you don't have to do everything the NT guy says.

I never said we did. I merely stated that this is one of the reasons we supply FTP and ODBC to people on request. It's real world enough that I think you would find most people would understand where I am coming from even if they didn't entirely like the way it ends up getting implemented. While most of us might share your ivory tower mind-set regarding the right way to set up security you would find that out there in the day-to-day trenches these are utilities the end users think THEY understand and demand.

So the real issue is not keeping up with the NT guy, it's providing fast
access to the data.  Why do you need fast FTP access to your data?  In
what situation does it make sense to download entire files to some other
machine?  How many rows are we talking about?  If it's not that many
rows, how long does it take to make a copy?  If it's a lot of rows,
wouldn't it be faster to download only a portion of the data?  And in
that case, you're no longer talking FTP.

Well you included ODBC in your response to me, so of course once that happened we weren't just talking about FTP

Really, I'm interested to know what purpose is served by FTP that can't
be handled with 15 minutes of programming, or how big a file it is that
copying it to a holding area actually takes too long for the end user.

*sigh* The transfer of data to suppliers that want access to a subset of product code matching data to validate their product code and their other product data.

Yes, this file would be in a separate area and yes each of the suppliers has a separate low level sign-on, but does this mean I should not think about an exit point for additional security to restrict what they can do via FTP ? And if I code my own exit point, shouldn't I understand the nuances of how the path is returned ? And further, if I discover something I've overlooked, shouldn't I be glad to learn that and take it into account to see whether it affects me ?

The point is not that you don't have a legitimate need for FTP, Evan.  I
don't know your shop.  I'm just pointing out that the majority of uses
I've seen of FTP are simply to save the IT guy some time, and it's done
at the expense of security.

And as I've always said, those who are willing to sacrifice security in
order to make their job a little easier deserve neither.

Joe

Joe this is all irrelevent to my original comment that I was happy to learn of a method of circumventing the FTP exit points depending on how they were coded.

Disregarding your red-rag response to my SQL Server and NT guy comments which you have exaggerated and distorted, the points I made were:

1. The issue was more about coding the exit not simply the use of FTP 2. I didn't expect to know absolutely everything about utilities I used, but expected to know enough and learn more as I went along 3. At least part of the reason for implementing exit points was poor vendor and programmer implementation of security which then has to be catered for 4. Is it reasonable to expect users to have more than one sign-on to assist in enforcing security (and will they accept this) ?

Your actually haven't addressed these and this discussion is pointless unless you do. I suspect it will be pointless anyway, but there you go.

I would be particularly interested in hearing how you would actually go about securing a machine that has had a major ERP application package installed where all the users have been granted *ALLOBJ rights and over a period of years many private authorites have also accumulated, and how you would do it after the event without disrupting the business while continuing to provide more access to the business;. This would be more relevent to the discussion than saying it shouldn't have happened.

Your last point is simply not worthy of this forum or you Joe. I don't know how you managed to get from my comment that I was happy to learn of a trick to circumvent exit point coding to implying that I had somehow sacrificed security to make my job easier. I agree somewhat with your statement regarding the use of FTP to make people's job easier but in my case I work for many shops (I am a consultant for a vendor) and more commonly I end up with the FTP process already established and trying to advise the customer to improve their security.

Regards
Evan Harris