* Auditing Logons/Logoffs
@ 2017-07-14 19:51 warron.french
2017-07-14 20:46 ` Steve Grubb
0 siblings, 1 reply; 3+ messages in thread
From: warron.french @ 2017-07-14 19:51 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 739 bytes --]
Back to this again, as I thought my coworker had addressed it months ago,
but he did not as I cannot find anything.
*THE_SUBJECT*: Auditing Logons and Logoffs (success/failures)
I am aware of the following files:
/var/log/faillog, and
/var/log/lastlog
The following link is relevant to RHEL5 (maybe 6 and 7??):
https://www.stigviewer.com/stig/oracle_linux_5/2015-12-07/finding/V-818
Is there an appropriate syscall for handling *THE_SUBJECT*?
Do I use the syntax as advised in the link provided at stigviewer.com?
We are dealing with systems that do tie into IPA, but have to ensure
*THE_SUBJECT* is being addressed and forwarded.
I have to support both RHEL6 and RHEL7.
Thanks in advance,
--------------------------
Warron French
[-- Attachment #1.2: Type: text/html, Size: 1374 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Auditing Logons/Logoffs
2017-07-14 19:51 Auditing Logons/Logoffs warron.french
@ 2017-07-14 20:46 ` Steve Grubb
[not found] ` <CAJdJdQmJb44ZwCWYxR9Cry9XddsqwR5_F5cbLyjTeDF7iVs0mQ@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Steve Grubb @ 2017-07-14 20:46 UTC (permalink / raw)
To: linux-audit
On Friday, July 14, 2017 3:51:16 PM EDT warron.french wrote:
> Back to this again, as I thought my coworker had addressed it months ago,
> but he did not as I cannot find anything.
>
> *THE_SUBJECT*: Auditing Logons and Logoffs (success/failures)
>
> I am aware of the following files:
> /var/log/faillog, and
> /var/log/lastlog
>
> The following link is relevant to RHEL5 (maybe 6 and 7??):
> https://www.stigviewer.com/stig/oracle_linux_5/2015-12-07/finding/V-818
>
> Is there an appropriate syscall for handling *THE_SUBJECT*?
Nope. This is hardwired into the applications. There is a specification here:
https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Login-Lifecycle-Events
That explains each event that is part of the login and logout and its meaning.
> Do I use the syntax as advised in the link provided at stigviewer.com?
Nope. Its hardwired. As long as audit is enabled, you'll get them.
-Steve
> We are dealing with systems that do tie into IPA, but have to ensure
> *THE_SUBJECT* is being addressed and forwarded.
>
> I have to support both RHEL6 and RHEL7.
>
>
> Thanks in advance,
> --------------------------
> Warron French
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Auditing Logons/Logoffs
[not found] ` <CAJdJdQmJb44ZwCWYxR9Cry9XddsqwR5_F5cbLyjTeDF7iVs0mQ@mail.gmail.com>
@ 2017-07-17 15:26 ` Steve Grubb
0 siblings, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2017-07-17 15:26 UTC (permalink / raw)
To: warron.french; +Cc: linux-audit
On Friday, July 14, 2017 5:18:13 PM EDT warron.french wrote:
> OK, so no rules to be found specifically/explicitly in audit.rules (for
> RHEL6 nor RHEL7) because it is hardwired/embedded in the code of auditd
> already?
Not auditd. In whatever observes the event. Pam observes the login for sshd
and it creates/sends the event.
> Looks like if I run an aureport and see the summary it might imply what is
> tracked by default and then I can deduce beyond that reasonably that:
It would be a fraction of what is hardwired since its based on system
activity. If you never run newgrp, then you will never see that event.
> 1. I either have a rule for something in audit.rules that is being
> summarized by aureport, and
> 2. can then attempt an ausearch of some appropriate context against the
> "test" that I need to validate.
>
> For example, User account modification, creation, deletion, suspensions and
> lockings might be covered as summarized by aureport under the category
> of - *Number of changes to accounts, groups, or roles:*
Locking would be under the anomaly category. Please see the explanation in
"User Login Lifecycle Events"
> Is that an appropriate assessment?
>
> If not, what do I need to do to address AUDIT(B) and AUDIT(C) tests?
They are generated automatically. You don't need to do anything for them.
> Thank you again, in advance. If you have something definitive I will read
> it, I just don't know how to look for these concepts apparently.
I already pointed you to the reading material. The specifications are written
to explain when certain hardwired event should be sent and what they mean.
Hardwired events mostly come from user space and never have a syscall record
attached. They also never have a key field.
-Steve
> On Fri, Jul 14, 2017 at 4:46 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Friday, July 14, 2017 3:51:16 PM EDT warron.french wrote:
> > > Back to this again, as I thought my coworker had addressed it months
> > > ago,
> > > but he did not as I cannot find anything.
> > >
> > > *THE_SUBJECT*: Auditing Logons and Logoffs (success/failures)
> > >
> > > I am aware of the following files:
> > > /var/log/faillog, and
> > > /var/log/lastlog
> > >
> > > The following link is relevant to RHEL5 (maybe 6 and 7??):
> > > https://www.stigviewer.com/stig/oracle_linux_5/2015-12-07/finding/V-818
> > >
> > > Is there an appropriate syscall for handling *THE_SUBJECT*?
> >
> > Nope. This is hardwired into the applications. There is a specification
> > here:
> >
> > https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Login-> > Lifecycle-Events
> >
> > That explains each event that is part of the login and logout and its
> > meaning.
> >
> > > Do I use the syntax as advised in the link provided at stigviewer.com?
> >
> > Nope. Its hardwired. As long as audit is enabled, you'll get them.
> >
> > -Steve
> >
> > > We are dealing with systems that do tie into IPA, but have to ensure
> > > *THE_SUBJECT* is being addressed and forwarded.
> > >
> > > I have to support both RHEL6 and RHEL7.
> > >
> > >
> > > Thanks in advance,
> > > --------------------------
> > > Warron French
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-07-17 15:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-14 19:51 Auditing Logons/Logoffs warron.french
2017-07-14 20:46 ` Steve Grubb
[not found] ` <CAJdJdQmJb44ZwCWYxR9Cry9XddsqwR5_F5cbLyjTeDF7iVs0mQ@mail.gmail.com>
2017-07-17 15:26 ` Steve Grubb
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.