Re: who ran the ADDTCPHTE comman -- MIDRANGE-L

It seems that the simplest solution to this specific problem would be
to turn on Object auditing (CHGOBJAUD) for the ADDTCPHTE command.
That would catch re-occurrences of this specific issue.

But most likely next time you have a problem, it will be something
else that was changed.  In which case Evan's advise (below) is right
on the money.  There is a lot to be said for always auditing powerful
profiles.

jte


----- Original Message -----
From: Evan Harris <spanner@ihug.co.nz>
To: <MIDRANGE-L@midrange.com>
Sent: Tuesday, June 05, 2001 1:22 PM
Subject: RE: who ran the ADDTCPHTE comman


>
> There is a third way (as I think has been mentioned before)
>
> Start Security Auditing
> Set up auditing for every user that has IOSYSCFG (or ALLOBJ, SECADM
ETC)
> Check the audit journal
> Periodically audit profiles with special authorities to check they
are audited.
>
> This is how I did it. As a bonus you also pick up all the commands
these
> people run not just the wrappered commands.
>
> Cheers
> Evan Harris
>
> >Okay, you need to identify command use.  You have two options:
> >
> >1. Restrict to one user
> >2. Log usage
> >
> >Those are the only options I can see.  Since restriction is not
viable,
> >logging is the only solution.  So, I would:
> >
> >A. Restrict use to a special profile
> >B. Write my own wrapper command that adopts that profile
> >C. Make my wrapper command log any use to a secure file
> >
> >This solves the problem, though at the expense of a wrapper.  At
the same
> >time it allows you to possibly minimize the exposure by perhaps
limiting the
> >actual operations allowed.  It could, for instance, do some
validation on
> >the parameters to avoid certain catastrophic conditions.  The
logging could
> >also notify someone who is in charge of auditing such changes.
> >
> >There's a price to pay in terms of development time, but if this is
a highly
> >sensitive systems area, you may want to pay the price.
> >
> >Joe
> >
> >
> > > -----Original Message-----
> > > From: owner-midrange-l@midrange.com
> > > [mailto:owner-midrange-l@midrange.com]On Behalf Of
D.BALE@handleman.com
> > > Sent: Tuesday, June 05, 2001 12:27 PM
> > > To: MIDRANGE-L@midrange.com
> > > Subject: RE: who ran the ADDTCPHTE comman
> > >
> > >
> > > Yes, you are correct, that *wasn't* what I meant. <g>
> > >
> > > It was intended to be a past tense question.  We have since
identified the
> > > culprit and we have cut off the pinky on his left hand.  This
was done in
> > > order to help him think twice before he attempts to run any ADD*
> > > commands in
> > > the future.
> > >
> > > We may need to consider the middle finger on his left hand as
> > > well to cover
> > > the DLT* & CHG* commands.  But we are hopeful that the first
> > > punishment was
> > > sufficient to preclude any future problems.
> > >
> > > Security?  Hmmmph.  We don't get many recurrences on security
> > > problems around
> > > here.
> > >
> > > <TFIC>
> > >
> > > Seriously though, Joe, you say to restrict it to a single user's
profile.
> > > What do you do when you need to allow more than one person to
use this
> > > command, and need to be able to determine who used it, as is
absolutely
> > > necessary in this case?
> > >
> > > Dan Bale
> > > IT - AS/400
> > > Handleman Company
> > > 248-362-4400  Ext. 4952
> > > D.Bale@Handleman.com
> > >   Quiquid latine dictum sit altum viditur.
> > >   (Whatever is said in Latin seems profound.)
> > >
> > > -------------------------- Original
Message --------------------------
> > > This probably isn't what you mean, but yes there is a way:
restrict the
> > > command's use to a single user profile.
> > >
> > > Joe
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-midrange-l@midrange.com
> > > > [mailto:owner-midrange-l@midrange.com]On Behalf Of
D.BALE@handleman.com
> > > > Sent: Tuesday, June 05, 2001 8:49 AM
> > > > To: MIDRANGE-L@midrange.com
> > > > Subject: who ran the ADDTCPHTE command?
> > > >
> > > >
> > > > Is there a way to determine the user profile used to
> > > create/modify/delete
> > > > TCP/IP interfaces, routes, host table entries, etc.
> > > >
> > > > Specifically, who ran the ADDTCPHTE command?
> > > +---
> > > | 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
> > > +---
> > >
> >
> >+---
> >| 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
> >+---
>
> +---
> | 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
> +---

+---
| 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
+---