Jump to content

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

Протокол сетевого времени
Международный стандарт RFC   5905
Разработано Дэвид Л. Миллс , Харлан Стенн, Network Time Foundation
Представлено 1985 год ; 39 лет назад ( 1985 )

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

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

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

В 1988 году гораздо более полная спецификация протокола NTPv1 и связанных с ним алгоритмов была опубликована в журнале. РФК   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] Несвязанный проект М. Личвара из chrony под названием «NTPv5» был инициирован в 2020 году и включает изменения в безопасности, точности и масштабировании. [27]

Поскольку NTP заменил использование старого протокола времени , некоторые варианты использования, тем не менее, сочли полный протокол слишком сложным. В 1992 году был определен простой протокол сетевого времени ( 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. Число представляет расстояние от эталонных часов и используется для предотвращения циклических зависимостей в иерархии. Stratum не всегда является показателем качества или надежности; Обычно источники времени уровня 3 имеют более высокое качество, чем другие источники времени уровня 2. [а] Краткое описание слоев 0, 1, 2 и 3 представлено ниже.

Слой 0
Это высокоточные устройства измерения времени, такие как атомные часы , ГНСС (в том числе GPS ) или другие радиочасы , либо часы с PTP -синхронизацией. [29] Они генерируют очень точный импульсный сигнал в секунду , который вызывает прерывание и метку времени на подключенном компьютере. Устройства Stratum 0 также известны как эталонные часы. Серверы NTP не могут объявлять себя как уровень 0. Поле уровня, установленное в 0 в пакете NTP, указывает на неопределенный уровень. [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).

Коды общих идентификаторов привязки времени (refid)
Рефид [32] Источник часов
ИДЕТ Спутник окружающей среды на геосинхронной орбите
GPS Глобальная система позиционирования
ГАЛ Галилео Система позиционирования
ППС Общий импульс в секунду
ИРРИГ Группа междиапазонного приборостроения
WWVB LF Radio WWVB Форт-Коллинз, Колорадо 60 кГц
DCF НЧ-радио DCF77 Майнфлинген, Германия 77,5 кГц
ГВГ НЧ-радио HBG Prangins, HB 75 кГц (прекращено)
MSF LF Radio MSF Anthorn, Великобритания 60 кГц
ДЖЖИ НЧ-радио JJY Фукусима, JP 40 кГц, Saga, JP 60 кГц
ЛОРК ПВ Радиостанция Лоран-С , 100 кГц
ИВС СВ Радио Аллуи, Франция 162 кГц
АН КВ Радио CHU Оттава, Онтарио
WWV КВ радио WWV Форт Коллинз, Колорадо
WWVH КВ радио WWVH Кауаи, Гавайи
НИСТ НИСТ Телефонный модем
АКТЫ Телефонный модем НИСТ
УСНО Телефонный модем USNO
ПТБ Телефонный модем немецкого стандарта времени PTB
МИССИС (Неофициально) Многочисленные справочные источники
ГУГ (Неофициально) Google Refid используется серверами Google NTP как time4.google.com

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

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

IANA ведет реестр имен источников и кодов 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] [б]

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

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

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

и двусторонняя задержка δ на где

  • t 0 — временная метка клиента передачи пакета запроса,
  • t 1 — временная метка приема пакета запроса сервером,
  • t 2 — временная метка сервера передачи ответного пакета и
  • t 3 — временная отметка клиента о приеме ответного пакета. [1] : 19 

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

Значения θ и δ пропускаются через фильтры и подвергаются статистическому анализу («смягчение»). Выбросы отбрасываются, а оценка смещения по времени получается на основе трех лучших оставшихся кандидатов. Затем тактовая частота корректируется для постепенного уменьшения смещения («дисциплина»), создавая петлю обратной связи . [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]

ОпенНТПД

[ редактировать ]

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

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]

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

  • Ntimed был запущен Полом-Хеннингом Кампом из FreeBSD в 2014 году и закрыт в 2015 году. [62] Реализация спонсировалась Linux Foundation . [63]
  • systemd-timesyncd — это SNTP-клиент, встроенный в systemd . Он используется Debian начиная с версии «книжный червь». [64] и нижестоящая версия Ubuntu.

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

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

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

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

[ редактировать ]

Сам NTP включает поддержку аутентификации серверов для клиентов. NTPv3 поддерживает режим симметричного ключа , который бесполезен против MITM. Система открытых ключей , известная как «автоключ» в 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. ^ Перейти обратно: а б с д и ж Дэвид Л. Миллс (12 декабря 2010 г.). Синхронизация времени в компьютерной сети: протокол сетевого времени . Тейлор и Фрэнсис. стр. 12–. ISBN  978-0-8493-5805-0 . Архивировано из оригинала 18 июля 2014 года . Проверено 16 октября 2016 г.
  2. ^ Перейти обратно: а б с «Краткое содержание: Синхронизация времени в компьютерной сети» . Архивировано из оригинала 2 ноября 2011 г. Проверено 21 ноября 2011 г.
  3. ^ Перейти обратно: а б с д «Часто задаваемые вопросы по NTP» . Проект НТП. Архивировано из оригинала 06 сентября 2011 г. Проверено 27 августа 2011 г.
  4. ^ «Номера портов» . Управление по присвоению номеров в Интернете (IANA). Архивировано из оригинала 4 июня 2001 г. Проверено 19 января 2011 г.
  5. ^ Перейти обратно: а б с д и ж г Д. Миллс ; Дж. Бербанк; В. Каш (август 2010 г.). Дж. Мартин (ред.). Протокол сетевого времени, версия 4: Спецификация протокола и алгоритмов . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC5905 . ISSN   2070-1721 . РФК 5905 . Предлагаемый стандарт. Устаревшие RFC 1305, 4330. Updated by RFC 7822 , 8573 и 9109 .
  6. ^ Перейти обратно: а б Дэвид Л. Миллс (март 1992 г.). Протокол сетевого времени (версия 3) — спецификация, реализация и анализ . Сетевая рабочая группа. дои : 10.17487/RFC1305 . РФК 1305 . Устаревший. Устарело RFC 5905. Obsoletes RFC 958 , 1059 и 1119 .
  7. ^ Д. Миллс (сентябрь 1985 г.). Протокол сетевого времени (NTP) . Сетевая рабочая группа. дои : 10.17487/RFC0958 . РФК 958 . Устаревший. Устарело RFC 1059 , 1119 и 1305 .
  8. ^ Д. Миллс (июль 1988 г.). Спецификация и реализация протокола сетевого времени (версия 1) . Сетевая рабочая группа. дои : 10.17487/RFC1059 . РФК 1059 . Устаревший. Устарело RFC 1119 и 1305 .
  9. ^ Д. Миллс (сентябрь 1989 г.). Спецификация и реализация протокола сетевого времени (версия 2) . Сетевая рабочая группа. дои : 10.17487/RFC1119 . РФК 1119 . Устаревший. Устарело RFC 1305. Obsoletes RFC 958 и 1059 .
  10. ^ Перейти обратно: а б Д. Миллс (август 1992 г.). Тип службы в наборе протоколов Интернета . Сетевая рабочая группа. дои : 10.17487/RFC1361 . РФК 1361 . Устаревший. Устарело РФК 1769 .
  11. ^ Д. Миллс (март 1995 г.). Простой протокол сетевого времени (SNTP) . Сетевая рабочая группа. дои : 10.17487/RFC1769 . РФК 1769 . Устаревший. Устарело RFC 2030. Obsoletes РФК 1361 .
  12. ^ Перейти обратно: а б Д. Миллс (октябрь 1996 г.). Простой протокол сетевого времени (SNTP) версии 4 для IPv4, IPv6 и OSI . Сетевая рабочая группа. дои : 10.17487/RFC2030 . РФК 2030 . Устаревший. Устарело RFC 4330. Obsoletes РФК 1769 .
  13. ^ Перейти обратно: а б Д. Миллс (январь 2006 г.). Простой протокол сетевого времени (SNTP) версии 4 для IPv4, IPv6 и OSI . Сетевая рабочая группа. дои : 10.17487/RFC4330 . РФК 4330 . Устаревший. Устаревшие RFC 2030 and 1769. Obsoleted by РФК 5905 .
  14. ^ Д.Л. Миллс (апрель 1981 г.). Служба интернет-часов DCNET . IETF . дои : 10.17487/RFC0778 . РФК 778 . Исторический.
  15. ^ Т. Мизрахи; Д. Майер (март 2016 г.). Поля расширения протокола сетевого времени версии 4 (NTPv4) . IETF . дои : 10.17487/RFC7822 . ISSN   2070-1721 . РФК 7822 . Информационный. Обновления РФК 5905 .
  16. ^ Перейти обратно: а б А. Малхотра; С. Гольдберг (июнь 2019 г.). Код аутентификации сообщения для протокола сетевого времени . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC8573 . ISSN   2070-1721 . RFC 8573 . Предлагаемый стандарт. Обновления РФК 5905 .
  17. ^ Ф. Гонт; Г. Гонт; М. Личвар (август 2021 г.). Протокол сетевого времени версии 4: Рандомизация портов . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC9109 . ISSN   2070-1721 . РФК 9109 . Предлагаемый стандарт. Обновления РФК 5905 .
  18. ^ DL Mills (25 февраля 1981 г.), Синхронизация времени в хостах DCNET , заархивировано из оригинала 30 декабря 1996 г.
  19. ^ «TIMED(8)» , Руководство администратора системы UNIX , заархивировано из оригинала 22 июля 2011 г. , получено 12 сентября 2017 г.
  20. ^ Дэвид Л. Миллс (октябрь 1991 г.). «Синхронизация времени в Интернете: протокол сетевого времени» (PDF) . Транзакции IEEE в области коммуникаций . 39 (10): 1482–1493. дои : 10.1109/26.103043 . Архивировано (PDF) из оригинала 10 июня 2016 г. Проверено 6 ноября 2017 г.
  21. ^ Дэвид Л. Миллс (март 1992 г.). Протокол сетевого времени (версия 3) — спецификация, реализация и анализ . Сетевая рабочая группа. дои : 10.17487/RFC1305 . РФК 1305 . Устаревший. Процедура выбора часов была изменена, чтобы удалить первый из двух этапов сортировки/отбрасывания и заменить его алгоритмом, впервые предложенным Марзулло и позже включенным в Цифровую службу времени. Эти изменения не оказывают существенного влияния на обычную работу или совместимость с различными версиями NTP, но они обеспечивают основу для формальных заявлений о корректности.
  22. ^ Дэвид Л. Миллс (15 ноября 2010 г.). Синхронизация времени компьютерной сети: протокол сетевого времени на Земле и в космосе, второе издание . ЦРК Пресс. п. 377. ИСБН  978-1-4398-1464-2 .
  23. ^ Перейти обратно: а б с «Планы на будущее», исследовательский проект синхронизации сетевого времени , заархивировано из оригинала 23 декабря 2014 г. , получено 24 декабря 2014 г.
  24. ^ «НТП нужны деньги: фонд — ответ?» . Информационная неделя . 23 марта 2015. Архивировано из оригинала 10 апреля 2015 года . Проверено 4 апреля 2015 г.
  25. ^ «Судьба NTP зависит от «отца времени» » . Информационная неделя . 11 марта 2015. Архивировано из оригинала 10 апреля 2015 года . Проверено 4 апреля 2015 г.
  26. ^ Перейти обратно: а б «Протоколы сетевого времени (ntp): Документы» . datatracker.ietf.org . Проверено 27 декабря 2022 г.
  27. ^ Личвар, Мирослав (6 декабря 2022 г.). «Протокол сетевого времени версии 5» . www.ietf.org .
  28. ^ Д. Миллс ; Дж. Бербанк; В. Каш (август 2010 г.). Дж. Мартин (ред.). Протокол сетевого времени, версия 4: Спецификация протокола и алгоритмов . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC5905 . ISSN   2070-1721 . РФК 5905 . Предлагаемый стандарт. Первичным серверам и клиентам, соответствующим подмножеству NTP, называемому Simple Network Time Protocol (SNTPv4) [...], не требуется реализовывать алгоритмы смягчения [...] Полностью разработанная реализация NTPv4 предназначена для [.. .] серверы с несколькими вышестоящими серверами и несколькими нижестоящими серверами [...] Помимо этих соображений, серверы и клиенты NTP и SNTP полностью совместимы и могут быть смешаны [...]
  29. ^ «Объединение PTP и NTP, чтобы получить лучшее от обоих миров» . www.redhat.com . Программы из пакета linuxptp можно использовать в сочетании с демоном NTP. Часы PTP на сетевой карте синхронизируются с помощью ptp4l и используются chronyd или ntpd в качестве эталонных часов для синхронизации системных часов.
  30. ^ RFC 5905, стр. 21
  31. ^ «Протокол сетевого времени: информационный документ о передовом опыте» . Архивировано из оригинала 1 октября 2013 года . Проверено 15 октября 2013 г.
  32. ^ Перейти обратно: а б « вывод 'ntpq -p'» . NLUG.ML1.co.uk. Архивировано из оригинала 12 ноября 2018 г. Проверено 12 ноября 2018 г.
  33. ^ «Сообщения о событиях и слова состояния» . docs.ntpsec.org . Коды Refid используются в пакетах «поцелуй смерти» (KoD), поле ссылочного идентификатора на рекламных щитах ntpq и ntpmon и сообщениях журнала.
  34. ^ «Параметры протокола сетевого времени (NTP)» . www.iana.org .
  35. ^ Дэвид Л. Миллс (12 мая 2012 г.). «Эра НТП и нумерация эпох» . Архивировано из оригинала 26 октября 2016 года . Проверено 24 сентября 2016 г.
  36. ^ В. Ричард Стивенс; Билл Феннер; Эндрю М. Рудофф (2004). Сетевое программирование UNIX . Аддисон-Уэсли Профессионал. стр. 582–. ISBN  978-0-13-141155-5 . Архивировано из оригинала 30 марта 2019 г. Проверено 16 октября 2016 г.
  37. ^ «Взгляд на проблемы 2036/2038 года и устойчивость различных систем к времени» . 14 марта 2017 г. Архивировано из оригинала 21 июля 2018 г. Проверено 20 июля 2018 г.
  38. ^ Университета штата Делавэр , 26 апреля 2006 г. Презентация Дэвида Миллса на семинаре по цифровым системам
  39. ^ Гото, Т.; Имамура, К.; Канеко, А. (2002). «Улучшение смещения времени NTP в асимметричной сети с методом двойных пакетов». Сборник конференций Конференция по прецизионным электромагнитным измерениям . Конференция по прецизионным электромагнитным измерениям. стр. 448–449. дои : 10.1109/CPEM.2002.1034915 . ISBN  0-7803-7242-5 .
  40. ^ Перейти обратно: а б Личвар, Мирослав (18 сентября 2018 г.). «хрони – chrony.conf(5)» . Проект Хрони . Проверено 2 августа 2020 г. Эта директива включает аппаратную метку времени для пакетов NTP, отправленных и полученных от указанного сетевого интерфейса.
  41. ^ "sourcestats.c, функция Assessment_asymmetry()" . git.tuxfamily.org (хрони) .
  42. ^ «Пентест-отчет НТП 01.2017» (PDF) . Вылечить53. 2017. Архивировано (PDF) из оригинала 1 декабря 2018 г. Проверено 3 июля 2019 г.
  43. ^ «Технический справочник службы времени Windows» . technet.microsoft.com. 17 августа 2011 г. Архивировано из оригинала 06 сентября 2011 г. Проверено 19 сентября 2011 г.
  44. ^ «Страница службы времени Windows на NTP.org» . Support.NTP.org . 25 февраля 2008 г. Архивировано из оригинала 14 мая 2017 г. Проверено 1 мая 2017 г.
  45. ^ «Как работает служба времени Windows» . technet.microsoft.com. 12 марта 2010 г. Архивировано из оригинала 24 сентября 2011 г. Проверено 19 сентября 2011 г.
  46. ^ Перейти обратно: а б «Граница поддержки для настройки службы времени Windows для сред с высокой точностью» . Майкрософт . 19 октября 2011 г. Архивировано из оригинала 12 января 2009 г. Проверено 10 декабря 2008 г.
  47. ^ Нед Пайл (23 октября 2007 г.). «Требования к высокой точности W32time» . Майкрософт . Архивировано из оригинала 17 октября 2012 г. Проверено 26 августа 2012 г.
  48. ^ «Точное время Windows Server 2016» . technet.microsoft.com . Архивировано из оригинала 2 декабря 2016 г. Проверено 7 декабря 2016 г.
  49. ^ дахавей. «Поддержка границы для высокоточного времени» . docs.microsoft.com . Проверено 24 июля 2021 г.
  50. ^ «ntpd(8) — страницы руководства OpenBSD» . man.openbsd.org . Он реализует простой протокол сетевого времени версии 4, как описано в RFC 5905, и протокол сетевого времени версии 3, как описано в RFC 1305.
  51. ^ Проект OpenBSD (21 августа 2006 г.). «Часто задаваемые вопросы 6.12.1: «Но OpenNTPD не так точен, как демон ntp.org!» " . Проект OpenBSD . Архивировано из оригинала 05 февраля 2016 г. Проверено 14 мая 2020 г.
  52. ^ Раймонд, Эрик С. (30 марта 2017 г.). «NTPsec: безопасная, усиленная реализация NTP | Linux Journal» . Linux-журнал . Архивировано из оригинала 26 января 2024 г. Проверено 26 января 2024 г.
  53. ^ «Распространение протокола безопасного сетевого времени (NTPsec)» . Архивировано из оригинала 13 января 2019 г. Проверено 12 января 2019 г.
  54. ^ Лиска, Аллан (10 декабря 2016 г.). Безопасность NTP: Краткое руководство . Апресс. стр. 80–. ISBN  978-1-4842-2412-0 .
  55. ^ «Пентест-отчет NTPsec 01.2017» (PDF) . Вылечить53. 2017. Архивировано (PDF) из оригинала 4 июля 2019 г. Проверено 3 июля 2019 г.
  56. ^ Личвар, Мирослав (20 июля 2016 г.). «Объединение PTP и NTP, чтобы получить лучшее от обоих миров» . Блог Red Hat Enterprise Linux . Красная шляпа . Архивировано из оригинала 30 июля 2016 года . Проверено 19 ноября 2017 г. . Начиная с Red Hat Enterprise Linux 7.0 (а теперь и в Red Hat Enterprise Linux 6.8) более универсальная реализация NTP также предоставляется через пакет chrony.
  57. ^ «Защита сетевого времени» . Core Infrastructure Initiative, совместный проект Linux Foundation . Инициатива по базовой инфраструктуре. 27 сентября 2017 года. Архивировано из оригинала 28 октября 2017 года . Проверено 19 ноября 2017 г. . В целом, программное обеспечение Chrony NTP заслуживает доверия.
  58. ^ Перейти обратно: а б «хроническое введение» . TuxFamily, некоммерческая организация . хрония. Архивировано из оригинала 9 декабря 2009 года . Проверено 19 ноября 2017 г. . Программное обеспечение поддерживается в Linux, FreeBSD, NetBSD, macOS и Solaris.
  59. ^ Оба, Дэвид. «Управление NTP с помощью Chrony» . Opensource.com . Архивировано из оригинала 29 июня 2019 года . Проверено 29 июня 2019 г.
  60. ^ Хайдерих, Марио (август 2017 г.). «Пентест-отчет 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 . Проверено 31 июля 2021 г.
  62. ^ Пол-Хеннинг, Камп. «20140926 – Опять игра со временем» . Велосипедный сарай PHK . Архивировано из оригинала 20 декабря 2019 года . Проверено 4 июня 2015 г.
  63. ^ Пол-Хеннинг, Камп. «Программное обеспечение синхронизации времени по сети, замена NTPD» . Файл README репозитория ntimed git . Гитхаб. Архивировано из оригинала 2 августа 2015 года . Проверено 4 июня 2015 г.
  64. ^ «Переход с OpenNTPd на Chrony — anarcat» . anarc.at . Таким образом, systemd-timesyncd стал демоном NTP по умолчанию в Debian в «книжном черве», что меня несколько удивляет.
  65. ^ Дэвид Миллс. «Временная шкала NTP и високосные секунды» . Архивировано из оригинала 7 сентября 2013 года . Проверено 15 октября 2013 г.
  66. ^ «Очернение разработчиков Google» . Архивировано из оригинала 4 апреля 2019 года . Проверено 4 апреля 2019 г.
  67. ^ Облеухов Олег (18 марта 2020 г.). «Создание более точной службы времени в масштабах Facebook» . Инженерное дело в Мете .
  68. ^ «chrony – Часто задаваемые вопросы» . chrony.tuxfamily.org .
  69. ^ «Уведомление о безопасности» . Support.NTP.org . 10 декабря 2009 г. Проверено 12 января 2011 г. [ постоянная мертвая ссылка ]
  70. ^ «Уязвимость пакетов сетевого протокола программного обеспечения Cisco IOS» . Сиско Системы . 23 сентября 2009 г. Архивировано из оригинала 11 июня 2020 г. . Проверено 11 июня 2020 г.
  71. ^ «Аудит кода» . Support.NTP.org . 13 июня 2009 г. Проверено 12 января 2011 г.
  72. ^ «Уязвимости протокола сетевого времени (обновление C) | ICS-CERT» . ics-cert.us-cert.gov. Архивировано из оригинала 20 декабря 2014 г. Проверено 15 апреля 2015 г.
  73. ^ Каннингем, Эндрю (23 декабря 2014 г.). «Apple автоматически исправляет компьютеры Mac, чтобы исправить серьезную ошибку безопасности NTP» . арстехника. Архивировано из оригинала 15 апреля 2015 года . Проверено 29 апреля 2015 г.
  74. ^ Фэрхед, Гарри (23 декабря 2014 г.). «NTP — новейшая проблема безопасности с открытым исходным кодом» . Я Программист. Архивировано из оригинала 24 декабря 2014 года . Проверено 24 декабря 2014 г.
  75. ^ Страница NTP SecurityNotice, заархивированная 19 февраля 2014 г. на Wayback Machine.
  76. ^ NVD NIST Поиск продуктов NTP
  77. ^ NVD NIST Поиск продуктов NTPsec. Архивировано 26 июня 2020 г. на Wayback Machine.
  78. ^ Поиск продуктов NVD NIST, Chrony. Архивировано 26 июня 2020 г. на Wayback Machine.
  79. ^ «Аудит CII определяет наиболее безопасную реализацию NTP» . Фонд Linux. 28 сентября 2017 г. Архивировано из оригинала 03 февраля 2018 г. Проверено 3 июля 2019 г.
  80. ^ Перейти обратно: а б Протокол сетевого времени версии 4: Спецификация автоматического ключа . IETF. Июнь 2010 г. doi : 10.17487/RFC5906 . РФК 5906 .
  81. ^ Перейти обратно: а б «Анализ безопасности NTP» . Архивировано из оригинала 7 сентября 2013 года . Проверено 11 октября 2013 г.
  82. ^ Хосе Сельви (16 октября 2014 г.). «Обход строгой транспортной безопасности HTTP» (PDF) . Архивировано из оригинала (PDF) 18 октября 2014 г. Проверено 16 октября 2014 г.
  83. ^ Анчал Малхотра; Исаак Э. Коэн; Эрик Бракке и Шэрон Голдберг (20 октября 2015 г.). «Атака на протокол сетевого времени» (PDF) . НДСС . Архивировано из оригинала (PDF) 22 октября 2015 года . Проверено 27 октября 2015 г.
  84. ^ «Атака на протокол сетевого времени» . www.cs.bu.edu . Архивировано из оригинала 24 октября 2015 г. Проверено 27 октября 2015 г.
  85. ^ Гудин, Дэн (13 января 2014 г.). «Новые DoS-атаки, уничтожающие игровые сайты, приводят к разрушительным наводнениям со скоростью 100 Гбит/с» . Арс Техника . Архивировано из оригинала 24 января 2014 г. Проверено 25 января 2014 г.
  86. ^ Ли, Дэйв (11 февраля 2014 г.). «Огромный взлом «уродливого знака будущего» для интернет-угроз» . Би-би-си. Архивировано из оригинала 11 февраля 2014 г. Проверено 12 февраля 2014 г.
  87. ^ «DRDoS/Атака с усилением с использованием команды ntpdc monlist» . support.NTP.org . 24 апреля 2010 г. Архивировано из оригинала 30 марта 2014 г. Проверено 13 апреля 2014 г.
  88. ^ Дитер Сибольд; Стивен Реттгер (2012). Анализ протокола автоключа NTP (PDF) . IETF 83.
  89. ^ «Домашняя страница nts.time.nl» . nts.time.nl. ​Проверено 19 августа 2021 г.
  90. ^ Д. Франке; Д. Сиболд; К. Тейхель; М. Дансари; Р. Сундблад (сентябрь 2020 г.). Безопасность сетевого времени для протокола сетевого времени . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC8915 . ISSN   2070-1721 . РФК 8915 . Предлагаемый стандарт.
  91. ^ Лангер, Мартин (05 декабря 2019 г.). «Настройка NTP, защищенного NTS, с помощью NTPsec» . Веберблог.нет . Проверено 19 августа 2021 г.
  92. ^ «Как пользоваться НТС | Netnod» . Нетнод . Проверено 19 августа 2021 г.
  93. ^ «Безопасность сетевого времени · Документация по службам времени Cloudflare» . Developers.cloudflare.com . 5 февраля 2024 г.
  94. ^ «[MS-SNTP]: расширения аутентификации протокола сетевого времени (NTP)» . 24 июня 2021 г.
  95. ^ «Сравнение реализаций NTP» . chrony.tuxfamily.org . Проверено 8 октября 2019 г.

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

[ редактировать ]
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: a7a5ddeb5be45989b6017babcbcacacc__1721661660
URL1:https://arc.ask3.ru/arc/aa/a7/cc/a7a5ddeb5be45989b6017babcbcacacc.html
Заголовок, (Title) документа по адресу, URL1:
Network Time Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)