Những bất lợi của việc vô hiệu hóa tinker hoảng loạn 0 trong NTP là gì?

Đôi khi chúng ta gặp vấn đề là các máy chủ mới có thời gian sai trong bios, do đó thời gian có thể bị tắt trong một tháng.

Khi bạn tạm dừng VM trong VMware và sau đó bỏ qua nó, thời gian cũng sẽ tắt. Vì NTP không đồng bộ hóa sau khi bù tối đa, tôi đang xem xét sử dụng tinker panic 0 trong /etc/ntp.conf.

Lý do nào có độ lệch tối đa mặc định là 1000 giây khiến NTP ngừng thời gian đồng bộ hóa? Chúng tôi đang sử dụng Puppet để thiết lập NTP, tôi đang xem xét để làm cho nó đặt tinker panic 0 trong ntp.conf, vì vậy NTP sẽ đồng bộ hóa bằng mọi cách. Những bất lợi của việc này là gì?

Nguyên nhân không đồng bộ hóa với máy chủ có thời gian quá khác nhau được ghi lại ở đây :

5.1.1.4. Điều gì xảy ra nếu Thời gian tham chiếu thay đổi?

Lý tưởng nhất là thời gian tham khảo là giống nhau ở mọi nơi trên thế giới. Sau khi được đồng bộ hóa, không nên có bất kỳ thay đổi bất ngờ nào giữa đồng hồ của hệ điều hành và đồng hồ tham chiếu. Do đó, NTP không có phương pháp đặc biệt để xử lý tình huống.

Thay vào đó, phản ứng của ntpd sẽ phụ thuộc vào độ lệch giữa đồng hồ cục bộ và thời gian tham chiếu. Đối với một offset nhỏ ntpd sẽ điều chỉnh đồng hồ cục bộ như bình thường; đối với các offset nhỏ và lớn hơn, ntpd sẽ từ chối thời gian tham chiếu trong một thời gian. Trong trường hợp sau, đồng hồ của hệ điều hành sẽ tiếp tục với các hiệu chỉnh cuối cùng có hiệu lực trong khi thời gian tham chiếu mới đang bị từ chối. Sau một thời gian, các độ lệch nhỏ (ít hơn đáng kể một giây) sẽ được xoay (điều chỉnh chậm), trong khi các độ lệch lớn hơn sẽ khiến đồng hồ bị bước (thiết lập lại). Sự bù đắp khổng lồ bị từ chối, và ntpd sẽ tự chấm dứt, tin rằng một điều gì đó rất kỳ lạ phải xảy ra.

Trong cấu hình NTP hiện tại của tôi, cũng được kiểm soát bởi puppet, tôi buộc đồng bộ hóa với máy chủ, cả trong ntp.conftệp, sử dụng tinker panicvà trong cài đặt daemon ( /etc/sysconfig/ntpd), như được mô tả trong ntpd(8)trang:

-g Thông thường, ntpd thoát với thông báo tới nhật ký hệ thống nếu phần bù vượt quá ngưỡng hoảng loạn, mặc định là 1000 giây. Tùy chọn này cho phép thời gian được đặt thành bất kỳ giá trị nào mà không hạn chế; tuy nhiên, điều này chỉ có thể xảy ra một lần. Nếu vượt quá ngưỡng sau đó, ntpd sẽ thoát với thông báo tới nhật ký hệ thống. Tùy chọn này có thể được sử dụng với các tùy chọn -q và -x.

Tôi làm điều này bởi vì tôi có thể tin tưởng máy chủ NTP mà tôi đang kết nối.

Phần có liên quan của mô-đun áp dụng cho khách hàng như sau:

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'],
  }

}

Và nội dung của các tệp được tham chiếu là:

$ 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"

và:

$ 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

Phần hieracòn thiếu ở đây, nhưng bạn có được ý tưởng.

Ví dụ trong trường hợp xấu nhất sẽ là các cuộc tấn công vào máy thu GPS đối diện với mạng LAN của bạn, điều này đã được chứng minh là có thể và đó là lý do tại sao NTP trong những trường hợp đó "bỏ đi" hơn là phá vỡ mọi thứ ngay lập tức. Đây là loại sự cố hoặc lỗi phần mềm đột ngột được mong đợi tại thời điểm thiết kế của NTP và cả hai đều có thể xảy ra.

Một cơ chế bảo vệ trong thuật toán là phát hiện cái mà họ gọi là falseticker , nhưng điều đó chỉ có thể phát hiện một số vấn đề, chủ yếu là nếu đồng hồ ngược dòng gửi một thời gian ngược một cách đột ngột.

Nếu đó chỉ là về "đồng hồ sai khi bắt đầu":

• bạn có thể sử dụng / etc / ntp / step-tickers (trên RHEL *, Debian không bao giờ có ý tưởng). Tệp đánh dấu bước cần một hoặc nhiều máy chủ NTP để chạy ntpdate trước khi bắt đầu ntpd.
• cách khác (hoặc ngoài ra) có tùy chọn -g cho ntpd , cho phép bù đắp xấu, nhưng chỉ khi chúng được tìm thấy khi bắt đầu.