[EXT] Re: The format of password change audit events seems to have changed, Can you confirm the correct record type ?

[Wieprecht, Karen M.]

We do monitor the file itself,  but we would also like to verify that the root password is being changed within the required timeframe.   Monitoring the shadow file for changes is a start,   but that file could be changed for other unrelated reasons,  so we also want  to confirm which specific audit record(s) are now being generated when a local  account password  is changed.  

 I see several pam-related messages that were generated the last time the  root password was changed on  a RHEL 7.9 system,   but it's not clear if those event types could get generated for other reasons as well.   The only clue that those audit events probably represent a password change attempt is that the exe=/usr/bin/passwd

Thanks again,
Karen Wieprecht 


-----Original Message-----
From: linux-audit-bounces at redhat.com <linux-audit-bounces at redhat.com> On Behalf Of Richard Guy Briggs
Sent: Thursday, July 8, 2021 8:47 PM
To: warron.french <warron.french at gmail.com>
Cc: Linux-audit at redhat.com
Subject: [EXT] Re: The format of password change audit events seems to have changed, Can you confirm the correct record type ?

APL external email warning: Verify sender linux-audit-bounces at redhat.com before clicking links or attachments 

On 2021-07-08 18:53, warron.french wrote:
> This is an interesting topic.
> 
> Please, can you tell me what audit rule you are using that generates 
> such records about root's (*or any other account's) password change?*

This is a built-in to the userspace password management tools and not a kernel-triggered rule.

You could duplicate the effort by monitoring /etc/shadow for writes if you are really paranoid about those tools being subverted.

> Sincerely, thank you.
> --------------------------
> Warron French
> 
> On Thu, Jul 8, 2021 at 3:27 PM Steve Grubb <sgrubb at redhat.com> wrote:
> > On Thursday, July 8, 2021 2:19:54 PM EDT Wieprecht, Karen M. wrote:
> > > I've noticed that the messages I'm searching  for in splunk to 
> > > show root password changes no longer seem to be in the same 
> > > format.  Most of our systems run RHEL7 release 7.9,  and I believe 
> > > this is a recent change (I've only noticed this problem in the 
> > > past 3 months or so?), but we do have an older 7.5 system, so  I was able to use that to compare against
> > > the 7.5 to  identify what's changed.    I wanted to confirm which record
> > I
> > > should be using now since there are several that get generated now
> > >
> > > The key differences seem to be in the message generated and the 
> > > keyname being used for the account being targeted,  but I wanted 
> > > to confirm that there isn't some other record I should be looking 
> > > at to verify that the root password was changed in the required 
> > > timeframe since I see several records being generated from a 
> > > password change, none of which include anything as conclusive as the old message that showed the operation as a
> > > "password change".   Here are some fo the fields I'm looking at:
> > >
> > > type=USER_CHAUTHOK
> > > exe=/usr/bin/passwd
> > > [acct targeted for the passwd change]:
> > >             id=root          (old format)
> > >             acct=root      (latest format)
> > > msg
> > >            msg='op=change password  (old format)
> > >            msg='op=PAM:chauthok      (latest format)
> > >
> > > If you can  confirm whether this is the info I should be using now 
> > > to confirm password changes, that would be much appreciated.
> >
> > I don't have a RHEL 7.9 machine to compare against. I can set one up 
> > in about a week. On 7.6 the event looks like this:
> >
> > type=USER_CHAUTHTOK msg=audit(1625771196.574:162): pid=5113 uid=0
> > auid=1000
> > ses=1 subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
> > msg='op=change
> > password id=1000 exe="/usr/bin/passwd" hostname=rhel7.3 addr=?
> > terminal=pts/0
> > res=success'
> >
> > The problem is that "op= change passwd" has a space in it and will 
> > not parse right. I have been trying to correct instances of this so 
> > that things parse correctly. Not everyone runs their changes by me 
> > for comment. So, its possible that the change was made to fix the 
> > space, but usually I suggest people add an underscore.
> >
> > I'll into it more next week.
> >
> > -Steve

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit at redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit