Протокол сетевого времени

редактировать
Стандартный протокол для синхронизации времени между устройствами

Протокол сетевого времени (NTP ) - это сетевой протокол для тактовой синхронизации между компьютерными системами через пакетную коммутацию, переменную- задержку сети передачи данных. Действующий с 1985 года, NTP является одним из старейших Интернет-протоколов, используемых в настоящее время. NTP был разработан Дэвидом Л. Миллсом из Университета Делавэра.

NTP предназначен для синхронизации всех участвующих компьютеров с точностью до нескольких миллисекунд of Всемирное координированное время (UTC). Он использует алгоритм пересечения, модифицированную версию алгоритма Марзулло, для выбора точных серверов времени и предназначен для уменьшения влияния переменной задержки сети. NTP обычно может поддерживать время с точностью до десятков миллисекунд в общедоступном Интернете и может достигать точности выше одной миллисекунды в локальных сетях в идеальных условиях. Асимметричные маршруты и перегрузка сети могут вызывать ошибки на 100 мс и более.

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

текущий протокол - версия 4 (NTPv4), который является предлагаемым стандартом, как описано в RFC 5905. Он обратно совместим с версией 3, указанной в RFC 1305.

Contents

  • 1 History
  • 2 Clock stratas
  • 3 Timestamps
  • 4 Алгоритм синхронизации часов
  • 5 Программные реализации
    • 5.1 Эталонная реализация
    • 5.2 SNTP
    • 5.3 Windows Time
    • 5.4 OpenNTPD
    • 5.5 Ntimed
    • 5.6 NTPsec
    • 5.7 хрон.
  • 6 дополнительных секунд
  • 7 Проблемы безопасности
  • 8 См. Также
  • 9 Примечания
  • 10 Ссылки
  • 11 Дополнительная литература
  • 12 Внешние ссылки

История

NTP был разработан Автор Дэвид Л. Миллс.RFC эволюция для NTP 1980 - –1985 - –1990 - –1995 - –2000 - –2005 - –2010 - –2015 - –2020 - RFC 958 RFC 1059 RFC 1119 RFC 1305 RFC 5905 RFC 7822 RFC 1361 RFC 1769 RFC 2030 RFC 4330 ←Служба интернет-часов DCNET ←SNTP

В 1979 году технология сетевой временной синхронизации была использована в том, что, возможно, было первой публичной демонстрацией. из Интернет-служб работает g через трансатлантическую спутниковую сеть на Национальной компьютерной конференции в Нью-Йорке. Позднее технология была описана в Инженерной записке по Интернету (IEN) 173 1981 года, и на ее основе был разработан общедоступный протокол, который был задокументирован в RFC 778. Технология была впервые развернута в локальной сети как часть протокола маршрутизации Hello и реализована в маршрутизаторе Fuzzball, экспериментальной операционной системе, используемой для создания прототипов сети, где она работала в течение многих лет.

Другие связанные сетевые инструменты были доступны и тогда, и сейчас. Они включают протоколы Daytime и Time для записи времени событий, а также параметр ICMP Timestamp и опцию IP Timestamp (RFC 781 ). Более полные системы синхронизации, хотя и не имеют алгоритмов анализа данных и контроля часов NTP, включают в себя демон Unix timed, который использует алгоритм выбора для назначения сервера для всех клиентов; и Служба цифровой синхронизации времени (DTSS), которая использует иерархию серверов, аналогичную модели слоя NTP.

В 1985 году версия NTP 0 (NTPv0) была реализована как в Fuzzball, так и в Unix, а заголовок пакета NTP, а также вычисления задержки и смещения приема-передачи, которые сохранились в NTPv4, были задокументированы в RFC 958. Несмотря на относительно медленные компьютеры и сети, доступные в то время, точность лучше, чем 100 миллисекунд, обычно достигалась на соединяющих каналах Atlantic, с точностью до десятков миллисекунд в сетях Ethernet.

В 1988 году гораздо более полная спецификация протокола NTPv1 с соответствующими алгоритмами была опубликована в RFC 1059. Он основан на результатах экспериментов и алгоритме фильтра часов, описанном в RFC 956, и был первой версией, описывающей клиент-сервер и одноранговые режимы. В 1991 году архитектура, протокол и алгоритмы NTPv1 были доведены до сведения более широкого инженерного сообщества после публикации статьи Дэвида Л. Миллса в IEEE Transactions on Communications.

In В 1989 г. был опубликован RFC 1119, определяющий NTPv2 посредством конечного автомата, с псевдокодом для описания его работы. Он представил протокол управления и схему криптографической аутентификации, которые выжили в NTPv4 вместе с основной частью алгоритма. Однако проект NTPv2 подвергся критике со стороны сообщества DTSS за отсутствие формальной корректности, а процедура выбора часов была изменена, чтобы включить алгоритм Марзулло для NTPv3 и далее.

В 1992, RFC 1305 определил NTPv3. RFC включал анализ всех источников ошибок, от эталонных часов до конечного клиента, что позволило вычислить метрику, помогающую выбрать лучший сервер, на котором несколько кандидатов не согласны. Был введен режим трансляции.

В последующие годы, когда были добавлены новые функции и усовершенствованы алгоритмы, стало очевидно, что требуется новая версия протокола. В 2010 году был опубликован документ RFC 5905, содержащий предлагаемую спецификацию для NTPv4. С тех пор протокол значительно продвинулся вперед, и по состоянию на 2014 год обновленный RFC еще не опубликован. После ухода Миллса из Университета Делавэра эталонная реализация в настоящее время поддерживается как проект с открытым исходным кодом, возглавляемый Харланом Стенном.

Clock strata

США Военно-морская обсерватория Альтернативные главные часы на авиабазе Шривер (Колорадо) - источник слоя 0 для NTP Желтые стрелки указывают прямое соединение; красные стрелки указывают на сетевое соединение.

NTP использует иерархическую, полууровневую систему источников времени. Каждый уровень этой иерархии называется стратой, и наверху ему назначается номер, начинающийся с нуля для эталонных часов. Сервер, синхронизированный с сервером уровня n, работает на уровне n + 1. Число представляет собой расстояние от эталонных часов и используется для предотвращения циклических зависимостей в иерархии. Stratum не всегда является показателем качества или надежности; часто находят источники времени слоя 3, которые более высокого качества, чем другие источники времени слоя 2. Ниже приводится краткое описание пластов 0, 1, 2 и 3.

Stratum 0
Это высокоточные устройства для измерения времени, такие как атомные часы, GPS или другие радиочасы. Они генерируют очень точный сигнал импульсов в секунду, который запускает прерывание и временную метку на подключенном компьютере. Устройства Stratum 0 также известны как эталонные часы. Серверы NTP не могут объявлять себя слоем 0. Поле страты, установленное в 0 в пакете NTP, указывает на неуказанный слой.
Уровень 1
Это компьютеры, у которых системное время равно синхронизируются с точностью до нескольких микросекунд от подключенных к ним устройств уровня 0. Серверы уровня 1 могут взаимодействовать с другими серверами уровня 1 для проверки работоспособности и резервного копирования. Их также называют первичными серверами времени.
Уровень 2
Это компьютеры, которые синхронизируются по сети с серверами уровня 1. Часто компьютер уровня 2 запрашивает несколько серверов уровня 1. Компьютеры уровня 2 могут также взаимодействовать с другими компьютерами уровня 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых устройств.
Уровень 3
Это компьютеры, которые синхронизируются с серверами уровня 2. В них используются те же алгоритмы для пиринга и выборки данных, что и для слоя 2, и они сами могут выступать в качестве серверов для компьютеров уровня 4 и т. Д.

Верхний предел для уровня - 15; stratum 16 используется, чтобы указать, что устройство не синхронизировано. Алгоритмы NTP на каждом компьютере взаимодействуют для построения Беллмана-Форда кратчайшего пути связующего дерева, чтобы минимизировать накопленную задержку приема-передачи к серверам уровня 1 для всех клиентов.

В дополнение к страте протокол может идентифицировать источник синхронизации для каждого сервера с помощью ссылочного идентификатора (refid).

Коды стандартных идентификаторов привязки времени (refid)
Идентификатор ссылки (refid)Источник часов
GOESСпутник на геостационарной орбите
GPSГлобальное позиционирование Система
GALGalileo Система позиционирования
PPSОбщая частота импульсов в секунду
IRIGМеждиапазонная группа приборов
WWVBLF Radio WWVB Форт Коллинз, Колорадо 60 кГц
DCFLF Radio DCF77 Mainflingen, DE 77,5 кГц
HBGLF Radio HBG Прангинс, HB 75 кГц (работа прекращена)
MSFLF Radio MSF Anthorn, UK 60 кГц
JJYLF Radio JJY Фукусима, JP 40 кГц, Сага, JP 60 кГц
LORCMF Radio Loran-C станция, 100
TDFMF Radio Allouis, FR 162 kHz
CHUHF Radio CHU Оттава, Онтарио
WWVHF Radio WWV Форт-Коллинз, Колорадо
WWVHВЧ-радио WWVH Кауаи, Гавайи
NISTNIST телефонный модем
ACTSТелефонный модем NIST
USNOТелефонный модем USNO
PTBСтандартный телефонный модем PTB для Германии
MRSМножественные источники ссылок
XFACInter Face Association Changed (IP-адрес изменен или потерян)
STEPИзменение времени шага, смещение меньше, чем порог паники (1000 с), но больше, чем порог шага (125 мс)

Метки времени

64-битные метки времени, используемые NTP, состоят из 32-битной части для секунд и 32-битной части для дробной секунды, что дает шкалу времени, которая переключается на каждые 2 секунды (136 лет), а теоретическое разрешение составляет 2 секунды (233 пикосекунды). NTP использует эпоху от 1 января 1900 года. Следовательно, первое обновление происходит 7 февраля 2036 года.

NTPv4 вводит 128-битный формат даты: 64 бита для второй и 64 биты для долей секунды. Наиболее значимые 32 бита этого формата - это номер эры, который в большинстве случаев устраняет неоднозначность при опрокидывании. По словам Миллса, «64-битного значения дроби достаточно, чтобы определить количество времени, необходимое фотону для прохождения электрона со скоростью света. 64-битного значения секунды достаточно, чтобы обеспечить однозначное представление времени до вселенная тускнеет. "

Алгоритм синхронизации часов

Время задержки туда и обратно δ

Типичный клиент NTP регулярно опрашивает один или несколько серверов NTP. Клиент должен вычислить свое временное смещение и задержку приема-передачи. Смещение времени θ, разница в абсолютном времени между двумя часами, определяется как

θ = (t 1 - t 0) + (t 2 - t 3) 2 {\ displaystyle \ theta = {(t_ {1}) -t_ {0}) + (t_ {2} -t_ {3}) \ over 2}}\ theta = {(t_1 - t_0) + (t_2 - t_3) \ over 2} ,

и задержку приема-передачи δ на

δ = (t 3 - t 0) - (t 2 - t 1) {\ displaystyle \ delta = {(t_ {3} -t_ {0}) - (t_ {2} -t_ {1})}}\ delta = {(t_3 - t_0) - (t_2- t_1)} ,

где

t0- временная метка запроса клиента пакетной передачи,
t1- это временная метка сервера для приема пакета запроса,
t2- это временная метка сервера для передачи пакета ответа, а
t3- это временная метка клиента приема ответного пакета.

Чтобы вывести выражение для смещение, обратите внимание, что для пакета запроса

t 0 + θ + δ / 2 = t 1 {\ displaystyle t_ {0} + \ theta + \ delta / 2 = t_ {1}}{\ displaystyle t_ {0} + \ theta + \ delta / 2 = t_ {1}}

и для пакет ответа,

t 3 + θ - δ / 2 = t 2 {\ displaystyle t_ {3} + \ theta - \ delta / 2 = t_ {2}}{\ displaystyle t_ {3 } + \ theta - \ delta / 2 = t_ {2}}

Решение для θ дает определение смещение по времени.

Значения θ и δ пропускаются через фильтры и подвергаются статистическому анализу. Выбросы отбрасываются, и оценка временного сдвига получается из трех лучших оставшихся кандидатов. Затем тактовая частота регулируется для постепенного уменьшения смещения, создавая петлю обратной связи.

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

Программные реализации

Утилита протокола управления NTP ntpq используется для запроса состояния сервера уровня 2.

Эталонная реализация

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

SNTP

Simple Network Time Protocol (SNTP ) - менее сложная реализация NTP, использующая тот же протокол, но без необходимости хранить состояние в течение продолжительных периодов времени. Он используется в некоторых встроенных системах и в приложениях, где полная поддержка NTP не требуется.

Windows Time

Все версии Microsoft Windows начиная с Windows 2000 включает службу времени Windows (W32Time), которая может синхронизировать часы компьютера с сервером NTP.

W32Time изначально был реализован для протокола аутентификации Kerberos версии 5, который требовал, чтобы время находилось в пределах 5 минут от правильного значения для предотвращения атак повторного воспроизведения. Версия для Windows 2000 и Windows XP реализует только протокол SNTP и нарушает некоторые аспекты стандарта NTP версии 3.

Начиная с Windows Server 2003 и Windows Vista, включена совместимая реализация NTP. Microsoft заявляет, что W32Time не может надежно поддерживать синхронизацию времени с точностью до одной секунды. Если требуется более высокая точность, Microsoft рекомендует использовать более новую версию Windows или другую реализацию NTP.

Windows 10 и Windows Server 2016 поддерживают точность времени 1 мс при определенных условиях эксплуатации.

OpenNTPD

В 2004 году Хеннинг Брауэр представил OpenNTPD, реализацию NTP с упором на безопасность и охватывающую дизайн с разделением привилегий. Хотя он нацелен на более простые общие потребности пользователей OpenBSD, он также включает некоторые улучшения безопасности протокола, при этом оставаясь совместимым с существующими серверами NTP. Переносная версия доступна в репозиториях пакетов Linux.

Ntimed

Новый клиент NTP, ntimed, был запущен Поул-Хеннинг Камп в 2014 году. Новая реализация спонсируется Linux Foundation в качестве замены эталонной реализации, поскольку было определено, что проще написать новую реализацию с нуля, чем уменьшить размер эталонной реализации. Хотя он не был официально выпущен, ntimed может надежно синхронизировать часы.

NTPsec

NTPsec - это вилка эталонной реализации, которая систематически защищена- закаленный. Точка разветвления пришлась на июнь 2015 года и возникла в ответ на серию компромиссов в 2014 году. Первый производственный выпуск был выпущен в октябре 2017 года. Между удалением небезопасных функций, удалением поддержки устаревшего оборудования и удалением поддержки устаревших вариантов Unix, NTPsec удалось сократить 75% исходной кодовой базы, сделав оставшуюся более доступной для аудита. Аудит кода 2017 года показал восемь проблем безопасности, в том числе две, которых не было в исходной эталонной реализации, но NTPsec не пострадал от восьми других проблем, которые остались в эталонной реализации.

chrony

chronyc, пользовательская лицензия и справка из командной строки. Окно терминала в Ubuntu 16.04.

chrony по умолчанию входит в Red Hat дистрибутивы и доступен в Ubuntu репозитории. chrony нацелен на обычные компьютеры, которые нестабильны, переходят в спящий режим или имеют прерывистое подключение к Интернету. chrony также разработан для виртуальных машин, гораздо более нестабильной среды. Он отличается низким потреблением ресурсов (стоимостью) и поддерживает оборудование Precision Time Protocol для большей точности временных меток. Он состоит из двух основных компонентов: chronyd, демона, который запускается при запуске компьютера, и chronyc, интерфейса командной строки для пользователя для его настройки. Он был оценен как очень безопасный и с небольшим количеством инцидентов, его преимуществом является универсальность кода, написанного с нуля, чтобы избежать ненужной сложности. chrony доступен в соответствии с Стандартной общественной лицензией GNU версии 2, был создан в 1997 году и в настоящее время поддерживается компанией.

Дополнительные секунды

В день Событие високосной секунды, ntpd получает уведомление либо от файла конфигурации, либо от прикрепленных эталонных часов, либо от удаленного сервера. Хотя часы NTP фактически останавливаются во время события, из-за требования, чтобы время казалось монотонно возрастающим, любые процессы, запрашивающие системное время, вызывают его увеличение на крошечный сумма, сохраняя порядок событий. Если когда-либо понадобится отрицательная дополнительная секунда, она будет удалена с помощью последовательности 23:59:58, 00:00:00, пропуская 23:59:59.

Альтернативная реализация, называемая размытием прыжка, заключается в постепенном вводе дополнительной секунды в течение 24 часов, с полудня до полудня по всемирному координированному времени. Эта реализация используется Google (как внутри компании, так и на их общедоступных серверах NTP) и Amazon AWS.

Проблемы безопасности

Лишь несколько других проблем безопасности были выявлены в эталонной реализации Кодовая база NTP, но те, что появились в 2009 году, вызвали серьезное беспокойство. Протокол пересматривался и пересматривался на протяжении всей своей истории. Кодовая база для эталонной реализации в течение нескольких лет подвергалась аудитам безопасности из нескольких источников.

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

Аудит безопасности трех реализаций NTP, проведенный в 2017 г. от имени Linux Foundation Core Infrastructure Initiative, показал, что оба NTP и NTPsec были более проблематичными, чем Chrony, с точки зрения безопасности.

NTP-серверы могут быть уязвимы для атак типа «человек посередине», если пакеты не подписаны криптографически для аутентификации. Затраты на вычисления могут сделать это непрактичным на загруженных серверах, особенно во время атак отказа в обслуживании. Подмена сообщений NTP в результате атаки «злоумышленник-посередине» может использоваться для перемещения часов на клиентских компьютерах и обеспечения ряда атак, основанных на обходе истечения срока действия криптографического ключа. Некоторые из выявленных фальшивых сообщений NTP затрагивают следующие службы: TLS, DNSSEC, различные схемы кэширования (например, DNS-кеш), BGP, Bitcoin и ряд постоянных схем входа в систему.

NTP использовался в распределенных атаках типа «отказ в обслуживании». На сервер NTP отправляется небольшой запрос с подмененным адресом возврата как целевым адресом. Подобно атаке с усилением DNS, сервер отвечает гораздо большим ответом, что позволяет злоумышленнику существенно увеличить объем данных, отправляемых цели. Чтобы избежать участия в атаке, можно обновить программное обеспечение сервера NTP или настроить серверы на игнорирование внешних запросов.

См. Также

Примечания

Ссылки

Дополнительная литература

Внешние ссылки

Последняя правка сделана 2021-05-31 04:55:51
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте