Разное

Ntp сервер порт: (NTP, SNTP, DAYTIME, TIME)

28.02.2000

Содержание

Сервер NTP-GPS Atomic Clock | Galleon Systems Ltd

NTP-сервер-GPS Atomic Clock Сервер времени получают точное время от глобальной системы позиционирования (GPS), чтобы обеспечить по-настоящему глобальным решением для компьютера синхронизации времени.

Связаться с Galleon для получения дополнительной информации

Особенности

  • Высокая точность исходный компьютер сроки.
  • Дисплей показывает число спутников синхронизированы и времени UTC
  • Драйверы для Windows, 95, 98, NT, 2000, XP и 2003 и Linux, UNIX и Solaris.
  • До 1,000 метров (3,000ft) максимальная длина кабеля.
  • Водонепроницаемый, джем устойчивые активные GPS антенны.
  • Простота установки и настройки.
  • Требуется один последовательный порт RS232.
  • USB вариант.

Преимущества

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

Обзор

GPS сетевой сервер времени Atomic Clock получает точную информацию о времени от системы GPS. Точная информация сроки передается в компьютер через одну RS232 последовательный порт. Сервер-GPS Clock обеспечивает точную синхронизацию времени в любой точке мира.

Помехоустойчивости GPS-антенны

Сервер-GPS часы снабжены стационарными, монтируемые на крыше GPS антенны. Антенна расположена в водонепроницаемом упаковки разработаны, чтобы противостоять воздействию ударов и вибрации.

Программное обеспечение Драйвера

Программные драйверы доступны для большинства операционных систем, включая Windows, 95, 98, Me, NT, 2000, XP и 2003, а также Linux, Unix и Solaris, а также драйверы для Novell Netware. Network Time Protocol (NTP) драйверов для Windows NT, 2000, XP и сервера 2003 для обеспечения синхронизации времени в сети. Linux, Unix, Solaris или драйверы предоставляются как часы NTP ссылки драйвер для стандартного дистрибутива NTP.

World-Wide операции

Сервер-GPS Clockuses глобальной системы позиционирования для получения точной информации о времени в любой точке планеты. Galleon поставляет на сервере GPS-часы с универсальным 12V питания, которые могут работать в Великобритании, США, Европе, Австралии и многих других стран.

GPS-сервер GPS-часы времени приемника Спецификация

Тип приемника: 12 канала Быстрое приобретение GPS-приемник
Точность синхронизации 100 наносекунд (0.0000001 сек)
Размеры приемника 125 78 х х 43 мм
Электропитание 12 VDC 80mA ок.
Состояние светодиодов Импульс в секунду и власть

Драйверы

Программные драйверы доступны для всех ОС Windows и операционные системы UNIX.

Для получения полного списка всех наших продуктов синхронизации времени см. наш Время сервера страница

【Введение в протокол NTP】 — Русские Блоги

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

В мире компьютеров время очень важно: например, для таких научных исследований, как запуск ракет, требования к единообразию и точности времени очень высоки, независимо от того, соответствует ли оно времени компьютера A или B. время? NTP используется для решения этой проблемы NTP (сетевой протокол времени) — это протокол, используемый для синхронизации времени каждого компьютера в сети. Его цель — синхронизировать часы компьютера с UTC, его точность может достигать 0,1 мс в локальной сети, а точность может достигать 1-50 мс в большинстве мест в Интернете.

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



 

NTP (сетевой протокол времени, сетевой протокол времени) — это протокол синхронизации времени, определенный в RFC 1305. Он используется для синхронизации времени между сервером распределенного времени и клиентом. NTP использует теплоизоляцию UDP для передачи и использует порт UDP номер 123.

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

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

 

Режим работы NTP

Устройство может принять несколько режимов работы NTP для синхронизации времени:

Режим клиент / сервер

Peer Mode

Режим вещания

Многоадресный режим

 

Принцип нтп

NTP-клиент может автоматически отправлять запрос на NTP-сервер для получения времени, а NTP-сервер отправляет время клиенту.

Есть два источника времени для NTP-сервера

1. Сетевое время

2. NTP сервер собственного времени

 

Принцип синхронизации NTP:

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

Передача информации о времени использует протокол UDP. Сервисный порт 123.



 

 

В системе Linux, чтобы избежать отклонения во времени, вызванного длительным временем работы хоста, очень необходимо выполнять синхронизацию времени (синхронизацию). В системе Linux служба ntp обычно используется для синхронизации времени разных машин. NTP — это сокращение от Network Time Protocol, зачем его использовать? Это для синхронизации времени между компьютерами через сетевые протоколы.

NTP — это… Что такое NTP?

NTP
Название:

Network Time Protocol

Уровень (по модели OSI):

Прикладной

Семейство:

TCP/IP

Порт/ID:

123/UDP

Назначение протокола:

Синхронизация часов

Спецификация:

RFC 5905

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

NTP использует для своей работы протокол UDP. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи.

NTP использует алгоритм Марзулло (предложен Кейтом Марзулло (Keith Marzullo) из Университета Калифорнии, Сан-Диего), включая такую особенность, как учёт времени передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет, и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей.

NTP — один из старейших используемых протоколов. NTP разработан Дэвидом Л. Миллсом (David L. Mills) из университета Дэлавера в 1985 году и в настоящее время продолжает совершенствоваться. Текущая версия — NTP 4.

NTP использует иерархическую систему «часовых уровней» (stratum). Уровень 1 синхронизирован с высокоточными часами, например, с системой GPS, ГЛОНАСС (Единая Государственная шкала времени РФ) или атомным эталоном времени. Уровень 2 синхронизируется с одной из машин уровня 1, и так далее.

Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 232 секунд, с теоретической точностью 2−32 секунды. Поскольку шкала времени в NTP повторяется каждые 232 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 50 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учётом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.

Наиболее широкое применение протокол NTP находит для реализации серверов точного времени. Для достижения максимальной точности предпочтительна постоянная работа программного обеспечения NTP в режиме системной службы. В семействе операционных систем Microsoft Windows, — это служба W32Time (модуль w32time.dll, выполняющийся в svchost.exe), Linux — сервис Ntpd.

Более простая реализация этого алгоритма известна как SNTP — простой синхронизирующий сетевой протокол. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени.

Подробная реализация протокола и системы в целом описана в:

NTP не следует путать с daytime protocol RFC 867 или time protocol RFC 868 (win программа FG Time Sync).

Часовые слои

Желтые стрелки обозначают аппаратное соединение; красные стрелки обозначают сетевое соединение.

NTP использует иерархическую, многоуровневую систему источников времени. Каждый уровень этой иерархии называется слоем, каждому слою присваивается номер, начиная с 0 (ноль) в верхней части. Уровень слоя определяет расстояние от эталонных часов и существует, чтобы предотвратить циклические зависимости в иерархии. Важно отметить, что слой не является показателем качества и надежности, это значит, что источник слоя 3 может дать сигнал более высокого качества, чем некоторые источники слоя 2. В основном, слои служат для распределения нагрузки и обеспечения большей площади покрытия. Это определение слоя также отличается от понятия часовых слоёв, используемых в телекоммуникационных системах.

Слой 0

Слой 0 — это высокоточные приборы служащие эталоном времени, такие как атомные (молекулярные, квантовые) часы, радиочасы или их аналоги. Обычно эти устройства не подключены к сети; вместо этого они подключены к локальному компьютеру (например, через интерфейс RS-232) и передают сигналы PPS для синхронизации.

Слой 1

Это компьютер, к которому напрямую подключены эталонные часы. Он выступает в качестве сетевого сервера времени и отвечает на NTP-запросы посылаемые компьютерами слоя 2.

Слой 2

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


Слой 3

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

См. также

Ссылки

  • ВНИИФТРИ — национальный метрологический институт России — список серверов NTP Государственного эталона времени и частоты (ГЭВЧ) Российской Федерации
  • Network Time Protocol project — общественный проект по развитию протокола и служб NTP
  • NTP Public Services Project — проект публичных серверов NTP и рабочей группы IETF по протоколу NTP
  • pool.ntp.org — ресурс, представляющий большой виртуальный кластер NTP-серверов для миллионов пользователей. По состоянию на 29 декабря 2010 в pool.ntp.org зарегистрированно 2078 серверов. Есть возможность выбрать региональные сервера.
  • ntp.mobatime.ru — с 2005 года публичный бесплатный NTP-сервер Mobatime первого стратума (Россия, Санкт-Петербург).
  • time.bakulev.ru — публичный бесплатный NTP сервер первого стратума (Россия, Москва).

Ntp протокол. Смотреть что такое «NTP» в других словарях. Как это работает

Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная , ограничено параметром ntp .maxstratum .

Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll ). Это целая переменная со знаком, которая указывает минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды.

Точность (sys.precision, peer.precision, pkt.precision ). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлена в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс).

Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay ). Это число с фиксированной запятой со знаком, которое указывает на величину полной циклической задержки ( RTT ) до первичного эталона частоты, выраженной в секундах.

Базовая дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion ). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах.

Идентификатор эталонных часов (sys.refid, peer.refid, pkt.refid ). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), это 4-октетная ASCII -строка, выровненная по левому краю и дополненная при необходимости нулями, например:

Таблица 7.4. Коды идентификаторов часов
Слой Код Значение
0 dcn Протокол маршрутизации dcn
0 dts Цифровая служба времени (digital time service)
0 nist Общий модем nist
0 tsp Временной протокол tsp
1 atom Атомные часы (калиброванные)
1 vlf vlf -радио (omega, и пр.)
1 callsign Общее радио
1 gps gps УВЧ позиционирование спутников
1 lorc loran-c радионавигация
1 wwvb Радио wwvb НЧ (диапазон 5)
1 goes Спутник goes УВЧ (диапазон 9)
1 wwv Радио wwv ВЧ (диапазон 7)

В случае слоя 2 и выше (вторичный эталон) — это 4-октетный IP — адрес партнера, выбранного для синхронизации.

Эталонная временная метка (sys.reftime, peer.reftime, pkt.reftime ) — локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль.

Базовая временная метка (peer.org, pkt.org ) — локальное время в формате временных меток, соответствующее моменту посылки последнего NTP -сообщения. Если партнер недостижим, переменная принимает нулевое значение .

Временная метка получения (peer.rec, pkt.rec ) — локальное время в формате временных меток, которое соответствуюет моменту прихода последнего NTP -сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение .

Временная метка передачи (peer.xmt, pkt.xmt ) — локальное время в формате временных меток, соответствующее моменту отправки NTP -сообщения.

Системные переменные

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

Переменная локальные часы (sys.clock ) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями.

Переменная Базовые часы (sys.peer ) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.

Переменные партнера

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

Бит конфигурации (peer.config ) — бит , индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен.

Временная метка актуализации (peer.update ) — локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига.

Регистр достижимости (peer.reach ) — сдвиговый регистр битов ntp .window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.

Таймер партнера (peer.timer ) — целочисленный счетчик , используемый для управления интервалом между последовательно посылаемыми NTP -сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек), пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов.

Пакетные переменные

Номер версии (pkt.version ) — целое число , индицирующее номер версии отправителя. NTP -сообщения всегда посылаются с текущим значением версии ntp .version и будут восприняты лишь при условии совпадения кодов версии ( ntp .version ). Исключения допускаются лишь при смене номера версии.

Переменные фильтра часов

Когда используются фильтры и алгоритмы отбора, дополнительно привлекаются следующие переменные состояния .

Регистр фильтра (peer.filter ) — сдвиговый регистр каскадов ntp . shift , где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются.

Счетчик корректных данных (peer.valid ) — целочисленный счетчик , указывающий на корректные образцы, остающиеся в регистре фильтра. Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений.

Смещение (peer.offset ) — число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.

Задержка (peer.delay ) — число с фиксированной запятой со знаком, индицирующее полную циклическую задержку ( RTT ) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения.

Дисперсия (peer. dispersion ) — число с фиксированной запятой , индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля.

Параметры

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

Номер версии ( ntp .version ) — текущий номер версии NTP (3).

Порт NTP ( ntp .port ) — стандартный номер порта (123), присвоенный протоколу NTP .

Максимальный номер слоя ( ntp .maxstratum ) — максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).

Максимальный возраст часов ( ntp .maxage ) — максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться как корректные после последней сверки.

Максимальный сбой ( ntp .maxskew ) — максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp .maxage, в секундах. Отношение ntp .maxskew к ntp .maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.

Максимальное расстояние ( ntp .maxdistance ) — максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.

Минимальный период рассылки ( ntp .minpoll ) — минимальный период рассылки, допустимый для любого из партнеров в сети Интернет . Этот период выражается в секундах и представляет собой степень 2.

Максимальный период рассылки ( ntp .maxpoll ) — максимальный период рассылки, допустимый для любого из партнеров в сети Интернет . Этот период выражается в секундах и представляет собой степень 2.

Минимум избранных часов ( ntp .minclock ) — минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).

Максимум избранных часов> ( ntp .maxclock ) — максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).

Минимальная дисперсия ( ntp .mindisperse ) — минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).

Максимальная дисперсия ( ntp .maxdisperse ) — максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).

Размер регистра доступности ( ntp .window ) — размер регистра доступности (peer.reach ) в битах.

Размер фильтра ( ntp .shift ) — размер сдвигового регистра фильтра часов (peer.filter ) в каскадах.

Вес фильтра ( ntp .filter ) — и широковещательный :

Симметрично активный (1) . ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

Симметрично пассивный (2) . Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое, ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

сервер времени, который работает в широковещательной среде) оповещает о намерении синхронизовать всех партнеров.

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

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

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

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

Обработка событий

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

NTP (Network Time Protocol — протокол сетевого времени) — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью. Протокол был разработан Дэвидом Л. Миллсом, профессором Делавэрского университета, в 1985 году. Версия на 2015 год — NTPv4.

NTP, основанный на алгоритме Марзулло, использует для своей работы протокол UDP и учитывает время передачи. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет, и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей.

Наиболее широкое применение протокол NTP находит для синхронизации серверов точного времени. Для достижения максимальной точности предпочтительна постоянная работа программного обеспечения NTP в режиме системной службы. В семействе операционных систем Microsoft Windows — это служба W32Time, Linux — сервис Ntpd.

Более простая реализация этого алгоритма известна как SNTP — простой протокол сетевого времени. Используется во встраиваемых системах и устройствах, не требующих высокой точности, а также в пользовательских программах точного времени.

Структура пакета

Структура пакета описана в RFC 5905. Пакет состоит из целого числа 32-битных слов.

Данные в заголовке будут отличаться для различных режимов работы. Например, клиент в поля часовой слой , идентификатор источника , начальное время и время приёма должен записать нули.

Заголовок

Заголовок NTP
Отступ Октет 0 1 2 3
Октет Бит 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 ИК Версия Режим Часовой слой Интервал опроса Точность
4 32 Задержка
8 64 Дисперсия
12 96 Идентификатор источника
16 128 Время обновления
20 160
24 192 Начальное время
28 224
32 256 Время приёма
36 288
40 320 Время отправки
44 352
Индикатор коррекции

Пример синхронизации времени, используя NTP

Длина — 2 бита, от Leap Indicator. Целое число, показывающее предупреждение о секунде координации.

Номер версии
Длина — 3 бита, от Version Number. Целое число, представляющее версию протокола.
Режим
Длина — 3 бита, от Mode. Целое число, представляющее режим. Значения представлены в таблице ниже.
Часовой слой
Длина — 8 бит, от Stratum. Целое число, представляющее часовой слой.
Интервал опроса
Длина — 8 бит, от Poll. Целое число со знаком, представляющее максимальный интервал между последовательными сообщениями. Значение равно двоичному логарифму секунд. Предлагаемые по умолчанию пределы на минимальные и максимальные опросы — 6 и 10, соответственно.
Точность
Длина — 8 бит, от Precision. Целое число со знаком, представляющее точность системных часов. Значение равно двоичному логарифму секунд. Например, значению -18 будет соответствовать точность около 1 мкс.
Задержка
Длина — 32 бита, от Root Delay. Общее время распространения сигнала в обе стороны в коротком формате NTP.
Дисперсия
Длина — 32 бита, от Root Dispersion. Общая дисперсия для источника времени в коротком формате NTP.
Идентификатор источника
Длина — 32 бита, от Reference ID. Код источника синхронизации. Зависит от значения в поле Часовой слой. Для слоя 0 — это четыре ASCII символа, называемые «kiss code», используются для отладки и мониторинга. Смотри ниже Для слоя 1 — это четыре октета ASCII символов, дополненные слева нулями, назначенные для опорного времени. В таблице ниже представлен список, поддерживаемый IANA.
ID Источник
GOES Геостационарный спутник системы экологического мониторинга и наблюдения
GPS Система глобального позиционирования
GAL Система местоопределения «Галилео»
PPS Общий радиосигнал с длительностью импульса, равной 1 секунде
IRIG Группа стандартизации в телеметрии, США
WWVB Низкочастотный радиопередатчик, 60 кГц, Форт Коллинз, Колорадо, США
DCF Низкочастотный радиопередатчик, 77.5 кГц, DCF77, Майнфлинген, ФРГ
HBG Низкочастотный радиопередатчик, 75 кГц, Прангинс, Швейцария
MSF Низкочастотный радиопередатчик, 60 кГц, Антхорн, Великобритания
JJY Низкочастотный радиопередатчик, 40 кГц, Фукушима, 60 кГц, Сага, Япония
LORC Среднечастотный радиопередатчик, 100 кГц, радионавигация, LORAN-C
TDF Среднечастотный радиопередатчик, 162 кГц, Аллоуис, Франция
CHU Высокочастотный радиопередатчик, Оттава, Онтарио, Канада
WWV Высокочастотный радиопередатчик, Форт Коллинз, Колорадо, США
WWVH Высокочастотный радиопередатчик, Кауаи, Гавайи, США
NIST
ACTS Телефонный модем Национального института стандартов и технологий США
USNO Телефонный модем Национальной обсерватории США
PTB Телефонный модем Национального метрологического института Германии
Для слоя 2 и выше — это идентификатор сервера и может быть использован для фиксирования временных петель. Если используется IPv4, то идентификатор представляет из себя четыре октета IP адреса. Если используется IPv6, то это первые четыре октета MD5 хэша адреса. Стоит отметить, что при использовании IPv6 адресов для сервере с NTPv4 и клиента с NTPv3 идентификатор может принимать случайное значение, из-за чего временные петли могут быть не зафиксированы.
Время обновления
Длина — 64 бита, от Reference Timestamp. Время, когда система последний раз устанавливала или корректировала время. Формат NTP.
Начальное время
Длина — 64 бита, от Origin Timestamp. Время клиента, когда запрос отправляется серверу. Формат NTP.
Время приёма
Длина — 64 бита, от Receive Timestamp. Время сервера, когда запрос приходит от клиента. Формат NTP.
Время отправки
Длина — 64 бита, от Transmit Timestamp. Время сервера, когда запрос отправляется клиенту. Формат NTP.

NTP-сообщение «Kiss-o»-Death»

Для слоя 0 , который считается неопределённым или недопустимым, поле Идентификатор источника может использоваться для доставки сообщений, которые выполняют роль данных о состоянии системы и управления доступом. Такие сообщения называются «Kiss-o»-Death» (KoD), а доставляемые ими ASCII-данные называются «kiss codes» (коды «помощи»). Перечень принятых в настоящее время кодов «помощи» представлен в таблице ниже.

Получатели KoD-сообщений обязаны их проверить и выполнить следующие действия:

  • При получении кодовых комбинаций DENY и RSTR клиент обязан разорвать виртуальные соединения с данным сервером времени и прекратить передачу сообщений этому серверу.
  • При получении кодовой комбинации RATE клиент обязан незамедлительно снизить свой интервал опроса этого сервера и продолжать его уменьшать каждый раз при получении этой кодовой комбинации.
  • При получении кодовой комбинации начинающейся с ASCII-символа Х , предназначенной для проведения экспериментальных исследований и последующих усовершенствований, она должна быть проигнорирована, если она не распознаётся.
  • Все другие кодовые комбинации и KoD-сообщения, не определённые данным протоколом, уничтожаются после их поверки.
Коды «помощи»
Код Описание
ACST Виртуальное соединение установлено одноадресным сервером
AUTH Аутентификация сервером завершилась отказом
AUTO Autokey-последовательность некорректна
BCST Виртуальное соединение установлено широковещательным сервером
CRYP Криптографическая аутентификация или идентификация завершились отказом
DENY Удалённый сервер отказал в доступе
DROP Потеря удаленного сервера времени в симметричном режиме
RSTR Отказ в доступе вследствие локальной стратегии безопасности
INIT Виртуальное соединение с первого раза не установлено
MCST Виртуальное синхросоединение установлено динамически обнаруженным сервером
NKEY Ключ не найден (либо он никогда ранее не загружался, либо он является ненадёжным)
RATE Скорость превышена. Сервер временно запретил доступ, так как клиент превысил порог скорости
RMOT Изменение виртуального соединения со стороны удалённого IP-узла, использующего NTP-протокол напрямую
STEP Произошла итерация по изменению системного времени, виртуальное синхросоединение не установлено

Часовые слои

Жёлтые стрелки обозначают аппаратное соединение; красные стрелки обозначают сетевое соединение.

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

Формат времени

Время представляется в системе NTP 64-битным числом (8 байт), состоящим из 32-битного счётчика секунд и 32-битного счётчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 −32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учётом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.

Обычный формат времени
Бит 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Секунды
4 Доли секунд
Формат даты
Бит 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Номер эры
4 Отступ эры
8 Доли
16

Network Time Protocol — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью, основанных на коммутации пакетов.

Хотя традиционно NTP использует для своей работы протокол UDP, он также способен работать и поверх TCP. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи.

Время, представляется в системе NTP 64-битным числом, состоящим из 32-битного счетчика секунд и 32-битного счетчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 -32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учетом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.

Как это работает

NTP-серверы работают в иерархической сети, каждый уровень иерархии называется ярусом (stratum). Ярус 0 представлен эталонными часами. За эталон берется сигнал GPS (Global Positioning System) или службы ACTS (Automated Computer Time Service). На нулевом ярусе NTP-серверы не работают.

NTP-серверы яруса 1 получают данные о времени от эталонных часов. NTP-серверы яруса 2 синхронизируются с серверами яруса 1. Всего может быть до 15 ярусов.

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

Иерархическая структура протокола NTP является отказоустойчивой и избыточной. Рассмотрим пример его работы. Два NTP-сервера яруса 2 синхронизируются с шестью различными серверами яруса 1, каждый — по независимому каналу. Внутренние узлы синхронизируются с внутренними NTP-серверами. Два NTP-сервера яруса 2 координируют время друг с другом. В случае отказа линии связи с сервером яруса 1 или с одним из серверов уровня 2 избыточный сервер уровня 2 берет на себя процесс синхронизации.

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

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

Ответы на вопросы

26.09.2018

Сложно представить современный мир без точного времени. Во многих сферах жизни нужно иметь очень точные часы, при этом точность часто должна быть гораздо выше точности часов, применяющихся людьми в обычной жизни. Например, требования к точности часов авиационных диспетчерских, комплексов, управляющих космическими аппаратами, или военных систем находятся на высочайшем уровне. Также часы с высокой точностью необходимы и в системах с более простыми функциями – в системах биллинга и тарификации сотовых операторов и интернет-провайдеров, в системах банковских транзакций, в биржевых системах, в производственных и научных комплексах. В локальных сетях протокол аутентификации пользователей Kerberos также использует сравнение времени контроллера домена с часами пользовательских рабочих станций. В компьютерных сетях синхронизация обычно выполняется с серверами точного времени при помощи протокола NTP или его «облегчённой» разновидности – SNTP . В этой статье мы рассмотрим особенности, отличия и примеры применения этих протоколов.

NTP (англ. Network Time Protocol – протокол сетевого времени) – сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной пропускной способностью. Обеспечивает высокую точность синхронизации времени благодаря специальному алгоритму, который позволяет выбирать наиболее точные источники для оценки точного времени. Этот алгоритм позволяет сводить к минимуму влияние данных от заведомо некорректно настроенных NTP-серверов на общую систему. Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд, и содержит средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию. Протокол NTP использует иерархическую систему уровней, или стратумов. Сервер NTP имеет наиболее высокий уровень (стратум 1), если он получает данные непосредственно от источника точного времени. Сервера, синхронизирующие свои часы с сервером 1-го стратума, находятся на уровне ниже (стратум 2), и т. д.

SNTP (англ. Simple Network Time Protocol – простой протокол сетевого времени) – протокол синхронизации времени по компьютерной сети. Представляет собой упрощённую реализацию протокола NTP, в нём отсутствует сложность алгоритма NTP. SNTP используется для узлов сети, которым не требуется полный набор функций NTP. Общепринятой практикой является синхронизация часов нескольких узлов локальной сети с другими узлами NTP по Интернет и использование этих узлов для временной синхронизации услуг, предоставляемых другим клиентам по локальной сети. В таком варианте использования не требуется высокой точности временной синхронизации. Протокол SNTP обеспечивает механизмы синхронизации с точностью от 1 до 50 мс

Пример использования протокола NTP: банк N предоставляет своим клиентам клиент-серверное приложение для биржевой торговли. Сервера, которые обрабатывают информацию о биржевых котировках, должны иметь часы с высокой точностью синхронизации со шкалой всемирного времени. В таком случае, каждый сервер биржевой торговли банка N синхронизируется с самым точным из серверов точного времени («стратум 1»), который получает данные непосредственно от источника точного времени. Самый точный сервер выбирается по алгоритму, встроенному в протокол NTP. Примерная архитектура такого решения отражена на схеме ниже:

Классический пример использования SNTP – синхронизация времени внутри домена. Контроллер домена получает время из глобальной сети Интернет от общедоступных серверов стратума 1 или стратума 2. Остальные клиенты домена синхронизируют свои часы со временем на контроллере домена. Примерная архитектура отображена на схеме.

Задача узнать точное время с некоторых пор стоит не только перед человеком. Множеству систем, созданных им, для правильного функционирования необходимо постоянно иметь в своём распоряжении очень точные часы, причём их точность должна быть значительно выше часов, используемых людьми в обычной жизни. Помимо собственно точности часов, не менее важной является их синхронизация со шкалой всемирного времени. Ведь даже в шкалу UTC (всемирное координированное время, является основой гражданского времени) периодически вносятся изменения в виде дополнительной секунды из-за расхождений с атомным временем (например, во времена, когда нашу планету населяли ещё первые динозавры, продолжительность суток была около 22 часов).

В качестве ярких примеров систем, использующих очень точные и надёжные методы вычисления текущего времени, вовсе необязательно представлять себе комплексы, управляющие движением космических аппаратов или авиационных диспетчерских служб – хотя, безусловно, требования к точности часов всех элементов подобных систем находятся на высочайшем уровне. Стабильные и синхронизированные со всемирным временем часы нужны и в системах, выполняющих более простые задачи. К ним, например, можно отнести научные и производственные комплексы, осуществляющие обработку данных в режиме реального времени различными устройствами. Добавьте ещё всё, что связано с финансами – это проведение банковских транзакций, системы биллинга операторов сотовой связи и Интернет-провайдеров, осуществляющие тарификацию обслуживаемого ими трафика. Всё это – примеры систем, реализация которых невозможна без использования часов, синхронизированных и согласованных с универсальным временем. В вычислительных сетях протокол аутентификации клиентов также использует сравнение времени сервера с часами клиентов.

Развитие коммуникаций в наше время значительно упростило задачу получения точного времени. Сейчас у нас «над головой» (точнее, на орбитах вокруг Земли) находится несколько десятков спутников систем глобального позиционирования, бортовые часы которых практически являются эталонами времени. Сигналы, посылаемые ими, могут использоваться для очень точной синхронизации часов. В вычислительных сетях синхронизация обычно выполняется с серверами точного времени при помощи протокола NTP (Network Time Protocol) или его «облегчённой» разновидности — SNTP (Simple Network Time Protocol) в тех случаях, когда максимальная функциональность применения полного NTP не является необходимой.

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

В общих чертах работает SNTP-протокол довольно просто и обычно происходит в три этапа:

  • Клиент, которому необходимо получить время, отправляет UDP-пакет, содержащий SNTP-запрос на общепринятый порт 123 NTP-сервера, и переходит в режим ожидания ответа. В этом запросе он проставляет метку времени собственных часов.
  • При получении запроса сервер отвечает UDP-пакетом, содержащим SNTP-сообщение, отправляя его клиенту с 123 порта. В пакете записывается полученная метка времени клиента и метка времени самого сервера.
  • При получении ответа клиент может использовать отметку времени, созданную им самим при отправке запроса, для подтверждения правильности ответа, пытаясь убедиться, что он отправлен именно на запрос этого клиента (если пакет отправлен на запрос из другого источника, вероятность того, что он содержит такую же отметку времени создания, крайне низка). Затем он извлекает значение отметки времени передачи, преобразуя его в соответствии с предполагаемым временем задержки, вызванной прохождением пакета по сети, и использует результат для установки времени своих системных часов.

Форматы пакетов для обоих протоколов одинаковы, что позволяет NTP-серверу работать как с клиентами NTP, так и с клиентами SNTP.

Структура кадра NTP

Сервера NTP, как правило, имеют лишь один открытый «наружу» порт – UDP 123. В такой конфигурации администратору не приходится особо заботиться о безопасности сервера, поскольку он практически неуязвим для атак злонамеренных программ. Тем не менее, очень важно обеспечить доступность сервера 1-го стратума для клиентов, ведь иначе теряется сам смысл его эксплуатации. Основной проблемой становится количество запросов, которые в состоянии обслужить NTP-сервер. Впрочем, и сами запросы могут генерироваться по весьма любопытным причинам.

Наиболее известные случаи NTP-вандализма

В середине мая 2003 года сотрудники университета Мэдисона обнаружили стремительно возросший Интернет-трафик, который был направлен на публичные NTP-сервера университета. Трафик представлял собой запросы протокола NTP, состоящие из пакетов в 76 байт, передаваемых на 123 порт UDP. Однако эти пакеты имели необычное свойство: несмотря на то, что они исходили из различных источников, все они были отправлены с порта номер 23457.

Для защиты серверов была изменена конфигурация роутеров, блокировавшая только эту часть входящих запросов к NTP-серверам, обычные запросы продолжали нормально обслуживаться. Был заблокирован лишь весь UDP-трафик, содержащий запросы к NTP-серверу, отправленные с порта 23457 на порт 123. В тот момент персонал просто подумал, что столкнулся с атакой типа «распределённый отказ в обслуживании» (DDoS-атака , от англ. Distributed Denial of Service, отказ в обслуживании), организованной с множества случайных адресов, и остановился на этом, предполагая, что флуд затихнет в течение нескольких часов, как это обычно и бывает в случае атак низкого профессионального уровня.

Месяц спустя выяснилось, что поток входящего NTP-трафика значительно увеличился, достигнув огромных значений — 250 тысяч пакетов в секунду, с объёмом свыше 150 МБит/с. Аккуратно отменяя блокирование доступа для некоторых интерфейсов, персонал начал изучать UDP-пакеты, включая их содержимое. Они выглядели правильными запросами формата SNTP версии 1, хотя их высокая интенсивность с каждого хоста была непонятна. Например, в течение одного периода отслеживания, множество клиентов производило примерно один запрос в секунду. Это было бы крайне странным для нормально функционирующего SNTP-клиента. Приложения, использующие SNTP, лишь устанавливают собственные системные часы с необходимой точностью, так, чтобы хост имел некое достаточное представление о текущем времени.

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

Ни один из источников запросов не находился в локальной сети комплекса зданий университета. Это означало, что для расследования причин инцидента потребуется помощь администраторов удалённых серверов. Из наиболее активных IP-адресов были выбраны два клиента, расположенных в сетях других университетах. Сетевым администраторам отослали письмо с описанием проблемы и просьбой выяснить, какие ОС и SNTP-клиенты могут быть запущены на этих хостах, и какие службы могут отправлять с них запросы, используя 23457 порт UDP.

Полученные ответы содержали сведения о том, что источником трафика являлись роутеры производства Netgear (в частности, один из них был идентифицирован как модель MR814). Теперь события начали приобретать некий смысл. Большое количество хостов, использующих один и тот же порт, могло быть объяснено встроенным SNTP-клиентом с запрограммированным номером порта. Сотрудники университета Мэдисона стали собирать информацию о продуктах Netgear, в которых была заявлена поддержка NTP. После исследования кода выяснилось, что в некоторые из них производитель просто программно «зашил» сведения о NTP-серверах. Кроме IP-адресов из диапазонов, зарезервированных для локальных сетей, в них содержались IP-адреса глобальной маршрутизации, среди которых был и публичный сервер NTP университета Мэдисона. Проблема усугублялась ещё и тем, что из указанных в коде глобальных IP-адресов реальным NTP-сервером оказался лишь университетский, а встроенный клиент роутера, не получив ответа на SNTP-запрос, начинал генерировать новые запросы каждую секунду.

Выявив, наконец, причины NTP-флуда, сотрудники университета обратились к производителю роутеров. Netgear пришлось признать свою ошибку. Выяснилось, что к тому моменту уже было продано свыше семисот тысяч подобных устройств. Несложные расчёты показывают, что потенциально они были способны генерировать трафик 426Мбит/с (700000 пакетов UDP в секунду, каждый длиной 76 байт), направленный на один и тот же NTP-сервер.

Для решения проблемы была создана группа с участием представителей университета, производителя и независимых экспертов. Были довольно быстро выпущены исправленные версии программного обеспечения для устройств, содержащих ошибки в коде. Конечно, это не решило всех проблем – ведь выпуск новой версии прошивки производителем не значит её замену всеми пользователями, большая часть которых и не подозревала о подобных проблемах. Тем не менее, университет решил продолжить обслуживание дефектных устройств Netgear, предоставляя им возможность синхронизации системных часов (связано ли это решение с суммой $375,000, которая была выплачена Netgear университету Мэдисона, как говорят, «для повышения безопасности беспроводной сети и развитие сети комплекса зданий университета», автору доподлинно неизвестно).

В том же году подобный инцидент произошел в Австралии. На этот раз его участниками стали лаборатория национальных измерений организации по научным и производственным исследованиям Австралии (Commonwealth Scientific and Research Organisation, CSIRO ) и калифорнийский производитель сетевого оборудования SMC Networks . Предельная загрузка NTP-серверов CSIRO (1-й стратум, источник – цезиевые часы, иначе называемые «атомными ») оценивалась в 200кБит/с. Блокирование трафика, основная часть которого приходила из-за океана, приводило к тому, что устройства SMC при отсутствии ответа от NTP-сервера начинали отсылать запросы дважды в минуту. В конце концов, CSIRO приняла решение изменить адреса своих серверов точного времени (предварительно известив об этом своих партнёров), а провайдеры просто стали блокировать запросы от источников, расположенных вне Австралии.

Последняя наиболее известная проблема подобного рода произошла в 2005 году и впервые получила название «NTP-вандализм », закрепившееся впоследствии как общий термин для обозначения случаев злоупотребления NTP-серверами. Тогда «чёрная метка» досталась датскому серверу 1-го стратума, подключенному к национальной сети Danish Internet Exchange (DIX). Сервер принадлежал одному из разработчиков FreeBSD — Полу-Хёнингу Кампу (Poul-Henning Kamp), и хотя не принадлежал государственным или научным учреждениям, существовал на некоммерческой основе. В правилах использования прямо указывалось, что использовать его для синхронизации времени могут только NTP-серверы второго стратума, расположенные на территории Дании и приложения, работа которых требует чрезвычайно точного времени.

В роли вандала выступил концерн D-Link . По оценке владельца NTP-сервера, от 75% до 90% запросов генерировались роутерами, произведёнными D-Link. Когда количество таких пакетов превысило три миллиона в день, провайдер потребовал от Кампа оплатить расходы, вызванные значительным увеличением трафика в размере DKK 54,000 (примерно $8,800 USD) в год.

Так же, как и в случае с университетом Мэдисона, Камп обратился в D-Link, надеясь на решение проблемы и возмещение своих финансовых затрат, ею вызванных. В отличие от Netgear, D-Link стала отрицать наличие проблемы вообще, в ответ обвиняя Кампа в вымогательстве. Противостояние длилось почти полгода, пока Камп не предал широкой огласке все детали инцидента. Наконец, в апреле 2006 года стороны пришли к мирному соглашению. Было заявлено, что уже существующие продукты D-Link получат авторизованный доступ к NTP-серверу Кампа, а последующие – перестанут его использовать (финансовая сторона соглашения неизвестна, но по некоторым оценкам, содержание собственных серверов времени, способных обслуживать такой трафик, обходилась бы D-Link’у около $1000 в месяц).

Технические решения

Все эти случаи заставили задуматься разработчиков сетевых протоколов над тем, какими способами, кроме применения различных политик доступа, можно избежать подобных проблем в будущем. Одним из решений стали изменения, внесённые в четвертую версию протокола NTP, появившиеся в начале 2006 года и описанные в RFC 4330. Они включают в себя расширение семантики полей пакета NTP для возможности посылки сервером специального управляющего пакета с романтичным названием «поцелуй смерти » (Kiss-o»-Death, KoD). В таком пакете заголовки заполняются специальным образом – поле дополнительной секунды содержит значение 3, поле, указывающее стратум сервера, устанавливается в 0, а идентификатор ссылки содержит 4-х байтовый код, указывающий причину его посылки (на практике пока применяется лишь код RATE — превышение частоты запросов).

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

В документе также представлены рекомендованные принципы, в соответствии с которыми «правильным» NTP-клиентом должны формироваться интервалы времени, определяющие частоту запросов к серверу, использоваться элементы сетевой инфраструктуры (включая DNS и DHCP). Если во встроенном коде устройства планируется указание прямых адресов NTP-серверов, настоятельно рекомендуется делать это лишь после согласования с их владельцами.

В принципе, такие нововведения вполне разумны, однако сколько-нибудь ощутимая польза от них возможна будет лишь тогда, когда подавляющее количество NTP-серверов и клиентов в глобальной сети будут полностью соответствовать требованиям четвёртой версии протокола NTP. Увы, в ближайшее время надеяться на развитие событий таким образом не приходится (к слову, одним из «следов», благодаря которым Камп пришёл к выводу, что источником атак являются роутеры производства D-Link, было использование ими всеми протокола SNTP версии 1).

В качестве технического решения, позволяющего значительно уменьшить пиковую нагрузку на сервера точного времени, можно отметить проект pool.ntp.org . Он представляет собой большой виртуальный кластер географически распределённых ntp-серверов (на момент написания статьи в него входят 1742 сервера со всех континентов). Сам проект был запущен в 2003 году, явившись плодом дискуссии о значительных затратах, необходимых для содержания и эксплуатации надёжных серверов точного времени, способных постоянно обслуживать значительное количество запросов. Идея, положенная в его основу, очень напоминает рекурсивный механизм функционирования серверов DNS. Если в качестве сервера-поставщика точного времени будет указан просто сервер вида 0.pool.ntp.org , то реальный сервер, с которым будет осуществляться синхронизация времени, будет выбираться случайным образом при каждом запросе клиента из списка серверов, входящих в пул. Однако, пользователи пула могут самостоятельно выбирать региональные сервера точного времени, уточняя континентальную зону, или даже зону конкретной страны (как правило, чем ближе сервер, тем точнее выполняется синхронизация), например — 0.ru.pool.ntp.org для России. При этом необходимо помнить, что некоторые страны не представлены в пуле, а некоторые представлены одним — двумя серверами (например, Малайзия). Использование пула осуществляется бесплатно, кроме обслуживания компаний, производящих оборудование и программные продукты, NTP-запросы которых планируется обслуживать при помощи ресурсов pool.ntp.org .

Сама идея запуска публичного сервиса синхронизации с точными часами без обеспечения его стабильности и надёжности в условиях экстремальных нагрузок вряд ли имеет какой-либо смысл. История знает немало примеров почивших NTP-серверов с заявленным 1-м стратумом, «сообщавших» время, отличающееся от реального на десятки (!) секунд, или просто ставших недоступными для запросов. Сервис, позволяющий синхронизировать часы с точным источником времени — это именно тот случай, когда понятие надёжности является таким же важным, как и точность предоставляемых данных. Вот иллюстрация реальной работы NTP-сервера Mobatime Systems:


Статистика запросов NTP-сервера Mobatime Systems

Это достаточно яркий пример NTP-вандализма — 1 апреля 2009 года было заблокировано 75 хостов, отославших более 12 миллионов запросов в сутки. Схожая интенсивность атаки продолжалась в течение 3 суток, и её природу вряд ли можно объяснить банальными ошибками в коде устройств, или их неправильным конфигурированием. Для защиты от подобных атак на NTP-сервере Mobatime используются алгоритмы фильтрации входящего трафика. Такой механизм защиты позволяет отсечь лавинообразный поток «мусора», способный привести систему к полному отказу за короткое время.

Тем не менее, подобная защита станет практически бесполезной, в случае, если объем данных в канале передачи приблизится к его пропускной способности. При такой нагрузке отправка данных легитимным, незаблокированным клиентам станет просто невозможной из-за исчерпания ресурсов каналов связи. Единственным выходом из ситуации, гарантирующим почти полное исключение случаев NTP-вандализма, пожалуй, является создание непубличного сервера точного времени с ограничением доступа. Имея в своём распоряжении надёжный источник времени (например, приёмник данных, передаваемых системой GPS), такой NTP-сервер будет являться стабильным поставщиком сервиса точного времени.

Список материалов, использовавшихся при подготовке публикации (на английском языке):
  • RFC 4330, описание протокола SNTP v4
  • Flawed Routers Flood University of Wisconsin Internet Time Server — отчёт о инциденте в университете Мэдисона, опубликованный его сотрудником Dave Plonka.
  • Network Devices Almost Take Down Atomic Clock — статья о инциденте в CSIRO
  • When firmware attacks! (DDoS by D-Link) — статья Ричарда Клейтона, принимавшего участие в выяснении обстоятельств атаки на NTP-сервер Пола-Хёнинга Кампа
  • Материалы веб-сайта организации pool.ntp.org
  • Help save the endangered time servers — статья Энди Лестера о pool.ntp.org

Я не знаю! Я просто хочу,чтобы у меня не сбивалось время! Подскажите,пожалуйста,что делать?


Может быть, правильно выставить часовой пояс и вовремя получать обновления (в том числе, касающиеся времени)? Ну и батарейку на маме поменять, если старая… на всякий…
научиться задавать вопросы.
До вопроса дело так и не дошло:D

Тематические материалы:

Обновлено: 11.02.2022

103583

Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter

утилита синхронизации времени в ОС

В РЕД ОС синхронизировать время можно следующими основными способами:

  • вручную при помощи утилиты ntpdate;
  • автоматически при помощи сервиса ntp.

Программа ntpdate — позволяет разово синхронизировать локальное время с эталонным сервером времени в интернете. Подобных эталонов существует достаточно много. Для примера можно воспользоваться одним из них — pool.ntp.org.

Запускаем синхронизацию времени:

ntpdate pool.ntp.org

Утилита провела синхронизацию, в результате которой к системному времени было добавлено число секунд, необходимое для приближения к эталонному. Если в результате работы синхронизации возникает ошибка: «no server suitable for synchronization found», то попробуйте в работе утилиты использовать непривилегированный порт. По-умолчанию ntpdate работает по 123 порту. Если он закрыт на фаерволе, то помочь в синхронизации поможет следующий параметр:

ntpdate -u pool.ntp.org

Если у вас запуск ntpdate завершается ошибкой — «the NTP socket is in use, exiting», значит у вас уже установлена и запущена служба ntpd, которая заняла необходимый udp-порт, необходимый для работы ntpdate.

Сервер времени ntp использует в своей работе одноименный протокол — Network Time Protocol, которому для работы необходим UDP-порт 123. Так что перед установкой и настройкой службы времени убедитесь, что на фаерволе открыт этот порт.

Устанавливаем сервер ntp:

Если вы используете РЕД ОС 7.1 или 7.2, выполните команду:

yum -y install ntp

Если вы используете РЕД ОС 7.3 и старше, выполните команду:

dnf -y install ntp

Теперь отредактируем файл конфигурации /etc/ntp.conf, удалив все лишнее:

cat /etc/ntp.confdriftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
 
server 0.redos.pool.ntp.org iburst
server 1.redos.pool.ntp.org iburst
server 2.redos.pool.ntp.org iburst
server 3.redos.pool.ntp.org iburst
 
disable monitor
logfile /var/log/ntp.log

Параметры:

server Список серверов для синхронизации времени.
Driftfile Задает адрес файла, в котором хранится история изменений времени во время синхронизации. Если по каким-то причинам синхронизация времени с внешними источниками станет невозможна, служба времени изменит системные часы в соответствии с записями в этом файле.
Restrict 127.0.0.1

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

restrict  192.168.10.0 mask 255.255.255.0

restrict default nomodify notrap nopeer noquery   — Параметры указывают на то, что клиентам данного сервиса времени запрещено изменять его настройки, получать его статус. Они могут только забрать с него значения точного времени.

disable monitor — Данный параметр повышает безопасность, предотвращая использования одной из уязвимостей сервиса ntpd, которую можно использовать для проведения DDoS атак.

Logfile — Указывает путь к файлу с логами сервиса.

После завершения редактирования файла настроек запускаем службу синхронизации времени:

systemctl start ntpd

Проверяем запустился ли сервер:

netstat -tulnp | grep 123

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

cat /var/log/messages | grep ntpd
cat /var/log/ntp.log

Теперь настроим автозапуск ntp вместе с загрузкой используемой ОС:

systemctl enable ntpd

Наблюдать за работой службы ntp можно с помощью команды:

ntpq -p

Данные вывода:

remote

Адрес удаленного эталона времени, с которого была синхронизация.

Refid Указывает, откуда каждый эталон получает точное время. Это могут быть другие сервера времени, система GPS и другое.
St Уровень (Stratum) это число от 1 до 16, которое указывает на точность эталона. 1- максимальная точность, 16 — сервер недоступен. Уровень вашего сервера будет равен уровню наименее точного удаленного эталона плюс 1.
poll Интервал в секундах между опросами.
Reach Восьмеричное представление массива из 8 бит, отражающего результаты последних восьми попыток соединения с эталоном. Бит выставлен, если удаленный сервер ответил.
Delay Время задержки ответа на запрос о точном времени.
Offset

Разница между вашим и удаленным сервером

jitter

Дисперсия (Jitter) — это мера статистических отклонений от значения смещения (поле offset) по нескольким успешным парам запрос-ответ. Чем меньше значение дисперсии, тем лучше, поскольку позволяет точнее синхронизировать время.

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.

Abstract Machine Test Utility (AMTU) — утилита тестирования аппаратного обеспеченияОтказоустойчивый кластер

Как мне найти свой NTP-сервер в Debian

NTP — это сокращение от «Network Time Protocol», которое используется для синхронизации времени сервера и клиентского компьютера. В этом процессе клиентская машина запрашивает у сервера текущее время, и сервер отправляет данные в виде пакетов. Существует универсальный стандарт времени, которому все следуют как всемирное координированное время (UTC). Порт 123 по умолчанию выделен серверу NTP, и весь этот процесс сопровождается протоколом пользовательских дейтаграмм (UDP).

В этом посте мы сосредоточимся на поиске сервера NTP путем установки и настройки NTP в Debian.

Как мне найти свой NTP-сервер в Debian

NTP — это процесс, в котором клиентская машина запрашивает у сервера время. Итак, сначала мы поймем, как установить и настроить сервер NTP, а затем узнаем, как узнать IP-адреса NTP.

Установка и настройка NTP: Во-первых, мы обновим репозиторий Debian:

$ судо подходящее обновление

Мы установим последний доступный пакет NTP:

$ судо подходящий установить нтп -у

По умолчанию после установки NTP должен иметь активный статус, вы можете подтвердить это, проверив его статус, но если он неактивен, вы можете запустить NTP-сервер:

$ судо systemctl start ntp

После перезапуска проверьте его статус, работает он или нет:

$ судо systemctl статус ntp

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

Выполните эти две команды здесь, попросив брандмауэр разрешить запросы на порт 123, который по умолчанию назначен NTP.

iptables -А ВЫХОД -п udp —dport123-j ПРИНИМАТЬ
iptables -А ВХОД -п udp —dport123-j ПРИНИМАТЬ

Теперь выйдем из режима пользователя root как:

Проверка работы NTP с помощью ntpstat : Команда ntpstat показывает нам, установлено ли соединение между сервером и клиентом, если соединение установлено, то статус будет «синхронизирован». Если ntpstat выдает ошибку «команда не найдена» при запуске команды:

Затем мы можем установить ntpstat, выполнив следующую команду.

$ судо подходящий установить ntpstat -у

Теперь, чтобы проверить статус, снова запустите команду.

В выходных данных отображается IP-адрес сервера NTP, а также последние сведения о корректировке времени с помощью сервер и для проверки статуса синхронизации часов запустим команду для получения выхода положение дел.

Результат «0» означает, что часы клиента синхронизированы с сервером. Другие результаты могут быть либо «1», что означает, что часы клиентской машины не синхронизированы с сервером, либо «2», что означает, что клиент не подключен к серверу.

Проверка сервера ntp с помощью команды ntpq Команда: Ntpq отслеживает работу демона NTP, операции ntpd и определяет производительность NTP. Будем использовать флаги, п что означает печать всего списка одноранговых узлов, известных серверу, со сводкой их состояния, и n, что означает отображение адресов хостов.

Заключение

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

Установка и настройка NTP-сервера в Linux

Протокол сетевого времени NTP (Network Time Protocol) используется для синхронизации времени в вашей системе с централизованным NTP-сервером. В этой статье рассмотрим установку и настройку NTP сервера.

Установка NTP

В первую очередь нужно установить пакет NTP при помощи менеджера пакетов. Например, в RedHat или CentOS используется yum:

yum install ntp

Настройка NTP-сервера

Установка ограничений в ntp.conf
В файл /etc/ntp.conf нужно добавить две строки restrict. Они разрешают синхронизацию с источником данных о времени, но не разрешают источнику опрашивать сервис на нашей системе или изменять его параметры.

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Первая строка разрешает другим клиентам опрашивать ваш сервер времени. В ней заданы следующие параметры:

noquery – запрещает получение данных о состоянии ntpd
notrap – запрещает использование управляющих сообщений.
nomodify – запрещает все запросы ntpq, которые пытаются изменить параметры сервера.
nopeer – запрещает все пакеты, которые пытаются установить синхронизацию с узлом.
kod – отправка пакета об отказе в обслуживании “Kiss-o-death” для исключения нежелательных запросов, затем отключение от сервера.

Значение -6 во второй строке устанавливает аналогичные параметры для IPV6. Более подробная информация о параметрах приведена в соответствующей man-странице

man ntp_acc

Проверьте что у вас в фале конфигурации прописаны внешние NTP-сервера. При желании измените их на свои

server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

Ограничение круга клиентов

Чтобы с вашим NTP-сервером могли синхронизироваться только машины вашей сети, добавьте в файл /etc/ntp.conf следующую строку (указав актуальные для вашей сети значения):

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Если на локальном узле требуется полный доступ с возможностью изменения параметров, нужно добавить такую строку:

restrict 127.0.0.1

Резервное использование локальных часов

Чтобы при отключении от Интернета NTP-сервер определял время по своим локальным системным часам, в файле конфигурации нужно прописать соответствующие параметры.

Протокол NTP использует иерархию, называемую Stratum. Sratum 0 – это эталонные часы, Stratum 1 – серверы, получающие время от них напрямую (не по сети). Начиная со Stratum 2 и далее серверы получают время по сети от серверов предыдущего уровня. С каждым уровнем точность времени снижается. Лучше всего выбирать для синхронизации серверы уровня 2, так как несмотря на более высокую точность Stratum 1 они сильнее загружены, и задержка получения пакетов от них может быть слишком большой.

В двух следующих строках мы командой server указываем использование локального узла в качестве сервера времени, а командой fudge задаем его уровень в иерархии Stratum и исключаем обновление, когда доступ к Интернету есть.

server 127.127.1.0 # локальные часы
fudge 127.127.1.0 stratum 10

Установка параметров журнала

Укажите в файле конфигурации расположение файла погрешности (driftfile) и файла журнала (logfile):

driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

Файл погрешности используется для записи отклонений ваших часов от необходимого значения. С течением времени NTP должен постепенно снижать это отклонение.

Запуск NTP-сервера

После задания необходимых параметров в файле конфигурации ntp.conf нужно запустить службу ntp.

service ntpd start

И добавим в автозагрузку

systemctl enable ntpd

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

windows — сервер NTP, порт не открыт

По умолчанию nmap проверяет порты TCP. Протокол NTP использует только UDP, а служба ntpd устанавливает только сокеты UDP, а не TCP.

Они никак не взаимодействуют — проверка порта TCP 123 абсолютно ничего не говорит вам ни о том, что прослушивает порт UDP 123, ни наоборот.


Кроме того, даже если вы можете попросить nmap сканировать UDP, это не будет работать так надежно, как TCP.

В TCP вы уже можете сказать, что порт определенно «открыт» или «закрыт», если вы можете установить соединение на уровне TCP, до , чтобы говорить по протоколу прикладного уровня.То есть либо вы получаете утвердительный пакет рукопожатия (SYN-ACK), либо отрицательный (RST), либо вообще ничего, но узнаете об этом из самого TCP. (Опция Nmap --reason покажет это более подробно.)

В UDP, с другой стороны, нет отдельного установления соединения – вы отправляете любой пакет, и он напрямую идет к рассматриваемому сервису. Так что если вы отправляете NTP-пакет и получаете ответ, вы точно знаете, что порт «открыт» во всех смыслах.Но если вы отправляете что-то, что является , а не пакетом NTP, а только общим зондом, то служба может просто не ответить!

Таким образом, с UDP вы не можете определить разницу между «нет ответа, потому что прослушиватель решил проигнорировать ваш мусорный пакет» и «нет ответа, потому что — это ничего не слушает» 1 и «нет ответа, потому что брандмауэр отбросил пакет» до того, как оно достигло слушателя».

Чтобы определить, существует ли сокет UDP, используйте netstat ; и чтобы определить, отвечает ли сокет на действительные запросы NTP , используйте фактический клиент NTP (например, ntpdate -q , sntp или w32tm /monitor ).

1 (Теоретически, если бы никто не прослушивал порт UDP, вы обычно получали бы ошибку ICMP «Порт недоступен». На практике брандмауэр Windows работает в так называемом «скрытом режиме», когда порты без прослушивателя вообще не выдает никакого ответа, ни RST для TCP, ни ICMP для UDP, даже если порт разрешен правилами. При желании это можно отключить.)

NTP-трафик на порту 123 TCP (не UDP) — Операторы сервера

Кашра #1

Привет, ребята,

Я получаю довольно много, более 200/сек запросов NTPv4 на порт 123 TCP, а не UDP.
Я не знаю, что с этим делать, так как это происходит на всех серверах, на которых я работаю.

107.18.37.188.rev.vodafone.pt.37830 > loadbalancer.kashra-server.com.123: Flags [S], seq 3725917667, win 65535, options [mss 1412,sackOK,TS val 8256906 ecr 0,nop, масштаб 12], длина 0

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

Это вполне нормально для любого хоста в пуле, хотя и не обязательно для этого тома. Я только что взял образец трафика размером 1 МБ, и для 8225 пакетов UDP порта 123 я получил 5 пакетов TCP порта 123. Это не NTP, но может быть неправильно настроен дневной протокол или просто случайное сканирование портов.

Пинги к хосту пула тоже вполне нормально. Я не вижу никакого вреда в том, чтобы позволить им это. Я получаю гораздо больше ответов «порт недоступен» для ответов на (возможно, поддельные?) запросы, чем запросы ping.

2 лайка

утонуть #3

Также выполняется множество сканирований портов для каждого порта на каждом IP-адресе в Интернете, это может быть совершенно не связано с пулом ntp

1 Нравится

Кашра #4

Частота инцидентов TCP 123 с другими портами составляет примерно 5000 к 1, поэтому сканирование портов, скорее всего, не является основной причиной пакетов TCP 123, даже если они составляют незначительную часть пакетов TCP 123 (около 1/5000)

Я исследовал это немного больше и обнаружил, что многие из них на самом деле являются клиентскими запросами ntpv4, которые по какой-то неизвестной причине являются не UDP, а TCP.

Похоже, что какой-то маршрутизатор/брандмауэр изменяет UDP-пакет на TCP-пакет, при этом некоторые из них отправляют TCP-синхронизацию нулевой длины, другие отправляют TCP с полным телом данных ntpv4.

Синхронные пакеты TCP нулевой длины обычно повторно отправляются 2 или 3 раза с интервалом примерно в 1 секунду друг от друга.

Интересно, что из этого получится, если я отвечу на них син-акком, а не просто сброшу их…

Как это может быть NTP? RFC5905 четко указывает, что NTP — это UDP.Существуют ли на самом деле реализации, которые настолько сломаны, что создают TCP-запросы и ожидают ответов?

Да, похоже, есть клиенты, которые отправляют действительные запросы NTPv3 по TCP и получают данные с сервера. Я понятия не имею, почему они это делают, но мне было бы интересно узнать, баг это или фича.

Авий #7

Обратите внимание, что NTP через TCP был рассмотрен, хотя я не думаю, что этот проект имеет прямое отношение к этому инциденту: https://tools.ietf.org/html/draft-stenn-ntp-tcp-services-00

Кашра #8

Существует два типа «клиентов TCP NTP».

#1 обычные клиенты UDP NTP, где корпоративный брандмауэр по какой-то неизвестной причине транслирует трафик UDP в TCP, но на рынке есть системы, которые делают именно это.

# 2 Некоторые ужасно неправильно настроенные маршрутизаторы, которые отправляют пакеты синхронизации TCP на порт 123 и пытаются выполнить рукопожатие в ожидании ответа синхронизации.

Я буду оценивать это дальше, так как второй случай кажется более региональным. Я заметил, что Vodafone Portugal и Vodafone Germany IoT делают это. Может быть ошибкой домашнего устройства/Интернета вещей/маршрутизатора, которая вызывает случай № 2

.

Можете ли вы привести какие-либо примеры продуктов, которые делают # 1, или ссылки на то, что вы видели этот трафик в дикой природе? Мне менее любопытен № 2, потому что, похоже, это ошибка, порожденная невежеством, но было бы неплохо узнать, если вы узнаете, какие производители и модели делают это.

Безопасность сети изучается IETF. Ранние реализации NTS временно использовали TCP-порт 123. С тех пор TCP-порт 4460 был выделен для NTS.

Но если бы это был трафик NTS, это был бы TLS внутри соединения TCP, а не NTPv4, верно?

Если прослушивателя нет и TCP SYN не передает данных, мы не можем определить предполагаемое соединение.

Если прослушивателя нет, а TCP SYN переносит данные, мы можем сделать обоснованное предположение о предполагаемом соединении. Кроме того, инструменты анализа пакетов, такие как Wireshark, могут использовать эвристику и могут ошибаться.

При наличии прослушивателя можно проанализировать полезную нагрузку соединения TCP. Wireshark нужно сказать, что это TLS, чтобы сделать действительное вскрытие, если NTS является полезной нагрузкой.

Плюс нужно различать серверный и клиентский порты. Иногда я вижу зонды UDP с портом назначения = Netbios и исходным портом = NTP.Я подозреваю, что это попытки победить брандмауэры.

Кашра #13

Будет слушатель. Завтра я сделаю настройку сервера NTS-NTP, который будет прослушивать как TCP 123, так и TCP 4460 и захватывать трафик, чтобы увидеть, действительно ли это трафик NTS или неуклюжий изогнутый трафик UDP ntp.

FWIW, вы можете использовать socat для перенаправления порта TCP на UDP, например:

  socat -x -T 1 tcp4-listen:123,reuseaddr,fork udp4:localhost:123
  

Здесь я не вижу соединений TLS. Просто минимальные запросы NTPv3.

2 лайка

НТПман #15 мличвар:
  socat -x -T 1 tcp4-listen:123,reuseaddr,fork udp4:localhost:123
  

Здесь стоит проверить конфигурацию NTP-сервера, некоторые могут действовать на контрольные сообщения NTP, полученные от localhost.

1 Нравится

Конфигурация брандмауэра UDP входящий или исходящий?

МакВитас #1

Правильно ли я понимаю, что на моих клиентских серверах, время которых я хочу синхронизировать с брандмауэром NTP.org, необходимо разрешить только входящий трафик на целевой UDP-порт 123?
Для нашей сетевой команды: есть ли какие-либо проблемы с безопасностью, чтобы разрешить этот входящий трафик UDP через порт 123 с любого хоста? На мой взгляд, нет, потому что единственное, что слушает это, — это NTP-клиенты (например, служба времени Windows), и он активно запрашивает данные с настроенного NTP-сервера, поэтому он не сможет правильно получать данные с какого-либо другого сервера. ?

МакВитас #2

О, но после прочтения этого я не уверен, достаточно ли входящего UDP-порта 123!

Эксперт-биржа.ком

NTP-порт, необходимый для открытия в брандмауэре Решения | Обмен экспертами

Найдите ответы на вопрос о порте NTP, необходимом для открытия в брандмауэре, от экспертного сообщества на Experts Exchange

. МакВитас #3

, но похоже, что службе времени Microsoft Windows нужен только этот UDP 123 в соответствии с самой нижней частью этой страницы
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings#ntpserver

МакВитас:

Правильно ли я понимаю, что на моих клиентских серверах…

О чем мы говорим, о клиентах или о серверах ?

Для сервера за брандмауэром, к которому вы хотите, чтобы клиенты могли получить доступ, вам нужно будет открыть (назначение) входящий UDP/123, и если исходящий трафик по умолчанию заблокирован, вам нужно будет разрешить (источник) UDP/123 исходящий, чтобы ответить на запросы.

Что касается безопасности, то она ничем не отличается от любой другой службы… Убедитесь, что она правильно настроена, и обновляйте ее.

МакВитас #5

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

Я спросил, нормально ли это, или может быть некоторый риск разрешить входящий UDP-трафик с любого хоста , не могли бы вы прокомментировать это? Обычно правила брандмауэра настроены так, чтобы разрешать трафик с определенных IP-адресов.

НТПман #6

Для ваших NTP-клиентов вы должны разрешить только исходящие UDP-пакеты на порт 123 на любые IP-адреса.Я предполагаю, что ваш брандмауэр имеет отслеживание соединений с отслеживанием состояния, поэтому не требуется явного правила для входящего трафика. Брандмауэр на лету откроет глазок для обратного трафика.

1 Нравится

Безопасный сетевой протокол времени (NTP)

Следуйте приведенным ниже шаблонам, чтобы защитить свой сервер от использования в DDOS-атаке.

СИСКО IOS

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

 ! Базовая конфигурация NTP
ntp-календарь обновлений! обновить аппаратные часы (только для определенного оборудования, т.е. 6509с)
ntp-сервер 192.0.2.1! сервер времени, с которым вы синхронизируетесь
ntp-пир 192.0.2.2 ! сервер времени, с которым вы синхронизируетесь и разрешаете синхронизироваться с вами
источник ntp Loopback0 ! мы рекомендуем использовать петлевой интерфейс для отправки сообщений NTP, если это возможно
!
! NTP-контроль доступа
только запрос группы доступа ntp 1 ! запретить все контрольные запросы NTP
ntp группа доступа обслуживает 1 ! запретить все запросы времени и управления NTP по умолчанию
узел группы доступа ntp 10 ! разрешить синхронизацию времени только с настроенными одноранговыми узлами/серверами
ntp группа доступа обслуживает только 20 ! разрешить запросы синхронизации времени NTP от выбранного набора клиентов
!
! списки контроля доступа (ACL)
утилита ACL для списка доступа 1, чтобы заблокировать все
список доступа 1 запретить любой
!
список доступа 10 примечание Одноранговые узлы/серверы NTP, с которыми мы синхронизируемся
список доступа 10, разрешение 192.0.2.1
список доступа 10 разрешение 192.0.2.2
список доступа 10 запретить любой
!
список доступа 20 примечаний Хосты/сети, которым мы разрешаем получать от нас время
список доступа 20 разрешение 192.0.2.0 0.0.0.255
список доступа 20 запретить любой 

Простая аутентификация NTP с использованием MD5 в IOS может легко управляться для ограниченного набора статических одноранговых узлов и восходящих поставщиков времени, которые ее поддерживают. Поскольку это, как правило, ручной процесс, поддержка аутентификации MD5 для большого набора клиентов, вероятно, будет громоздкой.Тем не менее, эта функция обеспечивает некоторую дополнительную защиту от нежелательных сообщений NTP. В этом примере предполагается, что вы создаете «ключ аутентификации ntp» для каждого узла/сервера. Ключ можно использовать повторно, но мы не рекомендуем повторно использовать один и тот же ключ с одноранговыми узлами или восходящими потоками из разных автономных систем. Также создайте строку «ntp trust-key» для каждого настроенного вами идентификатора ключа. Обратите внимание, что некоторые устройства ограничивают парольную фразу восемью символами.

 ntp аутентификация ! включить NTP-аутентификацию
ключ аутентификации ntp [идентификатор ключа] md5 [хэш] ! определить ключ аутентификации NTP
доверенный ключ ntp [идентификатор ключа] ! пометить ключ аутентификации NTP как доверенный
ntp peer [peer_address] key [key-id] ! сформировать аутентифицированный сеанс с узлом
ntp сервер [адрес_сервера] ключ [идентификатор ключа] ! сформировать аутентифицированный сеанс с сервером 

Следующие команды могут оказаться полезными для мониторинга или устранения проблем с NTP в IOS.

 ! общее состояние NTP и часов
показать статус нтп
! выводит сведения о синхронизации с настроенными одноранговыми узлами/серверами
показать ассоциации ntp [подробно]
! показывает или регистрирует подробные сообщения/пакеты NTP
! ВНИМАНИЕ: не рекомендуется для общего использования в производственной сети!!
отладка ntp [...] 

 

МОЖЖЕВЕЛЬНИК ЮНОС

Следующие операторы конфигурации определяют один или несколько серверов времени, с которых маршрутизатор будет получать время. Опция boot-server используется для синхронизации значительно смещенных часов.Чтобы защитить локальный процесс ntpd в JUNOS, вы можете использовать фильтры брандмауэра на петлевом интерфейсе, как вы, вероятно, делаете для других служб. Аутентификацию также можно выполнить в процессе Juniper ntpd, и ею можно легко управлять для ограниченного набора статических одноранговых узлов и вышестоящих поставщиков времени, которые ее поддерживают. Поскольку это, как правило, ручной процесс, поддержка аутентификации для большого набора клиентов, вероятно, будет громоздкой. Тем не менее, эта функция обеспечивает некоторую дополнительную защиту от нежелательных сообщений NTP.В этом примере предполагается, что вы создаете «ключ аутентификации» ntp для каждого узла/сервера. Ключ можно использовать повторно, но мы не рекомендуем повторно использовать один и тот же ключ с одноранговыми узлами или восходящими потоками из разных автономных систем. Там, где вы видите параметр [key-id], измените это утверждение в соответствии с настройками аутентификации, если таковые имеются.

 система {
    НТП {
        ключ аутентификации [идентификатор ключа] тип значение md5 "[парольная фраза]";
        доверенный ключ [идентификатор ключа];
        /* Разрешить синхронизацию NTP, если часы сервера значительно отличаются от локальных часов */
        загрузочный сервер 192.0.2.1;
        /* NTP-сервер для синхронизации */
        сервер 192.0.2.1;
        сервер 192.0.2.2 ключ [key-id] предпочитаю;
    }
} 

Вы можете использовать петлевой фильтр, который защищает маршрутизатор от другого анонимного доступа, чтобы также ограничить круг общения локальной службы NTP. Соответствующий раздел этого фильтра может выглядеть примерно так:

 от {
    адрес источника {
        0.0.0.0/0;
        /* NTP-сервер для получения времени */
        192.0.2.1/32 кроме;
    }
    протокол udp;
    порт нтп;
}
тогда {
    отказаться;
} 

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

.
 от {
    адрес источника {
        /* NTP-сервер для получения времени */
        192.0.2.1/32;
    }
    протокол udp;
    порт нтп;
}
тогда {
    принимать;
} 

 

UNIX NTPD

Следующая конфигурация предназначена для того, чтобы машина UNIX действовала просто как клиент NTP и никогда не разрешала запросы NTP к ней, кроме как с адреса обратной связи:

 # по умолчанию действует только как базовый клиент NTP
ограничить -4 по умолчанию nomodify nopeer noquery notrap
ограничить -6 по умолчанию nomodify nopeer noquery notrap
# разрешаем сообщения NTP с петлевого адреса, полезно для отладки
ограничить 127.0.0.1
ограничить ::1
# серверы, с которыми мы синхронизируем время
сервер 192.0.2.1
сервер 2001:DB8::1
сервер time.example.net 

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

 -A ВХОД -s 0/0 -d 0/0 -p udp --исходный-порт 123:123 -m состояние --состояние УСТАНОВЛЕНО -j ПРИНЯТЬ
-A ВЫВОД -s 0/0 -d 0/0 -p udp --destination-port 123:123 -m состояние --state НОВЫЙ, УСТАНОВЛЕННЫЙ -j ПРИНЯТЬ 

Аутентификация с эталонным программным обеспечением NTP в UNIX может быть выполнена с использованием шифрования с симметричным ключом, как в Cisco IOS и Juniper JUNOS, с использованием MD5.Однако также доступен подход на основе открытого ключа под названием «AutoKey», который обычно считается еще более безопасным. Дополнительные сведения об этих параметрах см. на странице параметров проверки подлинности NTP и в документации по настройке Autokey.

A ПРИМЕЧАНИЕ О ВЕЩАТЕЛЬНОМ/МУЛЬТИКАНСКОМ NTP

Если вам не нужна многоадресная поддержка NTP, но вы поддерживаете IP-многоадресную рассылку в своей сети, вам следует рассмотреть возможность фильтрации широко известного группового адреса многоадресной рассылки для NTP (224.0.1.1) на вашей границе.

ПРИМЕЧАНИЕ О ФИЛЬТРАЦИИ NTP НА ГРАНИЦЕ

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

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

Фильтрация пакетов из ваших сетей во внешние сети с исходным портом UDP 123 и/или пакетов в ваши сети из внешних сетей с портом назначения UDP 123, безусловно, предотвратит взаимодействие ваших хостов с внешними объектами в качестве серверов NTP, но также может предотвратить некоторые NTP. хосты также могут выступать в роли NTP-клиентов. Мы видели, как некоторые клиенты используют порт 123 в качестве исходных портов. Фильтрация в этом сценарии может вызвать проблемы для этих клиентов.

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

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

проект-ietf-ntp-альтернативный-порт-02

 Инженерная рабочая группа Интернета М. Личвар
Интернет-драфт Red Hat
Обновления: 5905 (если одобрено) 18 октября 2021 г.
Предполагаемый статус: Отслеживание стандартов
Истекает: 21 апреля 2022 г.


                          Альтернативный NTP-порт
                   проект-IETF-NTP-альтернативный-порт-02

Абстрактный

   Этот документ обновляет RFC 5905, чтобы указать альтернативный порт для
   Протокол сетевого времени (NTP), который ограничен сообщениями NTP, которые
   не допускайте увеличения трафика.Статус этого меморандума

   Настоящий Интернет-проект представлен в полном соответствии с
   положения BCP 78 и BCP 79.

   Интернет-Черновики являются рабочими документами Интернет-Инженерии.
   Целевая группа (IETF). Обратите внимание, что другие группы также могут распространять
   рабочие документы в виде Internet-Drafts. Список актуальных интернет-
   Черновики находятся по адресу https://datatracker.ietf.org/drafts/current/.

   Интернет-проекты – это проекты документов, действительные не более шести месяцев.
   и могут быть обновлены, заменены или устаревшими другими документами в любое время.
   время.Неуместно использовать Internet-Drafts в качестве справочного материала.
   материал или цитировать их, кроме как «в процессе».

   Срок действия настоящего интернет-драфта истекает 21 апреля 2022 года.

Уведомление об авторских правах

   Copyright (c) 2021 IETF Trust и лица, указанные в качестве
   авторы документа. Все права защищены.

   Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
   Положения, касающиеся документов IETF (https://trustee.ietf.org/
   лицензия-информация), действующая на дату публикации этого документа.Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права.
   и ограничения в отношении этого документа. Компоненты кода
   извлеченные из этого документа должны включать текст упрощенной лицензии BSD
   как описано в Разделе 4.e Правовых положений о трастах, и
   предоставляется без гарантии, как описано в упрощенной лицензии BSD.





Срок действия Личвара истекает 21 апреля 2022 г. [Страница 1] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


Оглавление

   1.Введение  . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1. Язык требований. . . . . . . . . . . . . . . . . . 3
   2. Альтернативный порт — обновление до RFC 5905. . . . . . . . . . . . 3
   3. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 5
   4. Вопросы безопасности. . . . . . . . . . . . . . . . . . . 5
   5. Благодарности. . . . . . . . . . . . . . . . . . . . . . 5
   6. Ссылки. . . . . . . . . . . . . . . . . . . . . . . . .5
     6.1. Нормативные ссылки  . . . . . . . . . . . . . . . . . . 5
     6.2. Информативные ссылки. . . . . . . . . . . . . . . . . 6
   Адрес автора. . . . . . . . . . . . . . . . . . . . . . . . 6

1. Введение

   Для NTP указано несколько режимов. Пакеты NTP в версиях
   2, 3 и 4 имеют 3-битное поле для режима. Режимы 1 (активный), 2
   (пассивный), 3 (клиент), 4 (сервер) и 5 ​​(широковещательный) используются для
   синхронизация часов. Они указаны в RFC 5905 [RFC5905].Режимы 6 и 7 используются для других целей, таких как мониторинг и удаленное управление.
   управление серверами и клиентами NTP. Режим 6 указан в
   Протокол управляющих сообщений для использования с версией протокола сетевого времени
   4 [I-D.ietf-ntp-mode-6-cmds].

   Первая группа режимов обычно не пропускает трафик.
   усиление, т.е. ответ не больше запроса. Ан
   Исключением является Autokey [RFC5906], который позволяет получить ответ NTP.
   длиннее, чем запрос, например. пакеты, содержащие Сертификат
   Поле расширения сообщения или файла cookie.Автокей используется редко.
   Если он включен на общедоступном сервере, доступ должен быть
   строго контролироваться для ограничения атак типа «отказ в обслуживании» (DoS)
   используя усиление.

   Режимы 6 и 7 NTP позволяют значительно увеличить трафик,
   который использовался в крупномасштабных DoS-атаках в Интернете.
   Общедоступные серверы, поддерживающие эти режимы, должны быть
   настроен не отвечать на запросы с использованием режимов, как рекомендовано
   в BCP 233 [RFC8633], но количество серверов, которые все еще делают это, составляет
   достаточно значительными, чтобы требовать конкретных мер по смягчению последствий.Сетевые операторы реализовали различные меры по смягчению последствий. Они есть
   не задокументировано и может меняться со временем. Некоторые из смягчений
   были замечены:

   1. Заблокированные UDP-пакеты с портом назначения или источника 123.

   2. Заблокированные пакеты UDP с портом назначения или источника 123 и
       определенная длина (например, более 48 октетов)



Срок действия Личвара истекает 21 апреля 2022 г. [Страница 2] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


   3.Заблокированные пакеты UDP с портом назначения или источника 123 и NTP
       режим 6 или 7

   4. Ограниченная скорость пакетов UDP с портом назначения или источника 123.

   Из них только 3-й подход не влияет на
   синхронизация часов с NTP. Однако это смягчение может быть
   реализуется только на устройствах, которые могут проверять полезную нагрузку UDP.

   Количество публичных серверов в проекте pool.ntp.org уменьшилось
   с 2013 года, когда начались масштабные атаки.

   Фильтрация по длине и ограничение скорости влияют на
   Аутентификация Network Time Security [RFC8915], которая использует расширение
   поля в пакетах NTPv4.В этом документе указан альтернативный порт для NTP, который
   ограничен подмножеством протокола NTP, который не позволяет
   усиление для обеспечения безопасной синхронизации часов в
   сети, где порт 123 заблокирован или скорость ограничена.

1.1. Язык требований

   Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
   «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
   «НЕОБЯЗАТЕЛЬНО» в этом документе следует интерпретировать, как описано в BCP.
   14 [RFC2119] [RFC8174], когда и только когда они появляются во всех
   столицы, как показано здесь.2. Альтернативный порт - обновление до RFC 5905

   Таблица на "Рисунок 6: Глобальные параметры" в Разделе 7.2
   [RFC5905] дополнен:

                +=========+=======+=====================+
                | Имя | Значение | Описание |
                +=========+=======+=====================+
                | АЛЬТПОРТ | подлежит уточнению | Альтернативный порт NTP |
                +---------+--------+--------+

                                 Таблица 1

   Следующий текст из Раздела 9.1 из [RFC5905]:








Срок действия Личвара истекает 21 апреля 2022 г. [Страница 3] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


      srcport: номер порта UDP сервера или эталонные часы. Этот
      становится номером порта назначения в пакетах, отправленных с этого
      ассоциация. При работе в симметричных режимах (1 и 2) это
      Поле должно содержать номер порта NTP PORT (123), назначенный
      ИАНА. В других режимах он может содержать любое число, соответствующее
      местная политика.заменяется на:

      srcport: номер порта UDP сервера или эталонные часы. Этот
      становится номером порта назначения в пакетах, отправленных с этого
      ассоциация. При работе в симметричных режимах (1 и 2) это
      Поле должно содержать номер порта NTP PORT (123) или
      альтернативный порт NTP ALTPORT (подлежит уточнению), назначенный IANA. В другом
      режимах, он может содержать любое число в соответствии с локальной политикой.

   В раздел 9.1 добавляется следующий текст:

      Порт ALTPORT (TBD) является альтернативой порту PORT.
      (123).Протокол и формат пакетов NTP, отправляемых из и
      к этому порту не изменяется. И запросы NTP, и ответы МОГУТ быть
      отправлено с альтернативного порта. Пакет NTP НЕ ДОЛЖЕН быть отправлен
      из альтернативного порта, если это ответ, который имеет более длинный
      Полезная нагрузка UDP, чем запрос, или количество пакетов NTP в
      один ответ больше, чем один.

      Только режимы 1 (активный), 2 (пассивный), 3 (клиент), 4 (сервер) и 5
      (широковещательные) обычно можно использовать на этом порту.Сервер NTP, поддерживающий альтернативный порт, ДОЛЖЕН получать
      запросы в клиентском режиме как на PORT (123), так и на ALTPORT
      (подлежит уточнению) порты. Если он отвечает, он ДОЛЖЕН отправить ответ от
      порт, который получил запрос. Если сервер поддерживает NTP
      поле расширения, оно ДОЛЖНО проверять для каждого ответа, что это не
      дольше, чем запрос.

      Когда клиент NTP запускается, он ДОЛЖЕН отправить первый запрос на
      альтернативный порт. Клиент ДОЛЖЕН чередоваться между двумя
      порты, пока не будет получен действительный ответ.Клиент МОЖЕТ отправить
      ограниченное количество запросов к обоим портам одновременно, чтобы
      чтобы ускорить обнаружение отвечающего порта. Когда оба порта
      отвечают, клиент ДОЛЖЕН предпочесть альтернативный порт.

      NTP-сервер, поддерживающий NTS, ДОЛЖЕН включать порт NTPv4.
      Запись согласования в ответах NTS-KE для указания альтернативы
      port как порт, на который клиент должен отправлять запросы NTP.





Срок действия Личвара истекает 21 апреля 2022 г. [Страница 4] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


      В симметричных режимах (активном и пассивном) пакеты NTP
      считаются запросами и ответами одновременно.Следовательно, два одноранговых узла, использующих альтернативный порт, ДОЛЖНЫ отправлять пакеты.
      одинаковой длины для синхронизации друг с другом. То
      одноранговые узлы МОГУТ по-прежнему использовать разные интервалы опроса, так как пакеты,
      последующие опросы считаются отдельными запросами и
      ответы.

3. Соображения IANA

   IANA запрашивается для выделения следующего порта в имени службы
   и Реестр номеров портов транспортного протокола [RFC6335]:

      Имя службы: ntp-alt

      Транспортный протокол: UDP

      Правопреемник: IESG 

      Контактное лицо: Председатель IETF 

      Описание: Протокол сетевого времени

      Ссылка: [[этот меморандум]]

      Номер порта: [[TBD]], выбранный IANA из диапазона системных портов.

4. Вопросы безопасности

   Злоумышленник «человек посередине» (MITM) может выборочно блокировать запросы
   отправляется на альтернативный порт, чтобы заставить клиента выбрать исходный
   порт и получить ухудшенный сервис NTP со значительной потерей пакетов.
   Клиенту необходимо периодически пробовать альтернативный порт для восстановления.
   из деградировавшей службы, когда атака прекращается.5. Благодарности

   Автор хотел бы поблагодарить Daniel Franke, Dhruv Dhody, Ragnar
   Sundblad и Steven Sommars за их полезные комментарии.

6. Ссылки

6.1. Нормативные ссылки

   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
              Уровни требований», BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, март 1997 г.,
              .



Срок действия Личвара истекает 21 апреля 2022 г. [Страница 5] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


   [RFC5905] Миллс, Д., Мартин, Дж., Эд., Бербанк, Дж., и В. Каш,
              «Протокол сетевого времени версии 4: протокол и алгоритмы
              Спецификация», RFC 5905, DOI 10.17487/RFC5905, июнь 2010 г.,
              .

   [RFC6335] Коттон М., Эггерт Л., Тач Дж., Вестерлунд М. и С.
              Чешир, «Управление по присвоению номеров в Интернете (IANA)
              Процедуры управления именем услуги и
              Реестр номеров портов транспортного протокола", BCP 165,
              RFC 6335, ДОИ 10.17487/RFC6335, август 2011 г.,
              .

   [RFC8174] Лейба, Б., «Неоднозначность прописных и строчных букв в RFC.
              2119 ключевых слов», BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              Май 2017 г., .

6.2. Информативные ссылки

   [I-D.ietf-ntp-mode-6-cmds]
              Хаберман, Б., "Протокол управляющих сообщений для использования с
              Сетевой протокол времени версии 4", работа в процессе,
              Интернет-черновик, черновик-ietf-ntp-mode-6-cmds-10, 28
              Сентябрь 2020 г., .

   [RFC5906] Хаберман, Б., изд. и Д. Миллс, "Протокол сетевого времени".
              Версия 4: Спецификация Autokey», RFC 5906,
              DOI 10.17487/RFC5906, июнь 2010 г.,
              .

   [RFC8633] Рейли, Д., Стенн, Х., и Д. Сиболд, «Сетевое время
              Передовые современные протоколы», BCP 223, RFC 8633,
              DOI 10.17487/RFC8633, июль 2019 г.,
              .

   [RFC8915] Франке Д., Сиболд Д., Тейхель К., Дансари М. и Р.
              Сандблад, «Безопасность сетевого времени для сетевого времени».
              Протокол», RFC 8915, DOI 10.17487/RFC8915, сентябрь 2020 г.,
              .

Адрес автора

   Мирослав Личвар
   Красная шляпа
   Пуркинова 115
   612 00 Брно
   Чешская Республика




Срок действия Личвара истекает 21 апреля 2022 г. [Страница 6] 

Internet-Draft Альтернативный порт NTP Октябрь 2021 г.


   Электронная почта: [email protected]ком


















































Срок действия Lichvar истекает 21 апреля 2022 г. [Страница 7]
 

НТП

NTP используется для синхронизации часов сетевого клиента с сервером. Это основная работа Дэвида Л. Миллса, доктора философии.

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

.

История

В статье Википедии есть соответствующее описание протокола.

Зависимости протокола

  • UDP: обычно NTP использует UDP в качестве транспортного протокола. Хорошо известный порт UDP для трафика NTP — 123.
  • .

Пример трафика

XXX — добавьте сюда пример трафика (в виде простого текста или снимка экрана Wireshark).

Wireshark

Диссектор NTP полностью функционален.

Настройки предпочтений

Нет настроек предпочтений, связанных с NTP.

Пример файла захвата

Фильтр дисплея

Полный список полей фильтра отображения NTP можно найти в ссылке фильтра отображения

.

Показать только трафик на основе NTP:

  НТП  

Улавливающий фильтр

Вы не можете напрямую фильтровать протоколы NTP во время захвата.Однако вы можете фильтровать по хорошо известному порту NTP UDP 123.

.

Захват только трафика на основе NTP:

  UDP-порт 123  

Во многих системах вы можете сказать «udp port ntp» вместо «udp port 123».

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

Текущий RFC:

  • RFC 5905 Протокол сетевого времени версии 4: Спецификация протокола и алгоритмов

Устаревшие RFC:

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

  • RFC 1059 Протокол сетевого времени (версия 1) Спецификация и реализация

  • RFC 1119 Протокол сетевого времени (версия 2) Спецификация и реализация

  • RFC 1305 Протокол сетевого времени (версия 3) Спецификация, реализация и анализ

Другая информация:

Обсуждение

Примечание. В WinXP служба «Время Windows» должна быть остановлена, чтобы пакеты NTP проходили вверх по стеку и были видны Wireshark.


Импортировано с https://wiki.wireshark.org/NTP 11 августа 2020 г., 23:17:35 UTC

NTP против PTP — Masterclock, Inc.

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

Почему мы не можем просто обновить наши компьютеры до общедоступных серверов NTP в NIST, на котором работают одни из самых точных часов в мире, и покончить с этим? К сожалению, задержка существует везде, и она делает идеальную синхронизацию невозможной. Скорость света высока — в вакууме фотон может облететь нашу планету более семи раз в секунду — и хотя по обычной оптоволоконной сети он движется примерно на 31 процент медленнее, вы можете легко передать один бит данных на полпути. вокруг света менее чем за десятую долю секунды.

Однако все мы знаем, что идеального мира не существует. Добавьте к этому коммутаторы, маршрутизаторы и другую сетевую инфраструктуру, и эта десятая доля секунды увеличится в несколько раз. Без специализированного оборудования ваша сеть внезапно отключается на большую часть секунды от NIST в США или NPL в Великобритании.

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

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

NTP, или сетевой протокол времени, получил широкое распространение в качестве средства сетевого хронометража, и в настоящее время существует его четвертая основная версия. Иерархическая система имеет различные слои, называемые стратами. Устройства Stratum 0 в самом верху включают атомные часы, как и в спутниках GNSS.

Уровня 1 или основных серверов времени, каждый из которых имеет прямое соединение один на один с часами Уровня 0, обеспечивает синхронизацию на уровне микросекунд с часами Уровня 0 и подключается к другим серверам Уровня 1 для быстрой проверки работоспособности и резервного копирования данных .Серверы Stratum 2 могут подключаться к нескольким первичным серверам времени для более тесной синхронизации и повышения точности и т. д. и т. п. NTP поддерживает до 15 уровней, но каждый уровень немного снижает синхронизацию клиента по сравнению с уровнем 0.

64-битная временная метка, реализованная в настоящее время, разделена на две равные 32-битные части:

Предлагаемое обновление до 128- битовые временные метки в NTPv4 увеличили бы шкалу времени чуть менее чем до 600 миллиардов лет, а разрешение по времени — до менее чем фемтосекунды.

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

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

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

Каждая последовательность PTP включает серию из четырех сообщений между ведущим и ведомым:

  • Начальное сообщение синхронизации от ведущего к ведомому

  • Последующее сообщение синхронизации от ведущего к ведомому

  • Сообщение запроса задержки от ведомого к ведущему

  • Окончательное ответное сообщение о задержке от ведущего к ведомому

Эта последовательность создает четыре разных метки времени:

  • T1, когда ведущее устройство отправляет начальное сообщение синхронизации

  • , когда начальное получает ведомое устройство T2 900 сообщение синхронизации

  • T3, когда ведомое устройство отправляет запрос на задержку

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

    Сети NTP имеют большую задержку и меньшую точность просто потому, что они основаны на программном обеспечении, и все запросы меток времени должны ждать локальной операционной системы. Для большинства компаний NTP обеспечивает достаточно точное временное разрешение для своевременного разрешения конфликтов, но некоторым организациям, включая вышеупомянутые физические лаборатории, требуется гораздо более высокий уровень синхронизации.Серверы GMR1000 и GMR5000 PTP Grandmaster соответствуют стандарту IEEE 1588. 0183.

Зачем вообще возиться с сервером времени?

Отметка времени и синхронизация клиентов жизненно важны для вашей сети, но некоторые сетевые инженеры все еще считают, что им может сойти с рук простая синхронизация серверов с общедоступными интернет-часами.Хотя интернет-часы прекрасно подходят для потребительских устройств, таких как смартфоны, они плохо подходят для бизнес-сетей по одной простой причине: безопасность.

Чтобы подключить сервер к интернет-часам, необходимо сначала открыть порт 123 на брандмауэре. В результате произойдет что-то ужасное? Мы не знаем, но мы не знаем точно так же, как мы не знаем, проникнет ли грабитель, потому что вы оставили входную дверь незапертой в вашем доме. Зачем рисковать? Выделенный NTP-сервер обеспечивает безопасность вашей сети и обеспечивает более точную отметку времени.

Что произойдет, если мой сервер времени будет отключен?

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

Например, наш NTP-сервер NTP100-GPS имеет стабильность удержания 3 секунды в год, что означает, что ваш сервер будет по-прежнему синхронизироваться с точностью до 3 секунд UTC даже после целого года бездействия.Высокостабильная модель с кварцевым генератором, управляемым печью, может похвастаться еще большей стабильностью удержания в 250 миллисекунд в год — это менее 1 миллисекунды в день. Наш вариант генератора HSO-3, доступный только на наших серверах GMR5000 NTP и PTP Grandmaster, дополнительно снижает дрейф до максимум 1 миллисекунды в год.

У вас есть вопросы о синхронизации сети? Нужна помощь в принятии решения о том, какая технология сетевой синхронизации лучше всего подходит для вас? Свяжитесь с нами сегодня .

.

Добавить комментарий

Ваш адрес email не будет опубликован.