Good afternoon,
I have RHEL 7 systems set up to emit audit records when the firewall rules with
iptables change. I do it with a single audit command:
-a always,exit -F arch=b64 -S setsockopt -F a2=0x40 -F key=IPTablesChange
And it works great. I get audit logs like this:
type=PROCTITLE msg=aud
Good afternoon,
I have TTY auditing set up on a number of hosts using pam_tty_audit for the
root account. I have this line in a PAM file to enable it:
session required pam_tty_audit.so disable=* enable=root
In looking at the reports from aureport and ausearch, the number of TTY events
is alw
Hello All,
I was at the BSides Portland security conference last weekend and I gave a
presentation called “The Linux Audit Framework” there. I have put up the slides
from the presentation on slideshare. I have also put up a file that implements
the Center for Internet Security RHEL 6 Benchmark
Hello Burn,
Have you considered iwatch (no, not the Apple wrist gadget). It monitors
files and can alert on a large set file conditions. Check out this man
page at: http://manpages.ubuntu.com/manpages/utopic/man1/iwatch.1.html
Best regards,
Gary Smith
On 7/20/15 4:56 AM, Burn Alting wrote:
> Al
Hi Steve,
Any chance that your presentation would get recorded for later viewing
by those of us who have no budget for travel at the end of the fiscal year?
Best regards,
Gary Smith
On 07/15/2015 03:22 PM, Steve Grubb wrote:
> Hello,
>
> I normally don't put the word out about speeches I give,
Hi,
What's the "best way to do it" is dependent on your system.
That said, I can offer two non-audit suggestions.
One I call the "Old Shell Game". Stick this bash code in in the appropriate
system wide bash file:
function log
{
typeset x
x=$(history 1 | cut -f 5-)
logger -p daemon.notice -
Hi Chad,
How are you looking at the syscall events? This is one case where grep is
not your friend. Try using ausearch instead. Here's a syscall that failed
and the log record was extracted with ausearch -a 1689093 where 1689093 is
the audit id:
type=SYSCALL msg=audit(1367438345.734:1689093): arc
Hi Jure,
Presuming you've captured the audit records you're interested in a file named
snorf, you could do something like this:
cat snorf | awk -F\= '{print $8 "0A"}' | xxd -r -p
In the example you had in the email, arg4 turns out to be:
strbegins(thread_id,"thread_id=2369892f")
Best regards
Hi all,
I've seen a several systems crash with what appears to a page fault on
audit_prune_tree. The systems are 2.6.18-164.11.1.el5 and audit-1.7.17-3.el5.
I've seen crashes with traces like this:
crash> bt
PID: 16570 TASK: 810108f447a0 CPU: 6 COMMAND: "audit_prune_tre"
#0 [81012e
he excessive memory glomming I've
seen.
Best regards,
Gary Smith
-Original Message-
From: Steve Grubb [mailto:sgr...@redhat.com]
Sent: Thursday, February 05, 2009 8:33 AM
To: linux-audit@redhat.com
Cc: Lucas C. Villa Real; Smith, Gary R
Subject: Re: Problem with auditd/SnareLinux on
Hello All,
I have some systems that have just been updated to from RHEL 5.2 to RHEL
5.3. The version of auditd is 1.7.7 and SnareLinux is 1.5.0.
Some time after the update ran, I noticed that the amount of free memory
on the systems had dramatically gone down. Running top, I saw that
auditd had s
11 matches
Mail list logo
