Re: FTP Exit pgms

Jamie,

Jamie Pratt wrote:

> We have all our normal users using a group profile, which apparently
> was set up like this long ago, as I understand it. It was (still is) a
> menu-driven security type of setup, built long before the days of
> TCP/IP on the 400, so not much care was taken in designing
> application/file security, and as a result, this group profile has
> full authority to all the data that (*change on objs, *all on dta??
> -- not sure exactly, "AS/400 object/file security" is not really my
> bag, but TCP/IP is, so that is why I have been asked to do this)
> resides in files in all our prod libs.

I here about these kinds of (vendor inflicted) problems a lot.  PowerTech
Toolworks has an AS/400 security package that was specifically designed to solve
this type of security problem.  You can learn more about it at
http://www.toolnet.com


> ---- Not good at all in the FTP
> world, I know, I know, and have let them know of this (huge!) security
> hole many times before.  (Worse, this system does not have any
> auditing on (as far as I can tell, anyways... like I said, security
> really isnt my bag!), so probably noone would even know who trashed
> these files if it were to happen via FTP by one of these group
> members!!)

Whatever solution you end up with, you'll certainly want to turn on Security
Auditing.  It is easy, free, and has few or no noticable performance
implications, so there is really no reason not to do it.   When you create a
journal called QAUDJRN in library QSYS, OS/400 will log many significant 
security
events for you for free.  All you have to do is create reports, and clean up the
receivers from time to time.  The Security Toolkit has a new command called
CHGSECAUD that will walk you through the setup.  It's a great way to find out
what is happening on your system.


> I really need to somehow restrict certain FTP subcommands on certain
> libs, as well as restrict access to certain libs altogether for all
> members of this group profile.    As I see it now, you can only
> retrieve the *USRPRF within the exit pgm..... (actually it's an input
> parm, but you know what I mean!..)  .... I would hate to have to code
> hundreds of usrprfs in there, just to restrict certain access to all
> members of this group!!

We have solved this problem in the PowerLock product by allowing the
administrator to restrict FTP functions by User or Group profile, or by incoming
IP address.  What's more, we also secure all of the Client Access servers (which
are just as big an exposure, but maybe slightly less well known).  It's all 
table
driven so you don't have to make program changes every time someone joins or
leaves your company.  If you're serious about closing this gap, take a look at
what our product can do.  It may save you a ton of time.

jte

--
John Earl   johnearl@toolnet.com

PowerTech Toolworks  206-575-0711
PowerLock Network Security www.toolnet.com
The 400 School   www.400school.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---