Точность синхронизации времени по ntp. Смотреть что такое "NTP" в других словарях. Зачем нужно точное время

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 настраивают свои часы, синхронизируясь с текущим временем постепенно либо единовременно.

Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная , ограничено параметром 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 -сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой, как отказ первичного эталона.

Задача узнать точное время с некоторых пор стоит не только перед человеком. Множеству систем, созданных им, для правильного функционирования необходимо постоянно иметь в своём распоряжении очень точные часы, причём их точность должна быть значительно выше часов, используемых людьми в обычной жизни. Помимо собственно точности часов, не менее важной является их синхронизация со шкалой всемирного времени. Ведь даже в шкалу 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

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

MSK-IX NTP server относится к высшему уровню точности (Stratum One Time Servers) в иерархической системе часовых уровней. В качестве эталонного сигнала времени используется сигнал глобальных спутниковых систем навигации ГЛОНАСС (приоритетно) и GPS.

MSK-IX NTP Server реализован в виде группировки серверов, размещенных в Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске. Применение сетевой технологии anycast обеспечивает высокую надежность и быстрый отклик системы на всей территории страны.

Серверы MSK-IX также включены в международный пул NTP-серверов POOL.NTP.ORG, широко используемый в настройках операционных систем.

Как начать пользоваться службой NTP Server?

Используйте следующие параметры при конфигурации оборудования:

Имя сервера	ntp.msk-ix.ru
IPv4-адрес	194.190.168.1
IPv6-адрес	2001:6d0:ffd4::1

Как установить пиринг с сетью NTP-сервера MSK-IX?

Для сокращения сетевого маршрута до NTP-сервера MSK-IX используйте службу Route Server или установите прямой пиринг с сетью MSK-IX DNS Cloud . Пиринговое взаимодействие устанавливается по дополнительной заявке в рамках договора на подключение к MSK-IX без дополнительной оплаты.

Синхронизация времени является важной задачей, хотя не многие задумывались об этом. Ну что плохого в убежавшем на сервере времени? А знаете ли вы, что многие проблемы с часами влияют на протоколы, связанные с криптографией? По этой причине в Active Directory разница в часах более 5 минут будет приводить к проблемам аутентификации Kerberos.

Часовые уровни. Strata.

Чтобы понять устройство NTP следует знать про концепцию strata или stratum . Авторитетные источники времени, такие как спутники GPS, цезиевые атомные часы, радио волны WWVB - всё это stratum 0 . Они авторитетны на том основании, что у них есть некоторый способ поддержания высокоточного хронометража. Можно, конечно, воспользоваться обычными кварцевыми часами, но зная, что за месяц с ними легко потерять 15 секунд, то лучше их не использовать в качестве мерила времени. Stratum 0 это когда секунда не потеряется за 300 000 лет!

Компьютеры, которые напрямую (не по сети!) берут время у stratum 0 - это stratum 1 . Так как всегда есть задержки из-за передачи сигнала и затраты на установку времени, то компьютеры stratum 1 не так точны как stratum 0 , но в реальной жизни различие достигает пару микросекунд (1 мкс = 10 -6 с), что вполне допустимое отклонение.

Следующий уровень компьютеров, берущих время по сети у stratum 1 - это... барабанная дробь... интрига... stratum 2 ! Опять таки из-за различных задержек (сетевые точно), stratum 2 чуток отстаёт от stratum 1 и уж точно от stratum 0 . На практике это разница от нескольких микросекунд (1 мкс = 10 -6 с) до нескольких миллисекунд (1 мс = 10 -3 с). Многие хотят синхронизироваться со слоем не дальше stratum 2 .

Как понятно из схемы, stratum 4 берёт время у вышестоящего stratum 3 . stratum 5 у stratum 4 и так далее. stratum 16 считается самым нижним слоем и время там считается несинхронизированным .

Чтобы синхронизировать время с помощью протокола NTP, следует сначала вручную выставить ваше время. Недопустима разница между вашим точным временем и показаниями ваших часов более 1000 секунд. Если используемый вами сервер времени врёт более 1000 миллисекунд (1 секунда), то он будет исключён из списка и будут использоваться другие вместо него. Данный механизм позволяет отсеивать плохие источники времени.

Клиент времени.

В файле /etc/ntp.conf для клиента важны строки Server. Их может быть несколько - до 10 штук!

Сколько добавлять? Следует иметь в виду:

• Если у вас только один сервер (одна строка server), то если данный сервер начнёт врать, то вы будете слепо следовать за ним. Если его время убежит на 5 секунд и вы убежите в след за ним.
• Если добавлено 2 сервера (2 строки server), то NTP пометит их обоих как false tickers . Если один из них будет врать, то NTP не может понять кто врёт, так как нет кворума.
• Если добавлено 3 и более сервера времени, то можно вычислить одного вруна false tickers . Если серверов времени 5 или 6, то можно найти 2 вруна false tickers . Если серверов 7 или 8, то 3 false tickers . Если серверов 9 и 10, то 4 false tickers .

Проект NTP Pool.

Есть такой проект NTP Pool по адресу которого pool.ntp.org/zone/ru/ можно найти рекомендованные для русских пользователей сервера времени.

server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org

Такие операционные системы, как Debian и Ubuntu, предлагают пользователям свои сервера времени.

server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server 3.debian.pool.ntp.org

server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

Если вызвать на вашем Linux компьютере, который использует NTP, команду ntpq -pn

Remote refid st t when poll reach delay offset jitter ============================================================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53.658 -0.877 1.174 +85.21.78.23 193.190.230.65 2 u 1027 1024 377 54.651 0.167 1.531 *62.173.138.130 89.109.251.24 2 u 940 1024 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482

О чём говорят названия столбцов:

• remote - удалённые сервера, с которыми вы синхронизируете время.
• refid - вышестоящий stratum для данного сервера.
• st - уровень stratum. От 0 (нам недоступно) до 16 (нам не желательно). Идеально - 2.
• t - тип соединения. "u " - unicast или manycast, "b " - broadcast или multicast, "l " local reference clock, "s " - симметричный узел, "A " - manycast сервер, "B " - broadcast server, "M " - multicast сервер.
• when - время, когда последний раз сервер ответил нам. Параметр отображает число в секундах, но может в минутах, если число с m или в часах, если h .
• poll - частота опроса. Минимум 16 секунд, максимум 32 часа. Число должно быть 2 n . Обычно в данном параметре наблюдается или 64 секунды или 1024.
• reach - 8 бит октета, показывающий статус общения с удалённым сервером времени: успешный или сбойный. Если биты установлены - то успешно, иначе - сбой. Значение 377 - бинарно это 0000 0000 1111 1111.
• delay - значение в миллисекундах показывает время между отправкой и получения ответа (round trip time - RTT).
• offset - смещение в миллисекундах между вами и серверами времени. Может быть положительным и отрицательным числом.
• jitter - абсолютное значение в миллисекундах с указанием среднеквадратичного отклонения вашего смещения.

Перед IP адресом NTP сервера есть символ - это tally code . Виды tally code :

• " " - отброшен как недопустимый. Например, нет связи с ним или он в оффлайн, он слишком высокого ранга и не обслуживает таких как вы.
• "x" - отброшен алгоритмом "пересечения" (intersection algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них.
• "." - отброшен из-за переполнения таблицы.
• "-" - отброшен алгоритмом кластеризации (cluster algorithm). Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния синхронизации.
• "+" - сервер включён алгоритмом "комбинирования" (combine algorithm). Этот сервер - отличный кандидат если текущий сервер времени начнёт отказывать вам.
• "#" - сервер является отличным альтернативным сервером времени. Сервер с # можно увидеть только если у вас более 10 записей server в /etc/ntp.conf
• "*" - текущий сервер времени. Его показания используются для синхронизации ваших часов.
• "o" - сервер Pulse per second (PPS). Обычно это означает, что данный сервер времени использует источники времени типа GPS спутников и другие сигналы точного времени. Если рисуется о , то другие типы tally code уже отображаться не будут.

В поле refid могут быть следующие значения:

• IP адрес - адрес удалённого сервера времени.
• .ACST.- NTP manycast сервер.
• .ACTS.- Automated Computer Time Service из American National Institute of Standards and Technology.
• .AUTH.- ошибка аутентификации.
• .AUTO.- ошибка в последовательностях Autokey.
• .BCST.- NTP broadcast сервер.
• .CHU.- Shortwave radio receiver от станции CHU в Ottawa, Ontario, Canada.
• .CRYPT.- ошибка протокола Autokey.
• .DCFx.- LF radio receiver от станции DCF77 в Mainflingen, Germany.
• .DENY.- В доступе отказано.
• .GAL.- European Galileo satellite receiver.
• .GOES.- American Geostationary Operational Environmental Satellite receiver.
• .GPS.- American Global Positioning System receiver.
• .HBG.- LF radio receiver от станции HBG в Prangins, Switzerland.
• .INIT.- Peer association initialized.
• .IRIG.- Inter Range Instrumentation Group time code.
• .JJY.- LF radio receiver от станции JJY в Mount Otakadoya, рядом с Fukushima или Mount Hagane на острове Kyushu, Japan.
• .LFx.- Обычный LF radio receiver.
• .LOCL.- локальные часы хоста.
• .LORC.- LF radio receiver от Long Range Navigation (LORAN-C).
• .MCST.- NTP multicast сервер.
• .MSF.- Anthorn Radio Station рядом с Anthorn, Cumbria.
• .NIST.- American National Institute of Standards and Technology.
• .PPS.- часы Pulse per second.
• .PTB.- Physikalisch-Technische Bundesanstalt от Brunswick и Berlin, Germany.
• .RATE.- превышен порог опроса NTP.
• .STEP.- изменение шага NTP. Смещение offset менее 1000 миллисекунд, но более 125 миллисекунд.
• .TDF.- LF radio receiver от станции TéléDiffusion de France в Allouis, France.
• .TIME.- NTP association timeout.
• .USNO.- United States Naval Observatory.
• .WWV.- HF radio receiver от станции WWV в Fort Collins, Colorado, United States.
• .WWVB.- LF radio receiver от станции WWVB в Fort Collins, Colorado, United States.
• .WWVH.- HF radio receiver от станции WWVH в Kekaha, на острове Kauai на Hawaii, United States.

Во-первых, избавьтесь от мысли как бы получить время от stratum 1 , дескать они ближе всех к точному времени. Они то ближе к точнейшему времени на планете, только сами они перегружены и у них высокие задержки RTT для обычных серверов. Лучше найти нормальный stratum 2 и не переживать по этому поводу. Не забывайте, что речь идёт о микросекундах и миллисекундах, что в обычной жизни - вполне достаточно.

Во-вторых, помните, что подключение к ближайшему серверу времени не всегда идеальный вариант. Важнее не территориальная близость, а уровень stratum. Проект NTP Pool публикует список серверов только уровня stratum 1 и stratum 2 и лучше взять до 10 серверов времени из данного списка, что будет просто замечательно.

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

Для крупных контор, лучшим вариантом будет поднятие своего сервера времени для рабочих компьютеров. Данный сервер будет получать точное время от серверов времени в Интернете и предоставлять его локальным компьютерам. На серверах Debian и Ubuntu достаточно раскомментировать строку

Restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap

в конфигурационном файле демона ntpd - /etc/ntp.conf

Пользователи из сети 192.168/16 будут иметь возможность брать с вашего сервера показания точнейших часов. Для внутренних серверов на базе Linux, которые не являются серверами времени и занимаются своими задачами, вместо запуска демона ntpd в клиентском режиме - вполне достаточно указать в файле /etc/cron.daily/syncntpd. Рекомендуется прочесть различия между ntpdate и ntp и решить для себя вопрос.
#!/bin/sh
/usr/sbin/ntpdate IP.адрес.вашего.сервера > /dev/null 2>&1
exit 0

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

В-четвёртых, NTP никак не связан, в какой стране и какие часовые пояса используются и как происходит переход на летнее и зимнее время и делается ли в данной стране такой переход. Это обязанность лежит на операционной системе, которую вам нужно обновлять, если в стране происходят изменения в часовых делах. В системах Debian и Ubuntu за это отвечает пакет tzdata, который должен быть актуальным.

В-пятых, лучше не поднимать свой NTP сервер на высоконагруженной системе.