2:25 p.m.
Is there a hidden switch option to auditctl that would tell me the last
time auditd was restart specifically in epoch (down to the second)?
If my rules are changed to non-immutable ( -e 1 ) rebooted, and then
changed back to immutable ( -e 2 ), then I discover this weeks later, then
I will not know for sure which was most recently updated/restarted.
That is the reason for the question. I am doing this for a hardening
script that will tell me based on known recent changes (as of script
execution), but I cannot properly/successfully assess for dates outside of
a day or so. :-/
Any ideas would be appreciated,
--------------------------
Warron French
3:02 p.m.
Hello,
On Wednesday, August 4, 2021 3:25:40 PM EDT warron.french wrote:
Is there a hidden switch option to auditctl that would tell me the
last
time auditd was restart specifically in epoch (down to the second)?
Not auditctl, but maybe ausearch:
ausearch --start boot -m daemon_start -i
Or...
systemctl status auditd.service | grep Active
And if you need this in the epoch:
date --date="$(systemctl status auditd.service|grep Active|awk '{printf "%s
%s", $6, $7}')" +"%s"
If my rules are changed to non-immutable ( -e 1 ) rebooted, and then
changed back to immutable ( -e 2 ), then I discover this weeks later, then
I will not know for sure which was most recently updated/restarted.
That might be one issue with using ausearch...it might have scrolled away.
Maybe this could be collected at start and printed as part of the auditd
state report? I could see this being useful information for various reasons.
That is the reason for the question. I am doing this for a
hardening
script that will tell me based on known recent changes (as of script
execution), but I cannot properly/successfully assess for dates outside of
a day or so. :-/
systemctl should be able to get you the info you need. I might add this info
to the state report, though.
-Steve
8:03 a.m.
Thanks for the info.
While driving home I realized that I had not considered using systemctl and
assessing the "Active:" field like you suggested here.
Then before reading your email I tried my own way, doing:
date +%s -d "$(systemctl status auditd | egrep Active | egrep -o
"[[:digit:]]{4}-[[:digit:]]{2}--[[:digit:]]{2}\s*[[:digit:]]{2}:[[:digit:]]{2}:[[:digit:]]{2}")"
What is interesting is that I would expect both commands to render the same
result, but for some reason your command reports today's date and time,
whereas mine renders the valid date and time (from last week, which I know
to be true).
When I say your command, I mean this one:
date --date="$(systemctl status auditd.service|grep Active|awk '{printf
"%s %s", $6, $7}')" +"%s"
AH! I figured it out, I was missing the letter 'f' on printf.
--------------------------
Warron French
On Wed, Aug 4, 2021 at 4:03 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
On Wednesday, August 4, 2021 3:25:40 PM EDT warron.french wrote:
> Is there a hidden switch option to auditctl that would tell me the last
> time auditd was restart specifically in epoch (down to the second)?
Not auditctl, but maybe ausearch:
ausearch --start boot -m daemon_start -i
Or...
systemctl status auditd.service | grep Active
And if you need this in the epoch:
date --date="$(systemctl status auditd.service|grep Active|awk '{printf
"%s
%s", $6, $7}')" +"%s"
> If my rules are changed to non-immutable ( -e 1 ) rebooted, and then
> changed back to immutable ( -e 2 ), then I discover this weeks later,
then
> I will not know for sure which was most recently updated/restarted.
That might be one issue with using ausearch...it might have scrolled away.
Maybe this could be collected at start and printed as part of the auditd
state report? I could see this being useful information for various
reasons.
> That is the reason for the question. I am doing this for a hardening
> script that will tell me based on known recent changes (as of script
> execution), but I cannot properly/successfully assess for dates outside
of
> a day or so. :-/
systemctl should be able to get you the info you need. I might add this
info
to the state report, though.
-Steve
1234
days inactive
1235
days old
linux-audit@lists.linux-audit.osci.io
2 comments
2 participants
participants (2)
-
Steve Grubb -
warron.french