Reading this, my first thought was ntpd trying to adjust time drift on the client.
On 09/27/2016 07:16 PM, Steve Grubb 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 > > -- > Linux-audit mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
