8:04 a.m.
Hi there,
I started playing with the audit subsystem a few days ago, and noticed
that even without any rules, there is a lot of logging going on. I
understand that rules have to be fine tuned, and I was expecting
having to do that, but I wasn't expecting the amount of logs on a busy
system with no rules at all.
I read in an old presentation (~2011) that these come from "trusted
apps", and in fact any process with cap_audit_write (iirc) can log
such events. The tip was that exclude/never list/action could be used
to reduce this noise, is that still the case and recommended approach?
Or is there a way to use audit with only the rules defined in
/etc/audit/rules.d?
8:34 a.m.
On Thursday, November 19, 2020 9:04:24 AM EST Andreas Hasenack wrote:
I read in an old presentation (~2011) that these come from
"trusted
apps",
There are only 10 - 15 apps that are "trusted apps". They are logging events
that are required by various security standards such as common criteria, DISA
STIG, PCI DSS, etc.
and in fact any process with cap_audit_write (iirc) can log
such events.
While that may be true, it is generally not the case that they do in fact
log.
The tip was that exclude/never list/action could be used to reduce
this
noise, is that still the case and recommended approach?
If you must, sure. Trusted app events are in the 1100-1199 range. But which
app is causing the problems that you see? In the past, we had to silence
crond because it was noisy.
Or is there a way to use audit with only the rules defined in
/etc/audit/
rules.d?
The rules in that dir are insufficient to fulfill regulatory requirements. If
you are doing some kind of syscall experiment, then I can see that you might
want to turn them off. But if your aim is meeting some kind of standard, then
other events are required.
-Steve
8:59 a.m.
Hi,
On Thu, Nov 19, 2020 at 11:34 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Thursday, November 19, 2020 9:04:24 AM EST Andreas Hasenack wrote:
> I read in an old presentation (~2011) that these come from "trusted
> apps",
There are only 10 - 15 apps that are "trusted apps". They are logging events
that are required by various security standards such as common criteria, DISA
STIG, PCI DSS, etc.
> and in fact any process with cap_audit_write (iirc) can log
> such events.
While that may be true, it is generally not the case that they do in fact
log.
> The tip was that exclude/never list/action could be used to reduce this
> noise, is that still the case and recommended approach?
If you must, sure. Trusted app events are in the 1100-1199 range. But which
app is causing the problems that you see? In the past, we had to silence
crond because it was noisy.
cron is one, for sure. Everytime it fires, it's a sequence of
USER_ACCT, CRED_ACQ, LOGIN, USER_START, CRED_DISP, USER_END. And it
doesn't really log useful information either, like the job it ran. The
syslog entry is more useful for that. In this example, I had a
/bin/true root crontab:
----
type=USER_ACCT msg=audit(11/19/20 14:44:01.418:368) : pid=32715
uid=root auid=unset ses=unset msg='op=PAM:accounting acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=CRED_ACQ msg=audit(11/19/20 14:44:01.418:369) : pid=32715
uid=root auid=unset ses=unset msg='op=PAM:setcred acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=LOGIN msg=audit(11/19/20 14:44:01.418:370) : pid=32715 uid=root
old-auid=unset auid=root tty=(none) old-ses=4294967295 ses=6 res=yes
----
type=USER_START msg=audit(11/19/20 14:44:01.418:371) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:session_open acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=CRED_DISP msg=audit(11/19/20 14:44:01.422:372) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:setcred acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=USER_END msg=audit(11/19/20 14:44:01.422:373) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:session_close acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
Another one is k8s apparently reapplying the iptables rules
frequently, so I get SYSCALL for setsockopt() with IPT_SO_SET_REPLACE
and NETFILTER_CFG entries. These perhaps I could turn off based on who
is emitting them via "exe=/foo/bar" and/or userid, as I can see this
happening very frequently as containers come and go.
> Or is there a way to use audit with only the rules defined in /etc/audit/
> rules.d?
The rules in that dir are insufficient to fulfill regulatory requirements. If
you are doing some kind of syscall experiment, then I can see that you might
want to turn them off. But if your aim is meeting some kind of standard, then
other events are required.
No standard or regulatory requirement required, I was just looking at
another layer of security to watch for specific events for which I
would create rules.
1442
days inactive
1442
days old
linux-audit@lists.linux-audit.osci.io
2 comments
2 participants
participants (2)
-
Andreas Hasenack -
Steve Grubb