What are the disadvantages of disabling tinker panic 0 in NTP?

Solution 1:

The cause for not syncing against a server whose time is so different is documented here:

5.1.1.4. What happens if the Reference Time changes?

Ideally the reference time is the same everywhere in the world. Once synchronized, there should not be any unexpected changes between the clock of the operating system and the reference clock. Therefore, NTP has no special methods to handle the situation.

Instead, ntpd's reaction will depend on the offset between the local clock and the reference time. For a tiny offset ntpd will adjust the local clock as usual; for small and larger offsets, ntpd will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened.

In my current NTP configuration, also controlled by puppet, I force the synchronization with the server, both in the ntp.conf file, using tinker panic, and in the daemon settings (/etc/sysconfig/ntpd), as described in the ntpd(8) manpage:

-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options.

I do this because I can trust the NTP server I'm connecting to.

The relevant portion of the module that applies to the clients is as follows:

class ntp (
  $foo
  $bar
  ...
  ){

  $my_files = {
    'ntp.conf'      => {
      path    => '/etc/ntp.conf',
      content => template("ntp/ntp.conf.$template.erb"),
      selrole => 'object_r',
      seltype => 'net_conf_t',
      require => Package['ntp'], },
    'ntp-sysconfig' => {
      path    => '/etc/sysconfig/ntpd',
      source  => 'puppet:///modules/ntp/ntp-sysconfig',
      require => Package['ntp'], },
      ...
  }

  $my_files_defaults = {
    ensure   => file,
    owner    => 'root',
    group    => 'root',
    mode     => '0644',
    selrange => 's0',
    selrole  => 'object_r',
    seltype  => 'etc_t',
    seluser  => 'system_u',
  }

  create_resources(file, $my_files, $my_files_defaults)

  exec { 'ntp initial clock set':
    command     => '/usr/sbin/ntpd -g -q -u ntp:ntp',
    refreshonly => true,
    timeout     => '-1',
    subscribe   => File['/etc/ntp.conf'],
  }

}

And the contents of the referenced files are:

$ cat devops/puppet/modules/ntp/files/ntp-sysconfig
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -a"

and:

$ cat devops/puppet/modules/ntp/templates/ntp.conf.RedHat.erb
# HEADER: This file was autogenerated by puppet.
# HEADER: While it can still be managed manually, it
# HEADER: is definitely not recommended.
tinker panic 0
<% server.each do |ntpserver| -%>
server <%= ntpserver %> autokey
<% end -%>
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
crypto pw hunter2
crypto randfile /dev/urandom
keysdir /etc/ntp

The hiera part is missing here, but you get the idea.

Solution 2:

The worst-case example would be attacks on your LAN-facing GPS receiver, this has been proven possible and is why NTP in those cases rather "leaves" than break anything immediately. This kind of problem, or sudden software bugs were expected at NTP's design time, and also both can happen.

One protection mechanism in the algorithm is the detection of what they call a falseticker, but that can only detect some problems, mostly if a upstream clock sends a backward time all of a sudden.

If it's only about "wrong clock at start time":

• you can use /etc/ntp/step-tickers (on RHEL*, Debian never got the idea). The step-tickers file takes one or more NTP servers to run an ntpdate against prior to starting ntpd itself.
• alternatively (or in addition) there's the -g option for ntpd, which allows ugly offsets, but only when they're found at start.