RE: What authorities needed for FTP access? -- SECURITY400

You can control what users have authority to with an FTP exit pgm.  What
I've done is create an authorization list, then add FTP users to it.  Then,
the various FTP commands are restricted based on the authority the user has
in the authorization list.  If a user tried to CD or LCD to a directory I
don't allow for them, the exit pgm prevents it.

Phil

> -----Original Message-----
> From: security400-admin@midrange.com
> [mailto:security400-admin@midrange.com]On Behalf Of Jim Langston
> Sent: Wednesday, June 05, 2002 5:07 PM
> To: 'security400@midrange.com'
> Subject: RE: [Security400] What authorities needed for FTP access?
>
>
> Hi Evan,
>
> Comments Inline.
>
> -----Original Message-----
> From: Evan Harris [mailto:spanner@ihug.co.nz]
>
> Hi Jim
>
> >I need to allow a couple of customers FTP access to our AS/400, which we
> >will be opening a port through the firewall for.
> >
> >I have created an account, and had it use a group profile, FTPGROUP.  I
> then
> >GRTOBJAUT *ALL/QSYS *LIB with *EXCLUDE so this group has no access to any
> >library.
>
> This may not be a good idea from a performance perspective. It is best to
> try and have the lowest access level as *PUBLIC as there is an authority
> flag set to indicate that there are authorities with less than *PUBLIC.
> Every access is then checked to see if it is in the list before any other
> authority is checked.
>
> - I agree, and I think that public should have *EXCLUDE on all libraries,
> - Objects, etc... but this system was set up before I got here, and we
> - are running a package program.  It would take quite a bit of work to
> - get all the authorities straight, and it turns out that we may only
> - be using this package for a year or so more anyway.  I'll try my dardest
> - to have them let me set up the security on the next package so
> we actually
> - have some security.  But for this instance, it's really not an option at
> - this time.
>
> Given what you are doing however, I would be looking to get *PUBLIC set to
> exclude on all libraries if I could, and to also make it the default for
> new libraries. The new profiles could then be explicitly
> authorised to just
> the libraries they need. I don't know whether I would try and do this with
> a group profile - it seems to me that different customers should not be
> part of the same group unless they are the same customer with multiple
> accounts as this could allow one account to see another accounts data. I
> woudl prefer to make this impossible through authorities rather than
> segregation by library or directory.
>
> - The customers that will only be allowed FTP access will be a part of the
> - FTP group for simplicity in setting up the authorities.  For their own
> - libraries and such I am giving each customer explicit access to that
> - library.
>
> >I then tried to FTP log this user in to see what error would
> occur, and I'm
> >getting the error:
> >530 Not able to set library QGPL for user SHOESPOT; logon rejected.
>
> Is it possible to use the IFS and the user profile HOMEDIR parameter ? I
> haven't tried this myself but it might actually be easier; its
> worth a shot
> at least.
>
> - Not sure, haven't tried this yet.  I did find that I also had
> to give them
> - access to the QTCP library and then they could log in.  They still can't
> - create a file in their own directory with *ALL access however, and I'm
> - trying to determine where that problem lies.  The way I found out they
> - needed access to QTCP was to give them all access to all
> libraries again,
> - and then granting them *EXCLUDE to A* libraries, then B*
> libraries, etc..
> - until it failed.  I think I'm going to have to do the same thing to
> determine
> - what library they need for creating objects.  After I get the libraries
> down
> - I'll be fine tuning it to the specific objects.
>
> >which is to be expected.  I then removed the *EXCLUDE for the libraries
> QSYS
> >and QGPL, but when I try to log in I get the same error, although this
> group
> >should have the default *CHANGE authority to these libraries
> (hey, I didn't
> >set up the security in the first place, I'm not the one who gave everyone
> >*change authority to all libraries).
>
> You might find they just used the defaults.....
>
> - Yeah, I think so.  Lazy system setup.
>
> >So, what other libraries/objects/programs do I need to give this group
> >profile specific access to?  They will have their own library where they
> >will have full access.
>
> As to what else they need, I would have thought what you have done is
> enough. What is the  *PUBLIC authority to library QGPL ?
>
> - Answered above.
>
> I presume the account has limited LMTCPB(*YES). I would strongly recommend
> you either obtain or write an exit program to prevent - among other things
> - cd and ls commands. Your libraries right now all have *EXCLUDE set, but
> can you guarantee that any new libraries will have this ? Now and in the
> future ? Better that you set up something that requires something be
> specifically allowed rather than specifically prevented, if you get my
> drift.
>
> - Yes, LMTCPB(*YES) and signon program is SIGNOFF.  I plan on
> isolating them
> - eventually to the specific commands they need to FTP files to their
> library.
> - With access to nothing else.
>
> I would also recommend that you consider a unique profile for
> each customer
> with access to only its own directory, and that the directory be used as a
> staging area only (although it sounds like you are doing this) If you use
> the same library for all customers as a staging area then there is some
> potential for the GETing of data unless you disallow this by the use of an
> exit program as well. The FTP exits are in my opinion the easiest of the
> three I have had a stab at.
>
> - Doing that.
>
> I would strongly urge you not to allow execution of commands under any
> circumstances. Use the presence of a file to trigger an action if you must
> have things processed immediately upon upload. It is a small thing to
> request a second 1 byte file to be uploaded as a flag to indicate
> processing should take place in my opinion. The program that does the
> processing should get the data from the staging area as previously
> described rather than having data placed in the area it is going to be
> placed in.
>
> - I have written procedures in the past to check periodically for files
> - and if they are ready for processing without having to do the second
> - file flag.  A CL that keeps trying to allocate the object exclusively
> - to find out when the transfer is done works.
>
> Hope this assists somewhat
>
> - I also plan on writing an FTP exit program in addition to this security.
> - I'm extremely leery about letting outsiders into the computer.
>
> Regards,
>
> Jim Langston
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries
> (Security400) mailing list
> To post a message email: Security400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/security400
> or email: Security400-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/security400.
>
>