Re: who ran the ADDTCPHTE comman

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