Порт ntp сервера по умолчанию. Чем отличается протокол синхронизации времени NTP от SNTP? Зачем нужно точное время

Доброго дня, гости и постоянные читатели . Постепенно перехожу от основ к более углубленному изучению Linux. Сегодня хочу рассмотреть работу протокола ntp , а так же настройку сервера времени на Linux (ntp server) . Итак, начнем с теории.

Протокол NTP

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

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

Текущая версия протокола - NTP 4 . NTP использует иерархическую систему «часовых уровней» (их так же называют Stratum ). Уровень 0 (или Stratum 0) - это, обычно, устройства представляющие собой атомные часы (молекулярные, квантовые), GPS часы или радиочасы. Данные устройства обычно не публикуются во всемирную сеть, а подключаются напрямую к серверам времени уровня 1 посредством протокола RS-232 (на иллюстрации обозначены желтыми стрелками). Уровень 1 синхронизирован с высокоточными часами уровня 0 , обычно работают в качестве источников для серверов уровня 2 . Уровень 2 синхронизируется с одной из машин уровня 1 , а так же возможна синхронизация с серверами своего уровня. Уровень 3 работает аналогично второму. Обычно в сеть публикуются сервера уровней от второго и ниже. Протокол NTP поддерживает до 256 уровней. Так же хочется отметить, что сервера уровней 1 и2, а иногда и 3 не всегда открыты для всеобщего доступа. Иногда, чтобы синхронизироваться с ними, необходимо послать запрос по почте - администраторам домена.

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

Назначение сервера NTP в локальной сети

Для чего нам может понадобиться NTP server? Например, существуют службы в операционных системах, которые могут зависеть от синхронизированного времени. Наиболее ярким примером таких служб является протокол аутентификации Kerberos. Для его работы необходимо, чтобы на компьютерах, доступ к которым осуществляется с использованием этого протокола, системное время различалось не более чем на 5 минут. Кроме того, точное время на всех компьютерах значительно облегчает анализ журналов безопасности при расследовании инцидентов в локальной сети.

Режимы работы NTP сервера/клиента

Клиент/сервер

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

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

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

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

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

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Время в Linux

Кратко расскажу, какое время существует в Linux и как его задать. В Linux, как и в другой ОС, существует 2 времени. Первые - аппаратные , иногда называемые Real Time Clock , сокращенно (RTC ) (они же - часы BIOS) обычно они связаны с колеблющимся кварцевым кристаллом, имеющим точность хода до нескольких секунд в день. Точность зависит от различных колебаний, например, окружающей температуры. Вторые часы - внутренние программные часы , которые идут непрерывно, в том числе и при перерывах в работе системы. Они подвержены отклонениям, связанным с большой системной нагрузкой и задержкой прерываний. Однако система обычно считывает показания аппаратных часов при загрузке и потом использует системные часы.

Дата и время операционной системы устанавливается при загрузке на основании значения аппаратных часов , а так же настроек часового пояса . Настройки часового пояса берутся из файла /etc/localtime . Данный файл - есть ссылка (но чаще - копия) одного из файлов в структуре каталога /usr/share/zoneinfo/ .

Аппаратные часы Linux могут хранить время в формате UTC (аналог GMT), либо текущее территориальное время. Общая рекомендация в том, какое время устанавливать (?) следующая: если на компьютере установлено несколько ОС и одна из них - Windows, то необходимо использовать текущее время (т.к. Windows берет время из BIOS/CMOS и считает его локальным). Если используются только операционные системы UNIX семейства, то желательно хранить время в BIOS в UTC формате.

После загрузки операционной системы, часы операционной системы и BIOS полностью независимы. Ядро системы раз в 11 секунд синхронизирует системные часы с аппаратными.

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

Примечание:

Ядро Linux"а всегда хранит и вычисляет время, как число секунд прошедших с полночи 1-го января 1970 года , в независимости от того, установлены ваши часы на локальное или всемирное время. Преобразование в локальное время производится в процессе запроса.

Поскольку количество секунд с 1-го января 1970 года всемирного времени сохраняется как знаковое 32-битное целое (это справедливо для Linux/Intel систем), ваши часы перестанут работать где-то в 2038 году. Linux не имеет проблемы 2000-го года, но имеет проблему 2038 года. К счастью, к тому времени все linux"ы будут запущены на 64-х разрядных системах. 64-х битное целое будет содержать наши часы приблизительно до 292271-миллионного года.

NTP Server Linux

Введение

Существует масса реализаций для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd.

Демон ntpd является одновременно и сервером времени и клиентом, в зависимости от настроек конфигурационного файла /etc/ntpd.conf (иногда /etc/ntp.conf), демон может и "принимать" время с уделенных серверов и "раздавать" другим хостам время.

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

Установка ntpd

Собственно, установка демона сводится к установке следующих пакетов: ntp (пакет включающий самого демона), ntpdate (утилита для ручной синхронизации времени - устарела), ntp-doc (документация по пакету), в некоторых дистрибутивах нужно будет установить так же ntp-utils (утилиты для диагностики), в некоторых они включены в пакет ntp. Как производить установку программ в Linux , я описывал в . После установки пакета, в большинстве дистрибутивов, демон будет уже сконфигурирован как как ntp-клиент (например в Debian было так). Соответственно, автоматически были созданы основные конфигурационные файлы: /etc/ntp.conf и /var/lib/ntp/ntp.drift и автоматом запущен демон.

Перед настройкой демона на синхронизацию с внешним миром я бы посоветовал установить текущую системную дату на значение, максимально приближенное к реальному времени. Установка даты в Linux производится командой: date MMDDhhmmCCYY.ss, где MM - месяц, DD - день месяца, hh - часы, mm - минуты, CCYY - 4 цифры года, ss - секунды. При этом, значения CCYY.ss указывать не обязательно.

Как видно, указанная команда установит текущие дату и время на 27 декабря 2010года, 20:06:30. Команда date без параметров, выводить текущее системное время. У данной команды есть куча параметров, с которыми можно ознакомиться в man date.

Так же, необходимо правильно настроить аппаратные часы и часовой пояс. Как говорилось выше, часовой пояс настраивается копированием необходимого файла зоны из каталога /usr/share/zoneinfo/ в файл /etc/localtime :

Ntp-server:~# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Аппаратные часы я настроил на UTC :

# cat /etc/sysconfig/clock | grep UTC # UTC=true indicates that the clock is set to UTC; UTC=true ntp2-server:~# cat /etc/default/rcS | grep UTC UTC=yes

В первом примере указан конфигурационный файл, определяющий использование UTC для RH, второй - для Deb-дистрибутивов.

Кроме установки настроек на использование времени в формате UTC, необходимо задать аппаратное время . (в большинстве случаев в этом нет необходимости, потому что заданное системное время неизбежно синхронизируется с аппаратным, силами ядра). Но все же, если у вас есть желание это сделать... Команда hwclock читает и устанавливает аппаратные часы на основании переданных ему параметров. Доступные параметры описаны в странице руководства команды. Вот несколько примеров использования hwclock:

Ntp-server# hwclock # считывает время из аппаратных часов ntp-server# hwclock --systohc --utc # устанавливает время аппаратных часов равным # UTC на основании системного времени ntp-server# hwclock --systohc # устанавливает время аппаратных часов # равным местному на основании системного времени ntp-server# hwclock --set --date "22 Mar 2002 13:17" # устанавливает время аппаратных часов # равным указанной строке

Другим вариантом изменения времени в аппаратных часах - это доступ в BIOS при загрузке системы. Поскольку время ОС независимо от аппаратных часов, любые изменения в BIOS будут учтены при следующей загрузке.

Теперь, когда у нас все подготовлено и установлено, приступим к настройке .

Управление демоном ntpd

Управление демоном ntpd ничем не отличается от управления любыми другими демонами. Запуск или перезапуск службы ntpd:

#/etc/init.d/ntp start #/etc/init.d/ntp restart

Остановка:

#/etc/init.d/ntp stop

#/bin/kill `cat /var/run/ntpd.pid`

Демон имеет следующие параметры запуска:

P - PID-файл,
-g - разрешить переход на большой скачек времени
-c - конфиг файл
-q - принудительная ручная синхронизация

Настройка сервера ntpd

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

Ntp-server:~# cat /etc/default/ntp NTPD_OPTS="-g"

# cat /etc/sysconfig/ntpd # Parameters for NTP daemon. # See ntpd(8) for more details. .... # Specifies additional parameters for ntpd. NTPD_ARGS="-g"

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

Итак, как я уже говорил, информация о конфигурации демона ntpd лежит в файле /etc/ntp.conf. Синтаксис файла стандартен, как и во многих других конфигах: пустые строки и строки, начинающиеся с символа "#" игнорируются. Вот простой пример:

Ntp-server:~# cat /etc/ntp.conf server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift

Параметр server задает, какие серверы будут использоваться для синхронизации, по одному в каждой строке. Если сервер задан с аргументом prefer , как ntplocal.example.com , то этому серверу отдается предпочтение перед остальными. Ответ от предпочтительного сервера будет отброшен, если он значительно отличается от ответов других серверов, в противном случае он будет использоваться безотносительно к другим ответам. Аргумент prefer обычно используется для серверов NTP, о которых известно, что они очень точны, такими, на которых используется специальное оборудование точного времени.

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

По умолчанию сервер NTP будет доступен всем хостам в Интернет. Параметр restrict в файле /etc/ntp.conf позволяет вам контролировать, какие машины могут обращаться к вашему серверу. Если вы хотите запретить всем машинам обращаться к вашему серверу NTP , добавьте следующую строку в файл /etc/ntp.conf :

restrict default ignore

Если вы хотите разрешить синхронизировать свои часы с вашим сервером только машинам в вашей сети , но запретить им настраивать сервер или быть равноправными участниками синхронизации времени, то вместо указанной добавьте строчку:

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

где 192.168.1.0 является IP адресом вашей сети, а 255.255.255.0 её сетевой маской. /etc/ntp.conf может содержать несколько директив restrict.

Для корректной и более точной работы демона, желательно выбрать сервера уровня - от stratum 2 (можно конечно stratum1, но придется убить время на поиски такого сервера) и из выбранных stratum 2 те, до которых минимальное "расстояние". Обычно такие сервера могут предоставляться вашим провайдером. Количество выбираемых серверов желательно - более 2-х 3-х, чем больше тем лучше, но в разумных пределах. Если Вам лень выбирать лучшие сервера, то можно взять список открытых серверов второго уровня отсюда: http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers.

Выбираем список эталонных NTP серверов

Идем по указанному адресу (http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers) и подбираем список начальных серверов. Из данного списка выбираем удовлетворяющий нашим требованиям серверы, с помощью анализа вывода команды ntpdate . При выполнении команды, применяется следующий синтаксис:

ntpdate параметры серверы_через_пробел

Для того чтобы наш запрос не вносил изменения в систему, необходимо использовать параметр -q, который указывает на использование запроса без внесения изменений. Так же, возможно использовать ключ -d, указывающий, что команда будет выполняться в отладочном режиме, с выводом дополнительных сведений, без внесения реальных изменений (при данном ключе выводится куча другого мусора:), который нам в данный момент не нужен). Остальные параметры можно посмотреть в man 8 ntpdate . Из указанной ссылки я выбрал все сервера Open Access, расположенные в России (RU) + тот, который предоставил провайдер и запустил команду, получилось примерно следующее:

Ntp-server:~# ntpdate -q ntp2.ntp-servers.net ntp1.vniiftri.ru ntp2.vniiftri.ru ntp4.vniiftri.ru ntp0.ntp-servers.net ntp1.ntp-servers.net ntp3.vniiftri.ru ntp.corbina.net server 88.147.255.85, stratum 1, offset 0.006494, delay 0.09918 server 62.117.76.142, stratum 1, offset 0.002552, delay 0.06920 server 62.117.76.141, stratum 1, offset 0.003147, delay 0.06918 server 62.117.76.140, stratum 1, offset 0.004823, delay 0.07350 server 88.147.254.228, stratum 1, offset -0.002355, delay 0.12030 server 88.147.254.229, stratum 1, offset -0.000922, delay 0.10577 server 62.117.76.138, stratum 1, offset 0.005331, delay 0.07401 server 195.14.40.141, stratum 2, offset 0.002846, delay 0.07188 13 Jan 19:14:09 ntpdate: adjust time server 62.117.76.141 offset 0.003147 sec

В примере наши сервера удачно выдали уровень stratum1, что не может не радовать (кроме сервера провайдера ), offset - это расхождение во времени с этим сервером в секундах, delay - задержка синхронизации в секундах. Обычно, бО льшая точность получается при использовании серверов, которые имеют низкую задержку передачи пакетов по сети. Для выявления этого, возможно воспользоваться . Соответственно, выбрав сначала те, у которых время ответа меньше, а из них - те, до которых меньше хопов. Я же, чтобы не терять время, воспользуюсь всем указанными серверами и впишу их в конфигурационный файл. Итого, зная все вышеперечисленное, опишу свой получившийся файл /etc/ntp.conf :

Ntp-server:~# cat /etc/ntp.conf # Сервера локальной сети (закомментированы, не используются - в сети один сервер) #server 192.168.0.2 #server 192.168.0.5 # интернет-сервера server ntp2.ntp-servers.net server ntp1.vniiftri.ru server ntp2.vniiftri.ru server ntp4.vniiftri.ru server ntp0.ntp-servers.net server ntp1.ntp-servers.net server ntp3.vniiftri.ru server ntp.corbina.net # Файлы сервера driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntpstats # ограничение доступа к серверу: # по умолчанию игнорируем все restrict default ignore # локалхост без параметров - значит разрешено все. Параметры идут только на запреты. restrict 127.0.0.1 # далее описываются сервера с которыми мы синхронизируемся в локальной сети. # Разрешаем им все кроме трапов и запросов к нам restrict 192.168.0.2 noquery notrap restrict 192.168.0.5 noquery notrap # для локалки так же разрешаем все, кроме трапов и модификаций restrict 192.168.0.1 mask 255.255.255.0 nomodify notrap nopeer # разрешаем внешним источникам времени доступ: restrict ntp2.ntp-servers.net restrict ntp1.vniiftri.ru restrict ntp2.vniiftri.ru restrict ntp4.vniiftri.ru restrict ntp0.ntp-servers.net restrict ntp1.ntp-servers.net restrict ntp3.vniiftri.ru restrict ntp.corbina.net # а этот хак, который выставляет уровень доверия серверу (strata) самому себе равный 3 # в двух словах чем выше уровень-тем меньше число. 0 - это атомные часы, # 1 - это синхронизированные с ними, 2 - с первым, и так далее. server 127.127.1.1 fudge 127.127.1.1 stratum 3

Для более углубленного понимания и настройки сервера, опишу некоторые параметры конфигурации ntpd, о которых не упоминал::

  • enable/disable auth/monitor/pll/pps/stats - включить/выключить режим работы :
    • auth - с неупомянутыми соседями общаться только в режиме аутентификации;
    • monitor - разрешить мониторинг запросов;
    • pll - разрешить настраивать частоту местных часов по NTP;
    • stats - разрешить сбор статистики;
  • statistics loopstats - при каждой модификации локальных часов записывает строчку в файл loopstats ;
  • statistics peerstats - каждое общение с соседом записывается в журнал, хранящийся в файле peerstats ;
  • statistics clockstats - каждое сообщение от драйвера локальных часов записывается в журнал, хранящийся в файле clockstats ;
  • statsdir {имя_каталого_со_статистикой} - задает имя каталога, в котором будут находится файлы со статистикой сервера;
  • filegen - определяет алгоритм генерации имен файлов, которые состоят из:
    • префикс - постоянная часть имени файла, задается либо при компиляции, либо специальными командами конфигурации;
    • имя файла - добавляется к префиксу без косой черты, две точки запрещены, может быть изменена ключем file;
    • суффикс - генерируется в зависимости от typename;
  • restrict numeric-address - задает ограничение доступа: пакеты сортируются и маскам, берется исходный адрес и последовательно сравнивается, от последнего удачного сравнения берется флаг доступа:
    • нет флагов - дать доступ;
    • ignore - игнорировать все пакеты;
    • noquery - игнорировать пакеты NTP 6 и 7 (запрос и модификация состояния);
    • nomodify - игнорировать пакеты NTP 6 и 7 (модификация состояния);
    • limited - обслуживать только ограниченное количество клиентов из данной сети;
    • nopeer - обслуживать хост, но не синхронизироваться с ним;
  • clientlimit limit - для флага limited определяет максимальное количество обслуживаемых клиентов (по дефолту 3);

Итого, мы получили ntpd-server , который синхронизируется с внешним миром, позволяет получать время для клиентов из локальной сети 192.168.0.1 с маской 255.255.255.0, а так же может синхронизироваться с локальным сервером (если раскомментировать несколько строк). Нам осталось настроить клиентов и узнать, как наблюдать за нашим сервером.

Наблюдение за сервером ntpd и за синхронизацией

Когда у вас все настроено. NTP будет держать время в синхронизированном состоянии. Этот процесс можно наблюдать при помощи команды NTP Query (ntpq):

Ntp-server:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== -n3.time1.d6.hsd .PPS. 1 u 34 64 177 70.162 2.375 8.618 +ntp1.vniiftri.r .PPS. 1 u 33 64 177 43.479 -0.020 10.198 *ntp2.vniiftri.r .PPS. 1 u 6 64 177 43.616 -0.192 0.688 +ntp4.vniiftri.r .PPS. 1 u 4 64 177 43.623 0.440 0.546 -n1.time1.d6.hsd .PPS. 1 u 53 64 77 92.865 -11.358 38.346 -ns1.hsdn.org .GPS. 1 u 40 64 177 78.057 -3.292 35.083 -ntp3.vniiftri.r .PPS. 1 u 44 64 77 47.667 2.292 2.611 -scylla-l0.msk.c 192.43.244.18 2 u 62 64 77 41.565 -1.564 28.914

Данная команда с ключом -p выводит на стандартный вывод список источников времени с их характеристиками (остальные параметры команды в man ntpq). Значение каждой колонки следующее:

Имя удаленного NTP-сервера. Если указать ключ -n, вы получите IP-адреса серверов вместо имён.

Указывает, откуда каждый сервер получает время в данный момент. Это может быть имя хоста или что-то вроде.GPS., указывающее на источник глобальной системы позиционирования (Global Positioning System).

Stratum (уровень) это число от 1 до 16, указывающее на точность сервера. Единица означает максимальную точность, 16 -- сервер недоступен. Ваш уровень будет равен уровню наименее точного удаленного сервера плюс 1.

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

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

Количество времени (в секундах) необходимого для получения ответа на запрос "который час? ".

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

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

Значение знаков перед именами серверов

x - фальшивый источник по алгоритму пересечения;
. - исключён из списка кандидатов из-за большого расстояния;
- - удалено из списка кандидатов алгоритмом кластеризации;
+ - входит в конечный список кандидатов;
# - выбран для синхронизации, но есть 6 лучших кандидатов;
* - выбран для синхронизации;
o - выбран для синхронизации, но используется PPS;
пробел - слишком большой уровень, цикл или явная ошибка;

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

Проверить возможность синхронизации локально на сервере возможно командой:

Ntp-server:~# ntpdate -q localhost server 127.0.0.1, stratum 2, offset -0.000053, delay 0.02573 server::1, stratum 2, offset -0.000048, delay 0.02571 14 Jan 14:49:57 ntpdate: adjust time server::1 offset -0.000048 sec

Из вывода команды видно, что наш сервер уже стал уровня stratum 2. Для достижения данного уровня, необходимо некоторое время. Возможно, в первые 10-15 минут уровень сервера будет выше.

О корректной работе сервера ntp можно так же судить по логам демона ntpd:

Ntp-server:~# cat /var/log/ntpstats/ntp 13 Jan 20:13:16 ntpd: Listening on interface #5 eth0, fe80::a00:27ff:fec1:8059#123 Enabled 13 Jan 20:13:16 ntpd: Listening on interface #6 eth0, 192.168.0.8#123 Enabled 14 Jan 14:31:00 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 14:31:10 ntpd: time reset +10.291312 s 14 Jan 14:31:10 ntpd: kernel time sync status change 0001 14 Jan 14:34:31 ntpd: synchronized to 88.147.255.85, stratum 1 14 Jan 14:36:04 ntpd: synchronized to 62.117.76.141, stratum 1 14 Jan 15:04:36 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 15:10:58 ntpd: synchronized to 62.117.76.140, stratum 1 14 Jan 15:17:54 ntpd: no servers reachable 14 Jan 15:31:49 ntpd: synchronized to 62.117.76.140, stratum 1 14 Jan 15:32:14 ntpd: time reset +13.139105 s

Настройка netfilter (iptables) для NTP сервера

Настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 123/udp порту, при этом запросы так же отправляются с порта 123/udp. Ознакомившись со статьей, и ознакомившись с практическими , можно создать правила фильтрации сетевого трафика:

Ntp ~ # iptables-save # типовые правила iptables для DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к NTP серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 123 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ NTP серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW -j ACCEPT COMMIT

Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.

Настройка клиентских машин

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

0 * * * * /usr/sbin/ntpdate -s

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

Server restrict default ignore restrict noquery notrap restrict 127.0.0.1 nomodify notrap

Думаю, в данном конфиге все понятно: источник времени (server) - локальный ntpd-сервер, доступ всем запретить, разрешить только локальному ntpd-серверу.

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

Для настройки NTP клиента Windows , необходимо выполнить в консоли следующие команды:

C:\>net time /setsntp: The command completed successfully. C:\>net stop w32time The Windows Time service is stopping. The Windows Time service was stopped successfully. C:\>net start w32time The Windows Time service is starting. The Windows Time service was started successfully. C:\>net time /querysntp The current SNTP value is: The command completed successfully.

Заключение

Ну вроде все! Объем статьи получился громадным... Даже сам не ожидал. Подведу маленький итог изложенному. В данной статье нам, надеюсь, стало понятно что есть и как работает NTP-сервер. Научились настраивать сервер и клиентов на UNIX и Windows машинах. В нескольких словах, структура синхронизации времени в локальной сети следующая: Имеется 1,2 или более серверов точного времени в локальной сети, они синхронизируют свое время с внешними источниками в глобальной сети. Настройки сервера и клиентов основаны на файлах /etc/ntp.conf (основной конфигурационный файл демона ntpd), /etc/localtime (файл текущего часового пояса), а так же /etc/sysconfig/ntp (для RH) и /etc/default/ntp (для Deb) - файлы параметров запуска демона. Для локального ntp-сервера в конфигурационном файле указываются внешние сервера для получения времени и разрешается доступ для этих серверов параметром restrict, а так же для компьютеров локальной сети, для клиентов указывается источник времени - локальные сервера в локальной сети, а так же запрещается доступ для всех, кроме источника времени в локальной сети. Все. Всем спасибо за внимание! Буду рад комментариям!

  • (архив статьи) описано, как подключить GPS к серверу для организации своего сервера точного времени уровня Stratum1.
  • описано, как настроить авторизацию на ntp-сервере.

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

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 без дополнительной оплаты.

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

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

Протокол NTP работает на основе протокола UDP , через 123 порт.

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

Уровень 1 присваивается системе, которая синхронизируется с высокоточными часами, например через GPS.

Система, которая будет синхронизировать с Уровня 1, будет иметь Уровень 2, и так далее.

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

В нашей ситуации у нас в сети есть машина с точным временем, у меня она настроена на основе FreeBSD, с этой машины, главное сетевое устройство будет брать время (синхронизировать), и тем самым будет становиться главным для других сетевых устройств (в идеологии cisco будет ntp мастером).

Хочу отметить тот факт, что по NTP передается время только в формате UTC (Гринвич) , каждая тайм зона настраивается не посредственно на железке.

Давайте рассмотрим пример простой настройки NTP.

Для начала синхронизируем время на нашем главном роутере (который будет раздавать другим сетевым устройствам).Для этого заходим в режиме глобальной конфигурации:

ntp server 10.0.100.254

где, 10.0.100.254 в нашем случае это машина с FreeBSD, имеющая точное время.

Этого достаточно для минимальной настройки.

Теперь проверим, смогли ли мы подключиться к серверу времени и получить с него время, для этого используем команду:

должны увидеть нечто подобное:

Звездочка напротив ip нашего ntp сервера, говорит нам, что все хорошо, связь по крайней мере установлена.

Теперь посмотрим, синхронизировалось ли время?

Если все синхронизировалось, то мы должны увидеть следующее:

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

clock timezone MSK/MSD 3
Теперь давайте проверим время:

Все замечательно.

Перейдем к настройке нашего роутера в режим мастера.

Для этой настройки, нам необходимо что данный роутер мастер и указать уровень (в cisco он зовется как stratum number), тот самый, о котором я говорил в начале, я укажу уровень пятый.

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

ntp server 10.0.100.1 prefer

где, 10.0.100.1 это наш головной роутер.

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

так же мы указываем нужную нам таймзону.

clock timezone MSK/MSD 3

Проверяем:

Все замечательно, все работает.

Теперь рассмотрим вопрос безопасности.

Для начала, разберем вопрос по ограничению с помощью ACL, кто может синхронизировать, а кто нет.

Все достаточно стандартно и прозрачно.

На сервере времени создаем соответствующий ACL:

access-list 20 remark ACCESS to NTP Sync access-list 20 permit 10.0.100.3

теперь привяжем этот список доступа к ntp.

ntp access-group serve-only 20

Если все настроено верно, то связь с ntp севером установится и синхронизация пройдет успешно.

Так же дополнительно можно прописать на клиентах список доступа. К каким серверам времени можно обращаться. Делается это похожим способом:

access-list 20 remark ACCESS SYNC to NTP Serv access-list 20 permit 10.0.100.1

Привяжем список доступа к NTP

ntp access-group peer 20

Теперь рассмотрим безопасность на основе аутентификации.

Все также достаточно прозрачно.

В конфигурацию ntp достаточно добавить следующее:

ntp authentication-key 1 md5 15060E1F10243F34 7 ntp authenticate ntp trusted-key 1
первой командой мы задаем ключ аутентификации, второй включаем аутентификацию, а третей указываем что аутентификацию проводить по первому ключу.Настраиваем это на каждой из сторон (сервер — клиент).Вот собственно и все. Получилась небольшой вводный курс по настройке NTP на Cisco устройствах.Для отладки используем:
ASW-M#debug ntp ? adjust NTP clock adjustments authentication NTP authentication events NTP events loopfilter NTP loop filter packets NTP packets params NTP clock parameters refclock NTP reference clocks select NTP clock selection sync NTP clock synchronization validity NTP peer clock validity ASW-M#debug ntp
Включаем все что нам интересно, например events, sync, auth и смотрим что происходит.Если мы зашли на устройство через ssh/telnet не забываем ter mon 🙂

Зачем нужно точное время?

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

Протокол NTP

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

Существует несколько версий этого протокола, имеющих некоторые отличия. Третья версия этого протокола в 1992 году была стандартизирована как RFC 1305. Четвертая (последняя на данный момент) версия привносит некоторые улучшения (автоматическая конфигурация и аутентификация, улучшение алгоритмов синхронизации) по сравнению с третьей, однако она еще не стандартизирована в RFC.

Кроме того, помимо протокола NTP, существует протокол SNTP (Simple Network Time Protocol). На уровне пакетов эти два протокола полностью совместимы. Основным отличием между ними является то, что SNTP не имеет сложных систем фильтрации и многоступенчатой корректировки ошибок, имеющихся в NTP. Таким образом, SNTP является упрощенной и более легкой в реализации версией NTP. Он предназначен для использования в тех сетях, где не требуется очень высокая точность времени, и в реализации от корпорации Microsoft обеспечивает точность в пределах 20 секунд в рамках предприятия и не более 2 секунд в пределах одного сайта. Протокол SNTP стандартизован как RFC 1769 (версия 3) и RFC 2030 (версия 4).

Модель синхронизации NTP предполагает иерархическую структуру. На первом уровне иерархии располагаются так называемые «первичные» серверы времени (First stratum). Они находятся в разных местах по всему миру и располагают самым точным временем. Таких серверов относительно немного, так как точное время на них поддерживается с помощью дорогостоящего специализированного оборудования (радиоканал, спутниковый канал). Серверы второго уровня (Second stratum) синхронизируются с серверами первого уровня, используя протокол NTP. Их уже значительно больше, однако они уже несколько рассинхронизированы (от 1 до 20 миллисекунд) относительно «первичных» серверов. Далее могут идти серверы третьего, четвертого и последующих уровней:

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

Для синхронизации времени в ОС Windows 2000/XP/2003 используется протокол SNTP. Поддержка этого протокола реализована в виде системной службы Windows Time, входящей в состав операционной системы MS Windows 2000/XP/2003. Отличительной особенностью этой реализации является то, что служба Windows Time поддерживает доменную аутентификацию при обращении к эталонному серверу времени, что является немаловажным с точки зрения безопасности.

Существует несколько вариантов работы службы SNTP, входящей в Windows:

  • Иерархическая (NT5DS). Используется по умолчанию для всех компьютеров, объединенных в домен. Синхронизация времени на рабочих станциях и серверах домена производится по иерархии. Таким образом, рабочие станции и рядовые серверы синхронизируются с контроллером домена, аутентифицировавшим вход, контроллеры домена – с хозяином операции «эмулятор PDC», который в свою очередь синхронизируется с контроллером домена, стоящим на более высоком уровне иерархии. Следует заметить, что данный порядок синхронизации используется «по умолчанию» и может быть переопределен вручную или с использованием групповых политик. О том, как это сделать, будет рассказано ниже.
  • Принудительная синхронизация с выбранным NTP-сервером (NTP). В данном случае источник эталонного времени для службы Windows Time устанавливается либо вручную, либо с помощью групповых политик.
  • Отключение синхронизации (NoSync). Этот режим необходим для смешанной схемы поддержания времени, в которой для синхронизации с внешним источником используется продукт третьей фирмы, а для поддержания времени в рамках домена используется Windows Time.

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

Для домена рекомендуется использовать иерархическую синхронизацию по протоколу SNTP. В большинстве случаев она обеспечивает приемлемую точность системного времени в рамках леса домена. Кроме того, она автоматически обеспечивает безопасность обновления времени, благодаря поддержке аутентификации с Active Directory. Для поддержки «правильного» времени в домене необходимо синхронизировать контроллер домена верхнего уровня, владеющий ролью «эмулятор PDC», с внешним NTP-сервером. В нашем примере в роли такого сервера будет выступать Linux-машина с работающим демоном ntpd.

Настройка SNTP в Windows

Для настройки службы Windows Time используются две утилиты:

  • Net time
  • W32tm

Net time используется главным образом для конфигурирования службы времени, а w32tm – для мониторинга и диагностики работы. Однако в Windows XP/2003 утилита w32tm претерпела существенные изменения и может быть использована для конфигурации службы времени. Настройка NTP далее будет проводиться на примере Windows XP/2003.

Итак, для того чтобы «вручную» указать источник синхронизации с помощью net time, достаточно написать в командной строке:

et time /setsntp:список_серверов_времени_через_пробел

Для получения информации о текущем сервере времени:

net time /querysntp

Узнать время на контроллере домена можно так:

net time /domain:имя_домена

А синхронизировать время с контроллером домена вот так:

Net time /domain:имя_домена /set

Системной утилитой w32tm можно сделать все то же самое и даже больше:

  • w32tm /resync – при помощи этой команды можно заставить локальный или удаленный компьютер синхронизировать показания своих системных часов с используемым им сервером времени.
  • w32tm /config – эта команда используется для конфигурирования службы Windows Time. С ее помощью можно задать список используемых серверов времени и тип синхронизации (иерархическая или выбранная серверами).

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

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

А для того чтобы Windows Time применила новые настройки, вместо перезапуска службы можно использовать команду:

w32tm /config /update

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

  • w32tm /monitor – при помощи этой опции можно узнать, насколько системное время данного компьютера отличается от времени на контроллере домена или других компьютерах.
  • w32tm /stripchart – графически показывает разницу во времени между текущим и удаленным компьютером.
  • w32tm /register – регистрирует службу Windows Time в качестве службы на данном компьютере. Эта опция может быть полезна на компьютерах, не входящих в домен, так как по умолчанию на них служба времени остановлена.

Более подробные сведения о параметрах утилит net time и w32tm можно получить, используя ключ /? или открыв соответствующий раздел справочной системы «Help and Support Center» MS Windows XP/2003.

Нетрудно догадаться, что настройки службы Windows Time хранятся в реестре Windows в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

В корне раздела определяются параметры работы самой службы, в подключе Config – настройки, связанные с работой самого протокола SNTP, режим синхронизации определяется в подключе Parameters. Настройки SNTP клиента и сервера находятся в подключах TimeProviders\NtpClient и TimeProviders\NtpServer соответственно. Рассмотрим основные значения, определяющие настройку NTP клиента и сервера:

  • Type – определяет режим работы NTP-клиента (NTDS5 – иерархическая, NTP – «вручную», NoSync – не синхронизировать, AllSync – доступны все типы синхронизации);
  • Enabled – определяет, включен ли данный компонент (клиент или сервер);
  • CrossSiteSyncFlags – определяет, можно ли синхронизировать время с источником, находящимся за пределами домена, в случае если используется иерархическая синхронизация (0 – нельзя, 1 – только с эмулятором PDC, 2 – со всеми);
  • EventLogFlags – определяет, будут ли сообщения от Windows Time заноситься в журнал или нет (очень полезная функция при отладке работы).

Другой вариант настройки службы времени Windows Time – использование групповых политик. Настройки определяются в объекте групповой политики по следующему адресу: «Computer Configuration –> Administrative Templates –> System –> Windows Time Service».

Если у вас установлен Windows 2000 Server и такой настройки вы не нашли – не отчаивайтесь, вам просто нужно обновить «Административные шаблоны». Для этого скопируйте из системной папки system32\GroupPolicy\Adm любой машины с установленной Windows XP все.adm-файлы на сервер, являющийся контроллером домена. Далее, определяя объект групповой политики, нажмите правой кнопкой на «Administrative templates» и выберите «Add/Remove templates…» Удалите перечисленные там шаблоны и добавьте скопированные. После нажатия кнопки «OK» шаблоны будут обновлены, и вы сможете сконфигурировать службу времени, используя групповые политики:

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

В ОС Windows XP появился еще один способ задания сервера времени, который может быть очень удобен для настройки синхронизации на домашнем компьютере или компьютере, входящем в рабочую группу:

NTP-сервер под Linux – внешняя синхронизация для Windows-домена

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

Существует масса программ для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd, входящий в состав Redhat 9, поставляемый в пакете ntp-4.1.2-0.rc1.2.i386.rpm.

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

Вот основные из них:

  • Ntpd – демон ntp, поддерживающий точное время в фоновом режиме;
  • Ntpq – утилита, предназначенная для опроса NTP-серверов, поддерживающих стандартный протокол опроса NTP mode 6. С ее помощью можно узнать и изменить текущее состояние сервера, если его настройки это позволяют;
  • Ntptdc – утилита, при помощи которой можно опрашивать демон ntpd и получать статистику его работы;
  • Ntpdate – программа для установки текущего системного времени с использованием протокола NTP.

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

В случае использования симметричной схемы аутентификации клиент и сервер выбирают произвольный идентификатор и один из 65534 ключей, определенных стандартом. При использовании несимметричных алгоритмов, используется так называемая схема Autokey, отличительной особенностью которой является отсутствие необходимости предварительно распределять открытые ключи серверов.

Для настройки аутентификации в ntpd существуют утилиты ntp-genkeys, ntpq и ntpdc.

Вся функциональность NTP, связанная с поддержкой точного времени, реализована в демоне ntpd. Его настройка производится обычным для UNIX способом – путем редактирования конфигурационного файла ntp.conf, находящегося в папке /etc.

Зададим следующие опции для работы NTP-сервера.

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

server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net

restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Здесь маска 255.255.255.255 используется для ограничения доступа к нашему серверу со стороны сервера ntp.nasa.gov. Теперь определим список узлов в нашей локальной сети, которым мы хотим разрешить доступ к нашему NTP-серверу для получения времени:

restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

Также нам требуется, чтобы Linux-машина имела полный доступ к ресурсам своего сервера:

restrict 127.0.0.1

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

#restrict default ignore

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

# ntpdate clock.vsu.ru
17 Feb 23:44:54 ntpdate: step time server 198.123.30.132 offset 25.307598 sec

17 Feb 23:45:05 ntpdate: adjust time server 198.123.30.132 offset 0.002181 sec
# ntpdate clock.vsu.ru

Запуск ntp-демона производится через инициализационные скрипты. Если программа устанавливалась из rpm-пакета, то скорее всего все вопросы, связанные с ее автоматическим запуском, уже решены. Для того чтобы в этом убедиться, можно воспользоваться командой:

# chkconfig -list ntpd
ntpd 0:on 1:off 2:off 3:on 4:off 5:on 6:off

Если вы не видите этой строки, значит, автоматический запуск ntpd не настроен. Чтобы это исправить, наберите:

# chkconfig –level 035 ntpd on

Для управления NTP (старт, запуск, перезапуск, статус) используются стандартный инициализационный скрипт:

# /etc/init.d/ntpd start

Для просмотра статистики синхронизации сервера можно воспользоваться следующей командой:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220.00 0.149 7.08
-navobs1.wustl.e .PSC. 1 u 55 64 377 193.47 6.857 4.81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254.88 7.471 9.58
-ntp0.NL.net .GPS. 1 u 144 512 377 122.54 12.515 13.75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133.94 14.594 41.99
+timekeeper.isi. .GPS. 1 u 13 64 377 245.30 3.454 15.08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37.51 -3.239 11.14
LOCAL(0) LOCAL(0) 10 l - 64 377 0.00 0.000 10.01

Режимы работы NTP сервера/клиента

Клиент/сервер

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

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

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

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

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

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Часто возникающие вопросы

Почему после команды net time /setsntp:server время не синхронизируется?

Убедитесь, что для службы w32time задан тип запуска «Автоматически».
Убедитесь, что порт UDP 123 используемого NTP-сервера доступен.
Убедитесь, что время между клиентом и сервером не отличается слишком сильно.

Может ли SNTP-клиент синхронизироваться с NTP-сервером?

Да, может, так как протокол SNTP является подмножеством NTP и полностью с ним совместим.

Можно ли использовать NTP-сервер от третьих производителей в ОС Windows 2000/XP/2003?

Да, можно воспользоваться любым сервером, платным или бесплатным. Предварительно следует отключить соответствующие компоненты (клиентские или серверные) службы Windows Time.

Почему NTP-клиент не работает на компьютере с установленным MS SQL Server?

Скорее всего проблема заключается в том, что SQL Server каким-либо образом занимает порт UDP 123. В качестве решения можно предложить запуск клиента NTP до MS SQL Server.

Демона ntpd после запуска работает 10-20 минут, после чего останавливается. В чем может быть проблема?

Убедитесь, что время клиента и сервера отличается не слишком сильно (не более 5 минут). В противном случае выполните принудительную синхронизацию при помощи ntpdate.

Можно ли синхронизировать время в OS Windows NT4, 95, 98, Me?

Можно, при помощи программ третьих фирм, например, NetTime, Automacahron, World Time5, ntpd Windows NT port.

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

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

Похожие публикации