Skip to contentSkip to conversation

ausearch checkpoint question

DISCUSSION LC Bruzenak 2 participants 3 messages Sep 29, 2016 – Oct 3, 2016

lore
Share & tools
lore
#0 lore raw

I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch "checkpoint" option a couple weeks ago. This was on a moderately busy system (judging by my own systems/experience) generating say 300-400MB of data/day.

I tried the checkpoint option in a 5-minute cron job, and I noticed that in comparison to the "-ts recent" option, it took far longer to complete. The "recent" option result was less than a second, whereas the checkpoint version took ~20 seconds every 5 minutes.

It's possible there were other factors at play; e.g. it was used on a mls-policy machine, and although I saw no AVCs, it's possible there were some access issues I didn't have time to investigate. On my intended application, I'll be on a standard targeted-policy machine so this won't be a potential factor.

I need to test this again, as I'm considering using the ausearch checkpoint capability for some new requirements, I was wondering if perhaps there were any timing results done or if there are any tips and tricks to getting the most out of it. Also - the man page section describing this is a little confusing to me so if anyone has a script segment that would be very helpful.

Thanks in advance,
LCB

Signature · 2 lines
LC Bruzenak
magitekltd.com
#1 lore raw

Lenny,

I typically use

TZ=UTC ausearch -i --input-logs \
--checkpoint <somepath>/auditd_checkpoint.txt

but I also set auditd.conf to have 9 x 32MB log files so the checkpoint code only scans the more recent files.

Quoted 26 lines · LC Bruzenak

I'm using the 2.4.5-3 audit rpm set and I tried using the ausearch "checkpoint" option a couple weeks ago.
This was on a moderately busy system (judging by my own systems/experience) generating say 300-400MB of data/day.

I tried the checkpoint option in a 5-minute cron job, and I noticed that in comparison to the "-ts recent" option, it took far longer to complete. The "recent" option result was less than a second, whereas the checkpoint version took ~20 seconds every 5 minutes.

It's possible there were other factors at play; e.g. it was used on a mls-policy machine, and although I saw no AVCs, it's possible there were some access issues I didn't have time to investigate.
On my intended application, I'll be on a standard targeted-policy machine so this won't be a potential factor.

I need to test this again, as I'm considering using the ausearch checkpoint capability for some new requirements, I was wondering if perhaps there were any timing results done or if there are any tips and tricks to getting the most out of it. Also - the man page section describing this is a little confusing to me so if anyone has a script segment that would be very helpful.

Thanks in advance,
LCB

#2 lore raw
Quoted 9 lines · Burn Alting

Lenny,

I typically use

TZ=UTC ausearch -i --input-logs \
--checkpoint <somepath>/auditd_checkpoint.txt

but I also set auditd.conf to have 9 x 32MB log files so the checkpoint code only scans the more recent files.

OK; thanks Burn. I store 20 x 100MB files; I need that many for my purposes. I'll be testing it again under controlled conditions; seems like what I need in one instance.

Signature · 2 lines
LC (Lenny) Bruzenak
[email protected]