Centos 7 синхронизация времени chrony

Время на прочтение

Большинство людей следят за временем. Мы встаём вовремя, чтобы выполнить наши утренние ритуалы и отправиться на работу, сделать перерыв на обед, уложиться в сроки проекта, отметить дни рождения и праздники, сесть на самолёт и так далее.

Более того: некоторые из нас одержимы временем. Мои часы питаются от солнечной энергии и получают точное время из Национального института стандартов и технологий (NIST) в Форт-Коллинз (штат Колорадо) через длинноволновую радиостанцию WWVB. Сигналы времени синхронизируются с атомными часами, также расположенными в форте Коллинз. Мой Fitbit синхронизируется с моим телефоном, который синхронизируется с сервером NTP, который в конечном итоге синхронизируется с атомными часами.

Содержание

Устройства тоже следят за временем
Время одно — часов много
Что там у NTP?
Различные реализации NTP
Отключение служб NTP
Проверка статуса перед запуском
Установка часового пояса
Systemd-timesyncd
Конфигурирование systemd-timesyncd
Запуск timesync
Установка аппаратных часов
Зачем вам вообще RTC?
Заключение
На правах рекламы
Как синхронизация времени стала безопасной
Сломать NTP за 25 минут
NTS — новый Autokey
Первый этап — NTS KE
Второй этап — NTP под защитой NTS
NTPSec
Chrony
Пример настройки Chrony на RHEL / CentOS на VPS
Как синхронизация времени стала безопасной
Сломать NTP за 25 минут
NTS — новый Autokey
Первый этап — NTS KE
Второй этап — NTP под защитой NTS
NTPSec
Chrony
Пример настройки Chrony на RHEL / CentOS на VPS
Настройка службы синхронизации времени chronyd в CentOS Linux 7

Устройства тоже следят за временем

Есть много причин, по которым нашим устройствам и компьютерам нужно точное время. Например, в банковской сфере, на фондовых рынках и других финансовых предприятиях транзакции должны выполняться в надлежащем порядке, и для этого критически важны точные временные последовательности.

Наши телефоны, планшеты, автомобили, системы GPS и компьютеры требуют точной настройки времени и даты. Я хочу, чтобы часы на рабочем столе моего компьютера показывали правильное время. Я хочу, чтобы в моём локальном календаре напоминания появлялись в нужное время. Правильное время также гарантирует, что задания cron и systemd запускались в нужное время.

Дата и время также важны для ведения журнала, поэтому немного проще найти те или иные логи, ориентируясь по дате и времени. Например, однажды я работал в DevOps (в то время его так не называли) и занимался настройкой системы электронной почты в штате Северная Каролина. Раньше мы обрабатывали более 20 миллионов писем в день. Отслеживание электронной почты через серию серверов или определение точной последовательности событий с использованием файлов журналов на географически разнесенных хостах может быть намного проще, если соответствующие компьютеры синхронизированы по времени.

Время одно — часов много

Хосты Linux должны учитывать, что существует системное время и время RTC. RTC (Real Time Clock — часы реального времени) является немного странным и не особо точным названием для аппаратных часов.

Аппаратные часы работают непрерывно, даже когда компьютер выключен, используя аккумулятор на материнской плате системы. Основная функция RTC — хранить время, когда соединение с сервером времени недоступно. В те времена, когда нельзя было подключиться к серверу времени через интернет каждый компьютер должен был иметь точные внутренние часы. Операционные системы должны были обращаться к RTC во время загрузки, и пользователь должен был вручную установить системное время, используя аппаратный интерфейс конфигурации BIOS, чтобы убедиться, что оно правильное.

Аппаратные часы не понимают концепцию часовых поясов; в RTC хранится только время, а не часовой пояс или смещение от UTC (Всемирное координированное время, которое также известно как GMT или среднее время по Гринвичу). Вы можете установить RTC с помощью инструмента, о котором я расскажу позже в этой статье.

Системное время — это время, которое ОС отображает на часах GUI на вашем рабочем столе, в выходных данных команды date, в метках времени журналов. Это также относится ко времени создания, изменения и открытия файлов.

На странице man для rtc есть полное описание RTC и системных часов.

Что там у NTP?

Компьютеры во всем мире используют NTP (сетевой протокол времени) для синхронизации своего времени со стандартными эталонными часами через интернет с помощью иерархии серверов NTP. Основные серверы времени находятся на уровне 1, и они напрямую подключены к различным национальным службам времени на уровне 0 через спутник, радио или даже модемы по телефонным линиям. Службы времени на уровне 0 могут быть атомными часами, радиоприёмником, который настроен на сигналы, передаваемые атомными часами, или приёмником GPS, использующим высокоточные сигналы часов, передаваемые спутниками GPS.

На подавляющем большинстве эталонных серверов открыто несколько тысяч общедоступных серверов NTP stratum 2, которые доступны для всех. Многие организации и пользователи (включая меня) с большим количеством хостов, которым требуется NTP-сервер, предпочитают устанавливать свои собственные серверы времени, поэтому только один локальный хост обращается к stratum 2 или 3. Затем они настраивают оставшиеся узлы в сети для использования локального сервера времени. В случае моей домашней сети это сервер уровня 3.

Различные реализации NTP

Первоначальная реализация NTP — это ntpd. Затем к ней присоединились две более новых, chronyd и systemd-timesyncd. Все три синхронизируют время локального хоста с сервером времени NTP. Служба systemd-timesyncd не так надёжна, как chronyd, но этого достаточно для большинства целей. Если RTC не синхронизирован, она может постепенно корректировать системное время, чтобы синхронизироваться с NTP-сервером, когда локальное системное время немного смещается. Служба systemd-timesync не может использоваться в качестве сервера времени.

Chrony — это реализация NTP, содержащая две программы: демон chronyd и интерфейс командной строки под названием chronyc. У Chrony есть некоторые функции, которые во многих случаях просто незаменимы:

Chrony может синхронизироваться с сервером времени намного быстрее, чем старый сервис ntpd. Это хорошо для ноутбуков или настольных компьютеров, которые не работают постоянно.
Он может компенсировать колебания тактовых частот, например, когда хост переключается в спящий режим или входит в спящий режим, или когда тактовая частота изменяется из-за скачкообразного изменения частоты, которое замедляет тактовые частоты при низких нагрузках.
Он решает проблемы со временем, связанные с нестабильным сетевым соединением или перегрузкой сети.
Он регулирует задержки в сети.
После начальной временной синхронизации Chrony никогда не останавливает часы. Это обеспечивает стабильные и согласованные временные интервалы для многих системных служб и приложений.
Chrony может работать даже без подключения к сети. В этом случае локальный хост или сервер можно обновить вручную.
Chrony может выступать в качестве NTP-сервера.

Ещё раз: NTP — это протокол, который может быть реализован на хосте Linux с использованием Chrony или systemd-timesyncd.

RPM-пакеты NTP, Chrony и systemd-timesyncd доступны в стандартных репозиториях Fedora. RPM systemd-udev — это менеджер событий ядра, который в Fedora установлен по умолчанию, но не является обязательным для использования.

Вы можете установить все три и переключаться между ними, но это создаст лишнюю головную боль. Так что лучше не стоит. Современные релизы Fedora, CentOS и RHEL перешли на Chrony как стандартную реализацию, и кроме того, у них есть systemd-timesyncd. Я считаю, что Chrony работает хорошо, обеспечивает лучший интерфейс, чем служба NTP, предоставляет гораздо больше информации и повышает контроль, что безусловно понравится системным администраторам.

Отключение служб NTP

Возможно, на вашем хосте уже запущена служба NTP. Если это так, вам нужно отключить её перед переключением на что-то другое. У меня был запущен chronyd, поэтому я использовал следующие команды, чтобы остановить и отключить его. Запустите соответствующие команды для любого демона NTP, который вы используете на своем хосте:

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Проверьте, что служба остановлена и отключена:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Проверка статуса перед запуском

Статус системной синхронизации часов позволяет определить, запущена ли служба NTP. Поскольку вы ещё не запустили NTP, команда timesync-status намекнёт на это:

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Прямой запрос статуса даёт важную информацию. Например, команда timedatectl без аргумента или параметров выполняет подкоманду status по умолчанию:

[root@testvm1 ~]# timedatectl status
           Local time: Fri 2020-05-15 08:43:10 EDT  
           Universal time: Fri 2020-05-15 12:43:10 UTC  
                 RTC time: Fri 2020-05-15 08:43:08      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: no                          
              NTP service: inactive                    
          RTC in local TZ: yes                    

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Так вы получите местное время для вашего хоста, время UTC и время RTC. В данном случае системное время установлено на часовой пояс America / New_York (TZ), RTC установлено на время в местном часовом поясе, а служба NTP не активна. Время RTC начало немного отклоняться от системного времени. Это нормально для систем, часы которых не были синхронизированы. Величина смещения на хосте зависит от времени, прошедшего с момента последней синхронизации системы.

Мы также получили предупреждение об использовании местного времени для RTC — это относится к изменениям часового пояса и настройкам летнего времени. Если компьютер выключен в тот момент, когда необходимо внести изменения, время RTC не изменится. Но для серверов или других хостов, которые работают круглосуточно, это вообще не проблема. Кроме того, любая служба, которая обеспечивает синхронизацию времени NTP, будет корректировать время хоста ещё на начальном этапе запуска, поэтому после завершения запуска время вновь станет правильным.

Установка часового пояса

Главное — знать официальное название часового пояса для вашего местоположения и соответствующую команду. Скажем, вы хотите изменить часовой пояс на Лос-Анджелес:


[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
America/La_Paz                  Europe/Budapest
America/Lima                    Europe/Chisinau
America/Los_Angeles             Europe/Copenhagen
America/Maceio                  Europe/Dublin
America/Managua                 Europe/Gibraltar
America/Manaus                  Europe/Helsinki
<SNIP>

Теперь вы можете установить часовой пояс. Я использовал команду date для проверки изменений, но вы также можете использовать timedatectl:

[root@testvm2 ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#

Теперь вновь можете изменить часовой пояс своего хоста на местное время.

Systemd-timesyncd

Демон systemd timesync предоставляет реализацию NTP, которой легко управлять в контексте systemd. Он устанавливается по умолчанию в Fedora и Ubuntu. Однако запускается он по умолчанию только в Ubuntu. Я не уверен насчёт других дистрибутивов. Вы можете проверить у себя сами:

[root@testvm1 ~]# systemctl status systemd-timesyncd

Конфигурирование systemd-timesyncd

Файл конфигурации для systemd-timesyncd — это /etc/systemd/timesyncd.conf. Это простой файл с меньшим количеством включенных опций, чем в старых сервисах NTP и chronyd. Вот содержимое этого файла (без дополнительных изменений) на моей виртуальной машине с Fedora:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

NTP=myntpserver

Запуск timesync

Запустить и сделать systemd-timesyncd активным можно так:

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#

Установка аппаратных часов

Вот как выглядит ситуация после запуска timesyncd:

[root@testvm2 systemd]# timedatectl
               Local time: Sat 2020-05-16 14:34:54 EDT  
           Universal time: Sat 2020-05-16 18:34:54 UTC  
                 RTC time: Sat 2020-05-16 14:34:53      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: no

Изначально разница между RTC и местным временем (EDT) не превышает секунды, и расхождение возрастает ещё на пару секунд в течение следующих нескольких дней. Поскольку в RTC нет понятия часовых поясов, команда timedatectl должна выполнить сравнение, чтобы определить нужный часовой пояс. Если время RTC точно не соответствует местному времени, то значит, оно не соответствует и местному часовому поясу.

В поисках дополнительной информации я проверил состояние systemd-timesync и обнаружил вот что:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limit: 10365)
     Memory: 2.8M
        CPU: 476ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Обратите внимание на сообщение журнала, в котором говорится, что системное время не установлено или сброшено назад. Служба Timesync устанавливает системное время на основе временной метки. Метки времени поддерживаются демоном timesync и создаются при каждой успешной синхронизации.

Команда timedatectl не имеет возможности взять значение аппаратных часов из системных часов. Она может установить время и дату только из значения, введённого в командной строке. Вы можете установить RTC на то же значение, что и системное время, используя команду hwclock:

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Local time: Mon 2020-05-18 13:56:46 EDT  
           Universal time: Mon 2020-05-18 17:56:46 UTC  
                 RTC time: Mon 2020-05-18 13:56:46      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: yes

Опция —localtime говорит о том, что аппаратные часы показывают местное время, а не UTC.

Зачем вам вообще RTC?

Любая реализация NTP установит системные часы во время запуска. И зачем тогда RTC? Это не совсем так: это произойдет только в случае, если у вас есть сетевое соединение с сервером времени. Однако многие системы не имеют постоянного доступа к сетевому соединению, поэтому аппаратные часы полезны для того, чтобы Linux мог на их основе установить системное время. Это лучше, чем установка времени вручную, даже если оно может отклоняться от реального времени.

Заключение

В этой статье рассмотрены некоторые инструменты для управления датой, временем и часовыми поясами. Инструмент systemd-timesyncd предоставляет NTP-клиента, который может синхронизировать время на локальном хосте с NTP-сервером. Однако systemd-timesyncd не предоставляет серверную службу, поэтому, если вам нужен NTP-сервер в вашей сети, вы должны использовать что-то ещё — например, Chrony, для работы в качестве сервера.

Я предпочитаю иметь единственную реализацию для любой служб в моей сети, поэтому использую Chrony. Если вам не нужен локальный NTP-сервер или если вы не против использовать Chrony в качестве сервера и systemd-timesyncd в качестве SNTP-клиента. Ведь нет необходимости использовать дополнительные возможности Chrony как клиента, если вас устраивает функционал systemd-timesyncd.

Еще одно замечание: вы не обязаны использовать инструменты systemd для реализации NTP. Вы можете использовать старую версию ntpd, Chrony или другую реализацию NTP. Ведь systemd состоит из большого количества сервисов; многие из них являются необязательными, поэтому их можно отключить и использовать вместо них что-то ещё. Это не огромный монолитный монстр. Можно не любить systemd или его части, но вы должны принять обоснованное решение.

Мне нравится реализация NTP в systemd, но я предпочитаю Chrony, потому что он лучше отвечает моим потребностям. Это Linux, детка -)

На правах рекламы

VDSina предлагает серверы под любые задачи, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата. Напомним, у нас есть вечные серверы, которые точно неподвластны времени 😉

Как синхронизация времени стала безопасной

Views

Как сделать так, чтобы время per se не врало, если у вас есть миллион больших и малых устройств, взаимодействующих по TCP/IP? Ведь на каждом из них есть часы, а время должно быть верным на всех. Эту проблему без ntp невозможно обойти.

Представим себе на одну минуту, что в одном сегменте промышленной ИТ инфраструктуры возникли трудности с синхронизацией сервисов по времени. Немедленно начинает сбоить кластерный стек Enterprise ПО, распадаются домены, мастера и Standby узлы безуспешно стремятся восстановить status quo.

Возможна также ситуация, когда злоумышленник намеренно старается сбить время через MiTM, или DDOS атаку. В такой ситуации может произойти все что угодно:

истечет срок действия паролей учетных записей пользователей;
истечет срок действия X.509 сертификатов;
двухфакторная аутентификация TOTP перестанет работать;
бэкапы «устареют» и система удалит их;
сломается DNSSec.

Понятно, что каждый первый департамент ИТ заинтересован в надежной работе служб синхронизации времени, и хорошо бы они были надежны и безопасны в промышленной эксплуатации.

Сломать NTP за 25 минут

Сетевые протоколы — милленниалы имеют одну особенность, они давно устарели и никуда уже не годятся, но заменить их не так-то легко даже тогда, когда набирается критическая масса энтузиастов и финансирования.

Основная претензия к классическому NTP в отсутствии надежных механизмов защиты от атак злоумышленников. Предпринимались разнообразные попытки решить эту проблему. Для этого сначала внедрили механизм заранее установленных ключей (PSK) для обмена симметричными ключами.

К сожалению этот способ себя не оправдал в виду простой причины — он плохо масштабируется. Нужна ручная настройка на стороне клиента в зависимости от сервера. Это значит, что вот так вот просто нельзя добавить еще одного клиента. Если на сервере NTP что-то меняется, надо перенастраивать все клиенты.

Тогда придумали AutoKey, но сразу же в нем обнаружили ряд серьезных уязвимостей в самом дизайне алгоритма и от него пришлось отказаться. Все дело в том, что начальное число (seed) содержит всего лишь 32-бита, оно слишком мало и не содержит достаточно вычислительной сложности для лобовой атаки.

Key ID — симметричный 32-битный ключ;
MAC (message authentication code) — контрольная сумма NTP пакета;

Autokey рассчитывается следующим образом.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Где H() — криптографическая хэш функция.

Для расчета контрольной суммы пакеты используется та же функция.

MAC=H(Autokey||NTP packet)

Так получается, что вся целостность проверок пакетов держится на аутентичности кукис. Завладев ими, можно восстановить autokey и затем подделать MAC. Однако сервер NTP при их генерации использует начальное число (seed). Именно тут кроется подвох.

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

Функция MSB_32 отрезает от результата вычисления md5 хэша 32 старших бита. Клиентский куки не меняется до тех пор, пока параметры сервера неизменны. Дальше злоумышленнику остается лишь восстановить начальное число и получить возможность самостоятельно генерить куки.

Для начала следует подключиться к серверу NTP в качестве клиента и получить куки. После этого методом перебора злоумышленник восстанавливает начальное число следуя простому алгоритму.

Алгоритм атаки на вычисление начального числа методом перебора.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

IP адреса известны, так что остается лишь создать 2^32 хэша до тех пор пока созданный куки не совпадет с тем, что получен от NTP сервера. На обычной домашней станции с Intel Core i5 на это уйдет 25 мин.

NTS — новый Autokey

Мириться с такими дырами в безопасности Autokey было невозможно и в 2012 г. появилась новая версия протокола. В целях скомпрометированного названия решили провести ребрендинг, так Autokey v.2 окрестили Network Time Security.

Протокол NTS является расширением безопасности NTP и в настоящее время поддерживает лишь одноадресный режим (unicast). Он дает надежную криптографическую защиту от манипуляций пакетами, предотвращает отслеживание, хорошо масштабируется, устойчив к потере сетевых пакетов и приводит к наименьшим потерям точности, возникающим в процессе защиты соединения.

NTS соединение состоит из двух этапов, в которых используются протоколы нижнего уровня. На первом этапе клиент и сервер договариваются о различных параметрах соединения и обмениваются куки, содержащими ключи со всем сопутствующим набором данных. На втором этапе происходит собственно защищенный NTS сеанс между клиентом и сервером NTP.

NTS состоит из двух протоколов нижнего уровня: Network Time Security Key Exchange (NTS-KE), инициализация безопасного соединения поверх TLS, и NTPv4 — последней инкарнации протокола NTP. Чуть подробнее об этом ниже.

Первый этап — NTS KE

На данном этапе NTP клиент инициирует TLS 1.2/1.3 сеанс по отдельному TCP соединению с сервером NTS KE. Во время этой сессии происходит следующее.

Стороны определяют параметры AEAD алгоритма для второго этапа.
Стороны определяют второй протокол нижнего уровня, но на данный момент лишь NTPv4поддерживается.
Стороны определяют IP адрес и порт NTP сервера.
NTS KE сервер выдает куки под NTPv4.
Стороны извлекают из материала куки пару симметричных ключей (C2S и S2C).

Такой подход имеет большое преимущество в том, что вся нагрузка по передаче секретной информации параметров соединения ложится на проверенный и надежный протокол TLS. Тем самым отпадает необходимость изобретать собственный велосипед для безопасного NTP рукопожатия.

Второй этап — NTP под защитой NTS

На втором этапе клиент безопасно синхронизирует время с NTP сервером. Для этой цели он передает четыре специальных расширения (extension field) в структуре NTPv4 пакета.

Unique Identifier Extension содержит случайный nonce для предотвращения атак путем повтора.
NTS Cookie Extension содержит один из имеющихся в наличие у клиента NTP куки. Поскольку только клиент располагает симметричными AAED ключами C2S и S2C, сервер NTP должен извлечь их из материала куки.
NTS Cookie Placeholder Extension способ для клиента запросить дополнительные куки с сервера. Это расширение необходимо, чтобы ответ сервера NTP не был намного длиннее, чем запрос. Это позволяет предотвратить атаки усиления.
NTS Authenticator and Encrypted Extension Fields Extension содержит шифр алгоритма AAED с C2S ключем, заголовком NTP, временными отметками, и упомянутыми выше EF в качестве сопутствующих данных. Без этого расширения возможно подделать временные отметки.

Получив запрос от клиента, сервер проверяет подлинность NTP пакета. Для этого он должен расшифровать куки, извлечь алгоритм AAED и ключи. После успешной проверки NTP пакета на валидность сервер отвечает клиенту в следующем формате.

Unique Identifier Extension зеркальная копия клиентского запроса, мера против атак путем повтора.
NTS Cookie Extension больше куки для продолжения сеанса.
NTS Authenticator and Encrypted Extension Fields Extension содержит шифр AEAD с S2C ключем.

Второе рукопожатие можно повторить много раз, минуя первый этап, так как каждый запрос и ответ дает клиенту дополнительные куки. Это дает то преимущество, что относительно ресурсоемкие TLS операции вычисления и передачи PKI данных делятся на число повторных запросов. Это особенно удобно для специализированных FPGA хронометров, когда весь основной функционал можно упаковать в несколько функций из области симметричной криптографии, передав весь TLS стек на другое устройство.

NTPSec

В чем особенность NTP? Несмотря на то, что автор проекта Dave Mills старался как можно лучше документировать свой код, редкий программист сумеет разобраться в хитросплетениях алгоритмов синхронизации времени 35-детней давности. Часть кода написана до эпохи POSIX, а Unix API тогда сильно отличался от того, что используется в наши дни. Кроме того, нужны знания по статистике, чтобы очистить сигнала от помех на шумных линиях.

NTS была не первой попыткой починить NTP. После того, как злоумышленники научились использовать уязвимости NTP для усиления DDoS атак, стало ясно, что нужны радикальные перемены. И пока готовились и доводились до ума черновики NTS, National Science Foundation США в конце 2014 г. срочно выделил грант на модернизацию NTP.

Рабочую группу возглавил не абы кто, а Эрик Стивен Реймонд — один из основателей и столпов сообщества Open Source и автор книги Собор и Базар. Первым делом Эрик со товарищи попробовали перенести код NTP из платформы BitKeeper на git, но не тут-то было. Лидер проекта Harlan Stenn был против этого решения и переговоры зашли в тупик. Тогда было решено форкнуть код проекта, так возник NTPSec.

Читайте также: Latest pending version

Солидный опыт, в том числе работа над GPSD, математический бэкграунд и магический навык чтения древнего кода — Эрик Реймонд был именно тем хакером, который мог вытащить такой проект. В команде нашелся специалист по миграции кода и всего за 10 недель NTP обосновалсяна GitLab-е. Работа закипела.

Команда Эрика Раймонда взялась за дело так же, как Огюст Роден при работе с глыбой камня. Удалив 175 KLOC старого кода, им удалось значительно сократить площадь атаки, закрыв множество дыр безопасности.

Вот неполный список попавших под раздачу:

Недокументированные, устаревшие, устаревшие или сломанные refclock.
Неиспользуемая библиотека ICS.
libopts/autogen.
Старый код для Windows.
ntpdc.
Autokey.
C код ntpq переписан на Python.
C код sntp/ntpdig переписан на Python.

Помимо очистки кода были и у проекта были и другие задачи. Вот неполный список достижений:

Значительно усилена защита кода от переполнения буфера. Чтобы предотвратить переполнение буфера, все небезопасные строковые функции (strcpy / strcat / strtok / sprintf / vsprintf / gets) заменили безопасными версиями, которые реализуют ограничение размера буфера.
Добавлена поддержка NTS.
Десятикратно повысили точность временного шага с помощью привязки физического оборудования. Это связано с тем, что современные компьютерные часы стали гораздо точнее тех, что были в момент зарождения NTP. Больше всех от этого выиграли GPSDO и выделенные радиостанции времени.
Количество языков программирования сократилось до двух. Вместо скриптов Perl, awk и даже S, теперь сплошной Python. За счет этого больше возможностей повторного использования кода.
Вместо лапши скриптов autotools проект стал использовать систему сборки программного обеспечения waf.
Обновили и реорганизовали документацию проекта. Из противоречивой, и местами архаичной коллекции документов создали вполне сносную документацию. Каждый ключ командной строки и каждая сущность конфигурации теперь имеют единую версию правды. Кроме того, страницы руководства и веб документация теперь создаются из одних и тех же основных файлов.

NTPSec доступен для ряда Linux дистрибутивов. В данный момент последняя стабильная версия 1.1.8, для Gentoo Linux — предпоследняя.

(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R    ] net-misc/ntpsec-1.1.7-r1::gentoo  USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]

Chrony

Была еще одна попытка заменить старый NTP более безопасный аналог. Chrony в отличие от NTPSec написан с нуля и предназначен для надежной работы в широком диапазоне условий, включая нестабильные сетевые соединения, частичная доступность или перегрузки сети и изменения температуры. Кроме того chrony обладает и другими преимуществами:

chrony может быстрее синхронизировать системные часы с большей точностью;
chrony меньше, потребляет меньше памяти и обращается к процессору только тогда, когда это необходимо. Для экономии ресурсов и энергии это большой плюc;
chrony поддерживает метки времени на аппаратном уровне в Linux, что обеспечивает чрезвычайно точную синхронизацию в локальных сетях.

Впрочем, в chrony отсутствуют некоторые возможности старого NTP такие, как широковещательный и многоадресный (multicast) клиент / сервер. В добавок классический NTP поддерживает большее число ОС и платформ.

Для отключения функциональности сервера и NTP запросов к процессу chronyd достаточно прописать port 0 в файл chrony.conf. Это делается в тех случаях, когда нет нужды обслуживать время для NTP клиентов или одноранговых узлов. Начиная с версии 2.0, порт сервера NTP открыт только в тех случаях, когда доступ разрешен директивой allow или соответствующей командой, либо же настроен одноранговый узел NTP, или используется директива broadcast.

Программа состоит из двух модулей.

chronyd — сервис, работающий в фоновом режиме. Он получает информацию о разнице системных часов с внешним сервером времени и корректирует локальное время. Он также реализует протокол NTP и может выступать в качестве клиента или сервера.
chronyc — утилита командной строки для мониторинга и контроля программы. Используется для тонкой настройки различных параметров сервиса, например позволяет добавлять или удалять серверы NTP в то время, как chronyd продолжает работать.

Начиная с 7-й версии RedHat Linux использует chrony в качестве службы синхронизации времени. Пакет также доступен для остальных дистрибутивов Linux. Последняя стабильная версия 3.5, готовится к выходу v4.0.

(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary  N     ] net-misc/chrony-3.5-r2::gentoo  USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]

Как настроить собственный удаленный сервер chrony в интернете для синхронизации времени в офисной сети. Далее пример настройки на VPS.

Пример настройки Chrony на RHEL / CentOS на VPS

Давайте теперь немного потренируемся и поднимем свой собственный NTP сервер на VPS. Это очень просто, достаточно выбрать подходящий тариф на сайте RuVDS, получить готовый сервер и набрать с десяток несложных команд. Для наших целей вполне подойдет такой вариант.

Переходим к настройке сервиса и первым делом ставим пакет chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 используют другой пакетный менеджер.

[root@server ~]$ dnf install chrony

После установки chrony нужно запустить и активировать сервис.

[root@server ~]$ systemctl enable chrony --now

При желании можно внести правки в /etc/chrony.conf, заменив сервера NPT на ближайшие локальные для сокращения времени отклика.

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst

Далее настраиваем синхронизацию NTP сервера с узлами из указанного пула.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

Необходимо также открыть наружу NTP порт, иначе межсетевой экран будет блокировать входящие соединения от клиентских узлов.

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

На стороне клиента достаточно правильно выставить часовой пояс.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

В файле /etc/chrony.conf указывает IP или название хоста нашего VPS сервера, на котором запущен NTP server chrony.

server my.vps.server

И наконец запуск синхронизации времени на клиенте.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

В следующий раз расскажу, какие есть варианты синхронизации времени без интернета.

Как синхронизация времени стала безопасной

Время на прочтение

истечет срок действия паролей учетных записей пользователей;
истечет срок действия X.509 сертификатов;
двухфакторная аутентификация TOTP перестанет работать;
бэкапы «устареют» и система удалит их;
сломается DNSSec.

Сломать NTP за 25 минут

Key ID — симметричный 32-битный ключ;
MAC (message authentication code) — контрольная сумма NTP пакета;

Autokey рассчитывается следующим образом.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Где H() — криптографическая хэш функция.

Для расчета контрольной суммы пакеты используется та же функция.

MAC=H(Autokey||NTP packet)

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

Алгоритм атаки на вычисление начального числа методом перебора.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

NTS — новый Autokey

Первый этап — NTS KE

Стороны определяют параметры AEAD алгоритма для второго этапа.
Стороны определяют второй протокол нижнего уровня, но на данный момент лишь NTPv4поддерживается.
Стороны определяют IP адрес и порт NTP сервера.
NTS KE сервер выдает куки под NTPv4.
Стороны извлекают из материала куки пару симметричных ключей (C2S и S2C).

Второй этап — NTP под защитой NTS

Unique Identifier Extension содержит случайный nonce для предотвращения атак путем повтора.
NTS Cookie Extension содержит один из имеющихся в наличие у клиента NTP куки. Поскольку только клиент располагает симметричными AAED ключами C2S и S2C, сервер NTP должен извлечь их из материала куки.
NTS Cookie Placeholder Extension способ для клиента запросить дополнительные куки с сервера. Это расширение необходимо, чтобы ответ сервера NTP не был намного длиннее, чем запрос. Это позволяет предотвратить атаки усиления.
NTS Authenticator and Encrypted Extension Fields Extension содержит шифр алгоритма AAED с C2S ключем, заголовком NTP, временными отметками, и упомянутыми выше EF в качестве сопутствующих данных. Без этого расширения возможно подделать временные отметки.

Unique Identifier Extension зеркальная копия клиентского запроса, мера против атак путем повтора.
NTS Cookie Extension больше куки для продолжения сеанса.
NTS Authenticator and Encrypted Extension Fields Extension содержит шифр AEAD с S2C ключем.

NTPSec

Вот неполный список попавших под раздачу:

Недокументированные, устаревшие, устаревшие или сломанные refclock.
Неиспользуемая библиотека ICS.
libopts/autogen.
Старый код для Windows.
ntpdc.
Autokey.
C код ntpq переписан на Python.
C код sntp/ntpdig переписан на Python.

Помимо очистки кода были и у проекта были и другие задачи. Вот неполный список достижений:

Значительно усилена защита кода от переполнения буфера. Чтобы предотвратить переполнение буфера, все небезопасные строковые функции (strcpy / strcat / strtok / sprintf / vsprintf / gets) заменили безопасными версиями, которые реализуют ограничение размера буфера.
Добавлена поддержка NTS.
Десятикратно повысили точность временного шага с помощью привязки физического оборудования. Это связано с тем, что современные компьютерные часы стали гораздо точнее тех, что были в момент зарождения NTP. Больше всех от этого выиграли GPSDO и выделенные радиостанции времени.
Количество языков программирования сократилось до двух. Вместо скриптов Perl, awk и даже S, теперь сплошной Python. За счет этого больше возможностей повторного использования кода.
Вместо лапши скриптов autotools проект стал использовать систему сборки программного обеспечения waf.
Обновили и реорганизовали документацию проекта. Из противоречивой, и местами архаичной коллекции документов создали вполне сносную документацию. Каждый ключ командной строки и каждая сущность конфигурации теперь имеют единую версию правды. Кроме того, страницы руководства и веб документация теперь создаются из одних и тех же основных файлов.

(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R    ] net-misc/ntpsec-1.1.7-r1::gentoo  USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]

Chrony

chrony может быстрее синхронизировать системные часы с большей точностью;
chrony меньше, потребляет меньше памяти и обращается к процессору только тогда, когда это необходимо. Для экономии ресурсов и энергии это большой плюc;
chrony поддерживает метки времени на аппаратном уровне в Linux, что обеспечивает чрезвычайно точную синхронизацию в локальных сетях.

Программа состоит из двух модулей.

chronyd — сервис, работающий в фоновом режиме. Он получает информацию о разнице системных часов с внешним сервером времени и корректирует локальное время. Он также реализует протокол NTP и может выступать в качестве клиента или сервера.
chronyc — утилита командной строки для мониторинга и контроля программы. Используется для тонкой настройки различных параметров сервиса, например позволяет добавлять или удалять серверы NTP в то время, как chronyd продолжает работать.

(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary  N     ] net-misc/chrony-3.5-r2::gentoo  USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]

Пример настройки Chrony на RHEL / CentOS на VPS

Переходим к настройке сервиса и первым делом ставим пакет chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 используют другой пакетный менеджер.

[root@server ~]$ dnf install chrony

После установки chrony нужно запустить и активировать сервис.

[root@server ~]$ systemctl enable chrony --now

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst

Далее настраиваем синхронизацию NTP сервера с узлами из указанного пула.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

На стороне клиента достаточно правильно выставить часовой пояс.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

В файле /etc/chrony.conf указывает IP или название хоста нашего VPS сервера, на котором запущен NTP server chrony.

server my.vps.server

И наконец запуск синхронизации времени на клиенте.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

В следующий раз расскажу, какие есть варианты синхронизации времени без интернета.

NTP — это для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью.

В CentOS, как в одном из дистрибутивов Linux, существует два понятия времени — аппаратное (время на часах материнской платы компьютера) и системное (время в самой операционной системе с учетом часового пояса). Аппаратное время можно узнать/обновить командой hwclock, системное — командой date. В файле /etc/adjtime хранится величина отклонения аппаратных часов и какое время они показывают, локальное или UTC.

[root@centos ~]# cat /etc
0.000000 1484111292 0.000000
1484111292
UTC
[root@centos ~]# hwclock
Wed 11 Jan 2017 03:08:14 PM +10  -1.022807 seconds
[root@centos ~]# date
Wed Jan 11 15:08:14 +10 2017

Из файла /etc/adjtime видно что время хранится в UTC. Для корректного отображения локального времени нужно добавить информацию о часовом поясе. Воспользуемся пакетом tzdata, обновив его через любое зеркало стандартных пакетов и командой timedatectl.

[root@centos ~]# yum update tzdata
[root@centos ~]# timedatectl set-timezone Asia/Vladivostok
[root@centos ~]# timedatectl
      Local time: Wed 2017-01-11 15:21:10 +10
  Universal time: Wed 2017-01-11 05:21:10 UTC
        RTC time: Wed 2017-01-11 05:29:34
       Time zone: Asia/Vladivostok (+10, +1000)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

В качестве NTP сервера/клиента воспользуемся chrony. Источником точного времени выберем NTP-сервера ФГУП ВНИИФТРИ, подключенных к государственному первичному эталону времени РФ.

[root@centos ~]# yum install chrony

[root@centos ~]head -n 12 /etc/chrony.conf
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server ntp1.vniiftri.ru iburst
server ntp2.vniiftri.ru iburst
server ntp3.vniiftri.ru iburst
server ntp4.vniiftri.ru iburst
server vniiftri.khv.ru iburst
server vniiftri2.khv.ru iburst

# Allow NTP client access from local network.
allow 172.16/16

Осталось разрешить на межсетевом экране принимать подключения от клиентов нашей сети.

[root@centos ~]firewall-cmd --zone-public --add-service=ntp

Настройка службы времени завершена а чтобы проверить синхронизацию, воспользуемся chronyc.

[root@centos ~]# chronyc sources
210 Number of sources = 6
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- ntp1.vniiftri.ru              1   6    37    18  -1073us[-2104us] +/-   57ms
^- ntp2.vniiftri.ru              1   6    37    18   -235us[-1266us] +/-   59ms
^- ntp3.vniiftri.ru              1   6    37    17  +2969us[+1938us] +/-   56ms
^- ntp4.vniiftri.ru              1   6    37    18   +931us[ -100us] +/-   52ms
^* vniiftri.khv.ru               1   6    57    15   +254us[ -777us] +/- 3300us
^+ 212.19.17.26                  1   6    37    17   -244us[-1275us] +/- 3463us

unix-linux:centos:configuring-ntp-client-crony-in-time-synchronization-service-chronyd-on-centos-linux-7-4

Настройка службы синхронизации времени chronyd в CentOS Linux 7

Если нужно настроить синхронизацию времени системы на базе CentOS Linux 7.4, например, с корпоративными NTP-серверами, нужно установить один из пакетов работы с NTP.
В данной заметке рассмотрен пример быстрой простой настройки NTP-клиента chrony из одноимённого пакета.

# yum install -y chrony

Настраиваем конфиграционный файл:

# nano -Y sh /etc/chrony.conf

chrony.conf

...
# Domain controllers as NTP-servers

server dc01.holding.com iburst
server dc02.holding.com iburst
...
# Don`t run network server

bindcmdaddress 127.0.0.1

Включаем автозагрузку службы и запускаем её:

# systemctl enable chronyd
# systemctl start chronyd

Проверено на следующих конфигурациях:

Автор первичной редакции:
Алексей Максимов
Время публикации: 18.03.2018 14:58

unix-linux/centos/configuring-ntp-client-crony-in-time-synchronization-service-chronyd-on-centos-linux-7-4.txt

· Последнее изменение: 18.03.2018 15:03 —

Алексей Максимов