Question regarding ntpd

John Jasen jjasen at gmail.com
Wed Sep 28 00:06:17 UTC 2016


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
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit




More information about the Linux-audit mailing list