stringtranslate.com

Сетевой протокол времени

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

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

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

Текущий протокол — это версия 4 (NTPv4), [5] которая обратно совместима с версией 3. [6]

История

NTP был разработан Дэвидом Л. Миллсом .

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

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

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

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

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

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

В последующие годы, по мере добавления новых функций и усовершенствования алгоритмов, стало очевидно, что требуется новая версия протокола. [22] В 2010 году был опубликован RFC  5905, содержащий предлагаемую спецификацию для NTPv4. [23] После ухода Миллса из Университета Делавэра , эталонная реализация в настоящее время поддерживается как проект с открытым исходным кодом под руководством Харлана Стенна. [24] [25] Со стороны IANA рабочая группа ntp ( протоколы сетевого времени ) отвечает за рассмотрение предлагаемых проектов. [26]

Протокол значительно продвинулся со времени NTPv4. [23] По состоянию на 2022 год было опубликовано три документа RFC, описывающих обновления протокола, [5] не считая многочисленных периферийных стандартов, таких как NTS ( RFC  8915). [26] Миллс упомянул на своей странице планы по «NTPv5», но ни один из них так и не был опубликован. [23] Несвязанный проект под названием «NTPv5» был инициирован М. Личваром из chrony в 2020 году и включает изменения в области безопасности, точности и масштабирования. [27]

SNTP

Поскольку NTP заменил использование старого протокола времени , некоторые варианты использования, тем не менее, обнаружили, что полный протокол слишком сложен. В 1992 году был определен Simple Network Time Protocol ( SNTP ), чтобы заполнить эту нишу. Стандарт SNTPv3 описывает способ использования NTPv3, при котором не требуется хранение состояния в течение длительного периода. Топология становится по сути такой же, как и в протоколе времени, поскольку используется только один сервер. [10] В 1996 году SNTP был обновлен до SNTPv4 [12] с некоторыми функциями тогда еще находившегося в разработке NTPv4. Текущая версия SNTPv4 была объединена с основным стандартом NTPv4 в 2010 году. [5] SNTP полностью совместим с NTP, поскольку он не определяет новый протокол. [28] : §14  Однако простые алгоритмы предоставляют время с пониженной точностью, и поэтому нецелесообразно синхронизировать время с источником SNTP. [13]

Часовые слои

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

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

Слой 0
Это высокоточные устройства для измерения времени, такие как атомные часы , GNSS (включая GPS ) или другие радиочасы , или часы, синхронизированные по PTP . [29] Они генерируют очень точный импульсный сигнал в секунду , который запускает прерывание и временную метку на подключенном компьютере. Устройства Stratum 0 также известны как опорные часы. Серверы NTP не могут объявлять себя как stratum 0. Поле stratum, установленное на 0 в пакете NTP, указывает на неопределенный stratum. [30]
Слой 1
Это компьютеры, системное время которых синхронизировано с их подключенными устройствами уровня 0 с точностью до нескольких микросекунд. Серверы уровня 1 могут взаимодействовать с другими серверами уровня 1 для проверки работоспособности и резервного копирования. [31] Их также называют первичными серверами времени. [2] [3]
Слой 2
Это компьютеры, которые синхронизируются по сети с серверами уровня 1. Часто компьютер уровня 2 запрашивает несколько серверов уровня 1. Компьютеры уровня 2 также могут взаимодействовать с другими компьютерами уровня 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых узлов.
Слой 3
Это компьютеры, которые синхронизированы с серверами уровня 2. Они используют те же алгоритмы для пиринга и выборки данных, что и уровень 2, и сами могут выступать в качестве серверов для компьютеров уровня 4 и т. д.

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

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

Для серверов на уровне 2 и ниже refid представляет собой закодированную форму IP-адреса сервера времени вышестоящего уровня. Для IPv4 это просто 32-битный адрес; для IPv6 это будут первые 32 бита MD5-хэша исходного адреса. Refid служат для обнаружения и предотвращения циклов синхронизации первой степени. [5]

Поле refid заполняется статусными словами в случае пакетов kiss-o'-death (KoD), которые сообщают клиенту о необходимости прекратить отправку запросов, чтобы сервер мог отдохнуть. [5] Вот некоторые примеры: INIT (инициализация), STEP (изменение времени шага) и RATE (клиент запрашивает слишком быстро). [33] Выходные данные программы могут дополнительно использовать коды, не переданные в пакете, для указания на ошибку, например XFAC для указания на отключение сети. [32]

IANA ведет реестр имен источников refid и кодов KoD. Неофициальные назначения все еще могут появляться. [34]

Временные метки

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

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

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

Время задержки в обоих направлениях δ

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

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

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

Значения θ и δ пропускаются через фильтры и подвергаются статистическому анализу («смягчение»). Выбросы отбрасываются, и оценка смещения времени выводится из трех лучших оставшихся кандидатов. Затем тактовая частота корректируется для постепенного уменьшения смещения («дисциплина»), создавая петлю обратной связи . [1] : 20 

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

Реализации программного обеспечения

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

Референтная реализация

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

Время Windows

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

W32Time изначально был реализован для протокола аутентификации Kerberos версии 5, который требовал, чтобы время находилось в пределах 5 минут от правильного значения для предотвращения атак повторного воспроизведения . Сетевой сервер времени в Windows 2000 Server (и Windows XP) не реализует дисциплинированную синхронизацию NTP, а только локально дисциплинированную синхронизацию с коррекцией NTP/SNTP. [44]

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

Начиная с Windows 10 версии 1607 и Windows Server 2016 , W32Time можно настроить для достижения точности времени 1 с, 50 ​​мс или 1 мс при определенных заданных условиях эксплуатации. [48] [46] [49]

OpenNTPD

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

NTPsec

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

хрони

chronyc, показывающий источники и информацию об активности. Окно терминала под Arch Linux

chrony — это независимая реализация NTP, в основном спонсируемая Red Hat , которая использует ее в качестве программы времени по умолчанию в своих дистрибутивах. [56] Будучи написанной с нуля, chrony имеет более простую кодовую базу, что обеспечивает лучшую безопасность [57] и меньшее потребление ресурсов. [58] Однако она не идет на компромисс с точностью, вместо этого синхронизируясь быстрее и лучше, чем эталонный ntpd во многих обстоятельствах. Она достаточно универсальна для обычных компьютеров, которые нестабильны, переходят в спящий режим или имеют прерывистое подключение к Интернету. Она также разработана для виртуальных машин, более нестабильной среды. [59]

Chrony был оценен как «заслуживающий доверия», с несколькими инцидентами. [60] Он способен достигать повышенной точности в LAN-соединениях, используя аппаратную отметку времени на сетевом адаптере. [40] Поддержка Network Time Security (NTS) была добавлена ​​в версии 4.0. [61] chrony доступен по лицензии GNU General Public License версии 2 , был создан Ричардом Курновом в 1997 году и в настоящее время поддерживается Мирославом Личваром. [58]

Другие

Високосные секунды

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

Альтернативная реализация, называемая leap smearing, заключается во введении високосной секунды постепенно в течение 24 часов, с полудня до полудня по времени UTC. Эта реализация используется Google (как внутри компании, так и на их публичных серверах NTP), Amazon AWS, [66] и Facebook. [67] Chrony поддерживает leap smear в конфигурациях smoothtime и leapsecmode , но такое использование не следует смешивать с публичным пулом NTP, поскольку leap smear нестандартен и в смеси сбивает клиентские вычисления. [68]

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

Поскольку настройка системного времени, как правило, является привилегированной операцией, часть или весь код NTP должен быть запущен с некоторыми привилегиями для поддержки его основных функций. В эталонной реализации кодовой базы NTP было выявлено всего несколько других проблем безопасности, но те, которые появились в 2009 году [ какие? ], стали причиной серьезного беспокойства. [69] [70] Протокол подвергался пересмотру и проверке на протяжении всей своей истории. Кодовая база для эталонной реализации подвергалась аудитам безопасности из нескольких источников в течение нескольких лет. [71]

Эксплойт переполнения буфера стека был обнаружен и исправлен в 2014 году. [72] Apple была достаточно обеспокоена этой уязвимостью, чтобы впервые использовать свою возможность автоматического обновления. [73] В системах, использующих эталонную реализацию, которая работает с учетными данными пользователя root, это может разрешить неограниченный доступ. Некоторые другие реализации, такие как OpenNTPD , имеют меньшую кодовую базу и приняли другие меры по смягчению, такие как разделение привилегий, и не подвержены этой уязвимости. [74]

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

Серверы NTP могут быть подвержены атакам типа «человек посередине» , если пакеты не подписаны криптографически для аутентификации. [80] Вычислительные издержки могут сделать это непрактичным на загруженных серверах, особенно во время атак типа «отказ в обслуживании» . [81] Подделка сообщений NTP от атаки типа «человек посередине» может использоваться для изменения часов на клиентских компьютерах и позволяет проводить ряд атак, основанных на обходе истечения срока действия криптографического ключа. [82] Некоторые из выявленных служб, затронутых поддельными сообщениями NTP, включают TLS , DNSSEC , различные схемы кэширования (например, кэш DNS), протокол пограничного шлюза (BGP), Bitcoin [ требуется ссылка ] и ряд постоянных схем входа в систему. [83] [84]

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

Безопасные расширения

Сам NTP включает поддержку аутентификации серверов для клиентов. NTPv3 поддерживает симметричный режим ключа , который бесполезен против MITM. Система открытого ключа, известная как «autokey» в NTPv4, адаптированная из IPSec, предлагает полезную аутентификацию, [80] но непрактична для загруженного сервера. [81] Позже было обнаружено, что Autokey также страдает от нескольких недостатков дизайна, [88] без опубликованных исправлений, за исключением изменения кода аутентификации сообщений . [16]

Network Time Security (NTS) — это защищенная версия NTPv4 с TLS и AEAD . [89] Главное улучшение по сравнению с предыдущими попытками заключается в том, что отдельный сервер «установления ключа» обрабатывает тяжелую асимметричную криптографию, которую нужно выполнить только один раз. Если сервер выйдет из строя, предыдущие пользователи все равно смогут получить время, не опасаясь MITM. [90] NTS в настоящее время поддерживается несколькими серверами времени, [91] [92] включая Cloudflare . Он поддерживается NTPSec и chrony. [93]

У Microsoft также есть подход к аутентификации пакетов NTPv3/SNTPv4 с использованием идентификатора домена Windows , известного как MS-SNTP. [94] Эта система реализована в эталонных ntpd и chrony, использующих samba для подключения к домену. [95]

Смотрите также

Примечания

  1. ^ Телекоммуникационные системы используют другое определение для тактовых страт .
  2. ^ 2 −64 секунды составляют около 54 зептосекунд (свет прошел бы 16,26 пикометров, или приблизительно 0,31 × радиус Бора ), а 2 64 секунды составляют около 585 миллиардов лет .

Ссылки

  1. ^ abcdef Дэвид Л. Миллс (12 декабря 2010 г.). Синхронизация времени компьютерной сети: сетевой протокол времени. Тейлор и Фрэнсис. стр. 12–. ISBN 978-0-8493-5805-0. Архивировано из оригинала 18 июля 2014 . Получено 16 октября 2016 .
  2. ^ abc "Резюме: Синхронизация времени компьютерной сети". Архивировано из оригинала 2011-11-02 . Получено 2011-11-21 .
  3. ^ abcd "NTP FAQ". Проект NTP. Архивировано из оригинала 2011-09-06 . Получено 2011-08-27 .
  4. ^ "Номера портов". Управление по распределению адресов Интернета (IANA). Архивировано из оригинала 2001-06-04 . Получено 2011-01-19 .
  5. ^ abcdefg D. Mills ; J. Burbank ; W. Kasch (август 2010 г.). J. Martin (ред.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force . doi : 10.17487/RFC5905 . ISSN  2070-1721. RFC 5905. Предложенный стандарт. Отменяет RFC 1305, 4330. Обновлен RFC 7822, 8573 и 9109.
  6. ^ Дэвид Л. Миллс (март 1992 г.). Протокол сетевого времени (версия 3) — спецификация, реализация и анализ. Сетевая рабочая группа. doi : 10.17487/RFC1305 . RFC 1305. Устарело. Устарело из-за RFC 5905. Устаревшие RFC 958, 1059 и 1119.
  7. ^ Д. Миллс (сентябрь 1985 г.). Сетевой протокол времени (NTP). Сетевая рабочая группа. doi : 10.17487/RFC0958 . RFC 958. Устарело. Устарело согласно RFC 1059, 1119 и 1305.
  8. ^ Д. Миллс (июль 1988 г.). Спецификация и реализация сетевого протокола времени (версия 1). Сетевая рабочая группа. doi : 10.17487/RFC1059 . RFC 1059. Устарело. Устарело согласно RFC 1119 и 1305.
  9. ^ Д. Миллс (сентябрь 1989 г.). Спецификация и реализация сетевого протокола времени (версия 2). Сетевая рабочая группа. doi : 10.17487/RFC1119 . RFC 1119. Устарело. Устарело из-за RFC 1305. Устаревшие RFC 958 и 1059.
  10. ^ ab D. Mills (август 1992 г.). Тип службы в наборе протоколов Интернета. Сетевая рабочая группа. doi : 10.17487/RFC1361 . RFC 1361. Устарело. Устарело согласно RFC 1769.
  11. ^ Д. Миллс (март 1995 г.). Простой сетевой протокол времени (SNTP). Сетевая рабочая группа. doi : 10.17487/RFC1769 . RFC 1769. Устарело. Устарело по RFC 2030. Устаревший RFC 1361.
  12. ^ ab D. Mills (октябрь 1996 г.). Простой сетевой протокол времени (SNTP) версии 4 для IPv4, IPv6 и OSI. Сетевая рабочая группа. doi : 10.17487/RFC2030 . RFC 2030. Устарело. Устарело из-за RFC 4330. Устаревший RFC 1769.
  13. ^ ab D. Mills (январь 2006 г.). Простой сетевой протокол времени (SNTP) версии 4 для IPv4, IPv6 и OSI. Сетевая рабочая группа. doi : 10.17487/RFC4330 . RFC 4330. Устарело. Устаревшие RFC 2030 и 1769. Устаревший RFC 5905.
  14. ^ DL Mills (апрель 1981 г.). Служба часов Интернета DCNET. IETF . doi : 10.17487/RFC0778 . RFC 778. Исторический.
  15. ^ T. Mizrahi; D. Mayer (март 2016 г.). Поля расширения сетевого протокола времени версии 4 (NTPv4). IETF . doi : 10.17487/RFC7822 . ISSN  2070-1721. RFC 7822. Информационное. Обновления RFC 5905.
  16. ^ ab A. Malhotra; S. Goldberg (июнь 2019 г.). Код аутентификации сообщений для сетевого протокола времени. Internet Engineering Task Force . doi : 10.17487/RFC8573 . ISSN  2070-1721. RFC 8573. Предложенный стандарт. Обновления RFC 5905.
  17. ^ F. Gont; G. Gont; M. Lichvar (август 2021 г.). Network Time Protocol версии 4: рандомизация портов. Internet Engineering Task Force . doi : 10.17487/RFC9109 . ISSN  2070-1721. RFC 9109. Предложенный стандарт. Обновления RFC 5905.
  18. ↑ DL Mills (25 февраля 1981 г.), Синхронизация времени в хостах DCNET, архивировано из оригинала 30 декабря 1996 г.
  19. ^ "TIMED(8)", Руководство администратора системы UNIX , архивировано из оригинала 2011-07-22 , извлечено 2017-09-12
  20. ^ Дэвид Л. Миллс (октябрь 1991 г.). «Синхронизация времени в Интернете: сетевой протокол времени» (PDF) . IEEE Transactions on Communications . 39 (10): 1482–1493. Bibcode :1991ITCom..39.1482M. doi :10.1109/26.103043. Архивировано (PDF) из оригинала 2016-06-10 . Получено 2017-11-06 .
  21. ^ Дэвид Л. Миллс (март 1992 г.). Протокол сетевого времени (версия 3) — спецификация, реализация и анализ. Сетевая рабочая группа. doi : 10.17487/RFC1305 . RFC 1305. Устарело. Процедура выбора часов была изменена, чтобы удалить первый из двух этапов сортировки/отбрасывания и заменить его алгоритмом, впервые предложенным Марзулло и позднее включенным в Цифровую службу времени. Эти изменения не оказывают существенного влияния на обычную работу или совместимость с различными версиями NTP, но они обеспечивают основу для формальных заявлений о корректности.
  22. ^ Дэвид Л. Миллс (15 ноября 2010 г.). Синхронизация времени компьютерной сети: сетевой протокол времени на Земле и в космосе, второе издание. CRC Press. стр. 377. ISBN 978-1-4398-1464-2.
  23. ^ abc "Планы на будущее", Исследовательский проект по синхронизации сетевого времени, архивировано из оригинала 23 декабря 2014 г. , извлечено 24 декабря 2014 г.
  24. ^ «NTP Needs Money: Is A Foundation The Answer?». InformationWeek . 23 марта 2015 г. Архивировано из оригинала 10 апреля 2015 г. Получено 4 апреля 2015 г.
  25. ^ "Судьба NTP зависит от "Отца Времени"". InformationWeek . 11 марта 2015 г. Архивировано из оригинала 10 апреля 2015 г. Получено 4 апреля 2015 г.
  26. ^ ab "Протоколы сетевого времени (ntp): Документы". datatracker.ietf.org . Получено 27 декабря 2022 г. .
  27. ^ Личвар, Мирослав (6 декабря 2022 г.). «Протокол сетевого времени версии 5». www.ietf.org .
  28. ^ D. Mills ; J. Burbank ; W. Kasch (август 2010 г.). J. Martin (ред.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force . doi : 10.17487/RFC5905 . ISSN  2070-1721. RFC 5905. Предложенный стандарт. Первичные серверы и клиенты, соответствующие подмножеству NTP, называемому Simple Network Time Protocol (SNTPv4) [...], не нуждаются в реализации алгоритмов смягчения [...] Полностью разработанная реализация NTPv4 предназначена для [...] серверов с несколькими вышестоящими серверами и несколькими нижестоящими серверами [...] За исключением этих соображений, серверы и клиенты NTP и SNTP полностью совместимы и могут смешиваться [...]
  29. ^ "Combining PTP with NTP to Get the Best of Both Worlds". www.redhat.com . Программы из пакета linuxptp могут использоваться в сочетании с демоном NTP. Часы PTP на сетевой карте синхронизируются ptp4l и используются в качестве опорных часов chronyd или ntpd для синхронизации системных часов.
  30. ^ RFC 5905, стр. 21
  31. ^ "Network Time Protocol: Best Practices White Paper". Архивировано из оригинала 1 октября 2013 г. Получено 15 октября 2013 г.
  32. ^ ab "'ntpq -p' output". NLUG.ML1.co.uk . Архивировано из оригинала 2018-11-12 . Получено 2018-11-12 .
  33. ^ "Сообщения о событиях и слова состояния". docs.ntpsec.org . Коды Refid используются в пакетах kiss-o'-death (KoD), поле идентификатора ссылки в дисплеях ntpq и ntpmon billboard и сообщениях журнала.
  34. ^ "Параметры сетевого протокола времени (NTP)". www.iana.org .
  35. ↑ Дэвид Л. Миллс (12 мая 2012 г.). «Эра NTP и нумерация эр». Архивировано из оригинала 26 октября 2016 г. Получено 24 сентября 2016 г.
  36. ^ W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). Сетевое программирование UNIX. Addison-Wesley Professional. стр. 582–. ISBN 978-0-13-141155-5. Архивировано из оригинала 2019-03-30 . Получено 2016-10-16 .
  37. ^ "Взгляд на проблемы 2036/2038 годов и устойчивость времени в различных системах". 14 марта 2017 г. Архивировано из оригинала 21 июля 2018 г. Получено 20 июля 2018 г.
  38. ^ Презентация Дэвида Миллса на семинаре по цифровым системам в Университете Делавэра , 2006-04-26
  39. ^ Гото, Т.; Имамура, К.; Канеко, А. (2002). «Улучшение смещения времени NTP в асимметричной сети с методом двойных пакетов». Сборник конференций по прецизионным электромагнитным измерениям . Конференция по прецизионным электромагнитным измерениям. стр. 448–449. doi :10.1109/CPEM.2002.1034915. ISBN 0-7803-7242-5.
  40. ^ ab Lichvar, Miroslav (18 сентября 2018 г.). "chrony – chrony.conf(5)". Проект Chrony . Получено 2 августа 2020 г. Эта директива включает аппаратную временную метку пакетов NTP, отправляемых и получаемых с указанного сетевого интерфейса.
  41. ^ "sourcestats.c, функция estimate_asymmetry()". git.tuxfamily.org (chrony) .
  42. ^ "Pentest-Report NTP 01.2017" (PDF) . Cure53. 2017. Архивировано (PDF) из оригинала 2018-12-01 . Получено 2019-07-03 .
  43. ^ "Технический справочник службы времени Windows". technet.microsoft.com. 2011-08-17. Архивировано из оригинала 2011-09-06 . Получено 2011-09-19 .
  44. ^ "Страница службы времени Windows на NTP.org". Support.NTP.org . 2008-02-25. Архивировано из оригинала 2017-05-14 . Получено 2017-05-01 .
  45. ^ "Как работает служба времени Windows". technet.microsoft.com. 2010-03-12. Архивировано из оригинала 2011-09-24 . Получено 2011-09-19 .
  46. ^ ab "Поддержка границы для настройки службы времени Windows для сред с высокой точностью". Microsoft . 2011-10-19. Архивировано из оригинала 2009-01-12 . Получено 2008-12-10 .
  47. ^ Нед Пайл (2007-10-23). ​​"High Accuracy W32time Requirements". Microsoft . Архивировано из оригинала 2012-10-17 . Получено 2012-08-26 .
  48. ^ "Windows Server 2016 Accurate Time". technet.microsoft.com . Архивировано из оригинала 2016-12-02 . Получено 2016-12-07 .
  49. ^ dahavey. "Граница поддержки для высокоточного времени". docs.microsoft.com . Получено 24.07.2021 .
  50. ^ "ntpd(8) - страницы руководства OpenBSD". man.openbsd.org . Он реализует Simple Network Time Protocol версии 4, как описано в RFC 5905, и Network Time Protocol версии 3, как описано в RFC 1305.
  51. ↑ Проект OpenBSD (21 августа 2006 г.). «FAQ 6.12.1: „Но OpenNTPD не так точен, как демон ntp.org!“». Проект OpenBSD . Архивировано из оригинала 2016-02-05 . Получено 2020-05-14 .
  52. ^ Рэймонд, Эрик С. (2017-03-30). "NTPsec: безопасная, защищенная реализация NTP | Linux Journal". Linux Journal . Архивировано из оригинала 2024-01-26 . Получено 2024-01-26 .
  53. ^ "Распространение протокола безопасного сетевого времени (NTPsec)". Архивировано из оригинала 2019-01-13 . Получено 2019-01-12 .
  54. ↑ Лиска, Аллан (10 декабря 2016 г.). Безопасность NTP: Краткое руководство. Апресс. стр. 80–. ISBN 978-1-4842-2412-0.
  55. ^ "Pentest-Report NTPsec 01.2017" (PDF) . Cure53. 2017. Архивировано (PDF) из оригинала 2019-07-04 . Получено 2019-07-03 .
  56. ^ Lichvar, Miroslav (20 июля 2016 г.). «Объединение PTP с NTP для получения лучшего из обоих миров». Red Hat Enterprise Linux Blog . Red Hat . Архивировано из оригинала 30 июля 2016 г. . Получено 19 ноября 2017 г. Начиная с Red Hat Enterprise Linux 7.0 (а теперь и в Red Hat Enterprise Linux 6.8) более универсальная реализация NTP также предоставляется через пакет chrony
  57. ^ "Securing Network Time". Core Infrastructure Initiative, совместный проект Linux Foundation . Core Infrastructure Initiative. 27 сентября 2017 г. Архивировано из оригинала 28 октября 2017 г. Получено 19 ноября 2017 г. В целом, программное обеспечение Chrony NTP надежно и может считаться заслуживающим доверия.
  58. ^ ab "chrony introduction". TuxFamily, некоммерческая организация . chrony. Архивировано из оригинала 9 декабря 2009 г. . Получено 19 ноября 2017 г. Программное обеспечение поддерживается на Linux, FreeBSD, NetBSD, macOS и Solaris.
  59. ^ Оба, Дэвид. «Управление NTP с помощью Chrony». Opensource.com . Архивировано из оригинала 29 июня 2019 г. Получено 29 июня 2019 г.
  60. ^ Хайдерих, Марио (август 2017 г.). "Pentest-Report Chrony 08.2017" (PDF) . Команда Cure53.de . wiki.mozilla.org, также известная как MozillaWiki или WikiMO. Архивировано из оригинала (PDF) 5 октября 2017 г. . Получено 19 ноября 2017 г. Выдержав одиннадцать полных дней удаленного тестирования в августе 2017 г., Chrony стал надежным, сильным и разработанным с учетом безопасности.
  61. ^ "chrony/chrony.git - Официальный репозиторий Git для проекта Chrony". git.tuxfamily.org . Получено 2021-07-31 .
  62. ^ Poul-Henning, Kamp. "20140926 – Playing with time again". PHK's Bikeshed . Архивировано из оригинала 20 декабря 2019 года . Получено 4 июня 2015 года .
  63. ^ Poul-Henning, Kamp. "Программное обеспечение для синхронизации сетевого времени, замена NTPD". Файл README репозитория ntimed git . Github. Архивировано из оригинала 2 августа 2015 г. Получено 4 июня 2015 г.
  64. ^ "Переход с OpenNTPd на Chrony - anarcat". anarc.at . Таким образом, по сути, systemd-timesyncd стал демоном NTP по умолчанию в Debian в bookworm, что я нахожу несколько удивительным.
  65. ^ Дэвид Миллс. "Шкала времени NTP и високосные секунды". Архивировано из оригинала 7 сентября 2013 года . Получено 15 октября 2013 года .
  66. ^ "Google Developers Leap Smear". Архивировано из оригинала 4 апреля 2019 г. Получено 4 апреля 2019 г.
  67. ^ Облеухов, Олег (18 марта 2020 г.). «Создание более точного сервиса времени в масштабе Facebook». Инжиниринг в Meta .
  68. ^ "chrony – Часто задаваемые вопросы". chrony.tuxfamily.org .
  69. ^ "Уведомление о безопасности". Support.NTP.org . 2009-12-10 . Получено 2011-01-12 .[ постоянная мертвая ссылка ]
  70. ^ "Уязвимость пакета сетевого протокола времени Cisco IOS". Cisco Systems . 23 сентября 2009 г. Архивировано из оригинала 11 июня 2020 г. Получено 11 июня 2020 г.
  71. ^ "Аудит кода". Support.NTP.org . 2009-06-13 . Получено 2011-01-12 .
  72. ^ "Уязвимости протокола сетевого времени (обновление C) | ICS-CERT". Ics-cert.us-cert.gov. Архивировано из оригинала 2014-12-20 . Получено 15-04-2015 .
  73. ^ Каннингем, Эндрю (23 декабря 2014 г.). «Apple автоматически исправляет серьезную уязвимость безопасности NTP на компьютерах Mac». arstechnica. Архивировано из оригинала 15 апреля 2015 г. Получено 29 апреля 2015 г.
  74. ↑ Fairhead, Harry (23 декабря 2014 г.). «NTP: последняя проблема безопасности с открытым исходным кодом». I Programmer. Архивировано из оригинала 24 декабря 2014 г. Получено 24 декабря 2014 г.
  75. ^ Страница NTP SecurityNotice Архивировано 19 февраля 2014 г. на Wayback Machine
  76. ^ NVD NIST Поиск продукта NTP
  77. ^ Поиск продукта NVD NIST NTPsec Архивировано 26.06.2020 на Wayback Machine
  78. ^ Поиск продуктов NVD NIST Chrony Архивировано 26.06.2020 на Wayback Machine
  79. ^ "CII Audit Identifies Most Secure NTP Implementation". Linux Foundation. 28 сентября 2017 г. Архивировано из оригинала 2018-02-03 . Получено 2019-07-03 .
  80. ^ ab Network Time Protocol Version 4: Autokey Specification. IETF. Июнь 2010 г. doi : 10.17487/RFC5906 . RFC 5906.
  81. ^ ab "Анализ безопасности NTP". Архивировано из оригинала 7 сентября 2013 г. Получено 11 октября 2013 г.
  82. ^ Хосе Сельви (16.10.2014). "Обход HTTP Strict Transport Security" (PDF) . Архивировано из оригинала (PDF) 18.10.2014 . Получено 16.10.2014 .
  83. ^ Aanchal Malhotra; Isaac E. Cohen; Erik Brakke & Sharon Goldberg (20 октября 2015 г.). «Attacking the Network Time Protocol» (PDF) . NDSS . Архивировано из оригинала (PDF) 22 октября 2015 г. . Получено 27 октября 2015 г. .
  84. ^ "Атака сетевого протокола времени". www.cs.bu.edu . Архивировано из оригинала 2015-10-24 . Получено 2015-10-27 .
  85. ^ Гудин, Дэн (13.01.2014). «Новые DoS-атаки, уничтожающие игровые сайты, вызывают парализующие потоки трафика в 100 Гбит/с». Ars Technica . Архивировано из оригинала 24.01.2014 . Получено 25.01.2014 .
  86. ↑ Ли, Дэйв (11.02.2014). «Огромный взлом — „уродливый знак будущего“ для интернет-угроз». BBC. Архивировано из оригинала 11.02.2014 . Получено 12.02.2014 .
  87. ^ "DRDoS / Атака усиления с использованием команды ntpdc monlist". support.NTP.org . 2010-04-24. Архивировано из оригинала 2014-03-30 . Получено 2014-04-13 .
  88. ^ Дитер Сиболд; Стивен Реттгер (2012). Анализ протокола автоключа NTP (PDF) . IETF 83.
  89. ^ "nts.time.nl homepage". nts.time.nl . Получено 2021-08-19 .
  90. ^ D. Franke; D. Sibold; K. Teichel; M. Dansarie; R. Sundblad (сентябрь 2020 г.). Безопасность сетевого времени для протокола сетевого времени. Internet Engineering Task Force . doi : 10.17487/RFC8915 . ISSN  2070-1721. RFC 8915. Предлагаемый стандарт.
  91. ^ Лангер, Мартин (2019-12-05). "Настройка NTP с защитой NTS с помощью NTPsec". Weberblog.net . Получено 2021-08-19 .
  92. ^ "Как использовать NTS | Netnod". Netnod . Получено 2021-08-19 .
  93. ^ "Безопасность сетевого времени · Документация по службам времени Cloudflare". developers.cloudflare.com . 5 февраля 2024 г.
  94. ^ "[MS-SNTP]: Расширения аутентификации сетевого протокола времени (NTP). 24 июня 2021 г.
  95. ^ "Сравнение реализаций NTP". chrony.tuxfamily.org . Получено 2019-10-08 .

Дальнейшее чтение

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