Ok, this is bring clarity to the confusion. I appreciate you taking the time to provide a
thoughtful and detailed reply.
Dan
On Sep 27, 2016, at 6:16 PM, Steve Grubb <sgrubb(a)redhat.com>
wrote:
On Tuesday, September 27, 2016 10:05:31 PM EDT Sullivan, Daniel [CRI] wrote:
> type=SYSCALL msg=audit(1475012495.972:5327): arch=c000003e syscall=159
> success=yes exit=0 a0=7ffd7498eb00 a1=861 a2=0 a3=1 items=0 ppid=1 pid=5357
> auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38
> fsgid=38 tty=(none) ses=4294967295 comm="ntpd"
exe="/usr/sbin/ntpd"
> key="time-changeā
>
> This is generating large amounts of log data.
Yep.
> I am not an expert in auditd log analysis. Is this expected behavior?
Unfortunately for that syscall yes. Your best option is to not audit that
syscall.
> I am unsure of what the key time-change value of this log data is, and am
> wondering if this indicates some sort of misconfiguration or problem with
> ntpd.
Keys are used for reporting. You can run
aureport --start today --key --summary
to get an idea of what kinds of events you are getting. You can also use keys
with ausearch to extract events that trigger on a specific rule and then feed
that to aureport.
> From looking at the output of tcpdump it does not look like I am polling
> every second, so I am wondering why this activity is occurring. If anybody
> could advise on how to decipher these log entries I would appreciate it.
> Thank you for your help and advisement.
Well, using the -i option to ausearch gives more meaning:
type=SYSCALL msg=audit(09/27/2016 17:41:35.972:5327) : arch=x86_64
syscall=adjtimex success=yes exit=0 a0=0x7ffd7498eb00 a1=0x861 a2=0x0 a3=0x1
items=0 ppid=1 pid=5357 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp
egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd
key=time-change
But the syscall uses a single data struct and we have no visibility into that
so we cannot tell any more what its doing.
The whole point of monitoring the time settings is that someone could tamper
with logs or cause something to appear like it occurred at a different time
than it really did. So, the idea is to collect this info "in case". But ntpd
overwhelms logs but chronyd might be marginally better. See bz
https://bugzilla.redhat.com/show_bug.cgi?id=918127
for some discussion.
-Steve
********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.
Thank you
University of Chicago Medicine and Biological Sciences
********************************************************************************