Головна → Windows 10 Чим відрізняється протокол синхронізації часу NTP від \u200b\u200bSNTP? Дивитися що таке "NTP" в інших словниках Протокол ntp опис.

Чим відрізняється протокол синхронізації часу NTP від \u200b\u200bSNTP? Дивитися що таке "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 мс ) буде поставлена \u200b\u200bу відповідність величина -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 (первинний еталонний джерело), \u200b\u200bце 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) - мінімальне число партнерів, необхідне для синхронізації (при використанні алгоритму відбору).

Максимум обраних годин\u003e ( 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-повідомлення від різних партнерів. Подія може відбутися як результат команди оператора або виявленої помилки, такий, як відмова первинного еталона.

Доброго дня, гості та постійні читачі. Поступово переходжу від основ до більш поглибленого вивчення 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 \u003d true indicates that the clock is set to UTC; UTC \u003d true ntp2-server: ~ # cat / etc / default / rcS | grep UTC UTC \u003d 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 \u003d "- g"

# Cat / etc / sysconfig / ntpd # Parameters for NTP daemon. # See ntpd (8) for more details. .... # Specifies additional parameters for ntpd. NTPD_ARGS \u003d "- 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- дозволити збір статистики;
statisticsloopstats- за будь-якої модифікації локальних годин записує рядок у файл loopstats;
statisticspeerstats- кожне спілкування з сусідом записується в журнал, що зберігається в файлі peerstats;
statisticsclockstats- кожне повідомлення від драйвера локальних годин записується в журнал, що зберігається в файлі clockstats;
statsdir(Імя_каталого_со_статістікой) - задає ім'я каталогу, в якому будуть знаходиться файли зі статистикою сервера;
filegen - визначає алгоритм генерації імен файлів, які складаються з:
- префікс- постійна частина імені файлу, задається або при компіляції, або спеціальними командами конфігурації;
- ім'я файлу - додається до префікса без риски, дві точки заборонені, може бути змінена ключем file;
- суфікс- генерується в залежності від typename;
restrictnumeric-address- задає обмеження доступу: пакети сортуються і маскам, береться початкова адреса і послідовно порівнюється, від останнього вдалого порівняння береться прапор доступу:
- немає прапорів - дати доступ;
- ignore- ігнорувати всі пакети;
- noquery- ігнорувати пакети NTP 6 і 7 (запит і модифікація стану);
- nomodify- ігнорувати пакети NTP 6 і 7 (модифікація стану);
- limited- обслуговувати тільки обмежена кількість клієнтів з даної мережі;
- nopeer- обслуговувати хост, але не синхронізуватися з ним;
clientlimitlimit- для прапора 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 \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d -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: 4: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: \\\u003e net time / setsntp: The command completed successfully. C: \\\u003e net stop w32time The Windows Time service is stopping. The Windows Time service was stopped successfully. C: \\\u003e net start w32time The Windows Time service is starting. The Windows Time service was started successfully. C: \\\u003e 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-сервері.

Відповіді на питання

26.09.2018

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

NTP (Англ. Network Time Protocol - протокол мережевого часу) - мережевий протокол для синхронізації внутрішнього годинника комп'ютера з використанням мереж зі змінною пропускною спроможністю. Забезпечує високу точність синхронізації часу завдяки спеціальним алгоритмом, який дозволяє вибирати найбільш точні джерела для оцінки точного часу. Цей алгоритм дозволяє зводити до мінімуму вплив даних від свідомо некоректно налаштованих NTP-серверів на загальну систему. Протокол NTP забезпечує механізми синхронізації з точністю до наносекунд, і містить засоби для визначення характеристик та оцінки помилок локальних годин і тимчасового сервера, який здійснює синхронізацію. Протокол NTP використовує ієрархічну систему рівнів, або стратумов. Сервер NTP має найбільш високий рівень (стратум 1), якщо він отримує дані безпосередньо від джерела точного часу. Сервера, що синхронізують свій годинник з сервером 1-го стратума, знаходяться на рівні нижче (стратум 2), і т. Д.

SNTP (Англ. Simple Network Time Protocol - простий протокол мережевого часу) - протокол синхронізації часу по комп'ютерній мережі. Являє собою спрощену реалізацію протоколу NTP, в ньому відсутній складність алгоритму NTP. SNTP використовується для вузлів мережі, яким не потрібен повний набір функцій NTP. Загальноприйнятою практикою є синхронізація годин кількох вузлів локальної мережі з іншими вузлами NTP по Інтернет і використання цих вузлів для тимчасової синхронізації послуг, що надаються іншим клієнтам по локальній мережі. У такому варіанті використання не потрібно високої точності тимчасової синхронізації. Протокол SNTP забезпечує механізми синхронізації з точністю від 1 до 50 мс

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

Класичний приклад використання SNTP - синхронізація часу всередині домену. Контролер домену отримує час з глобальної мережі Інтернет від загальнодоступних серверів стратума 1 або стратума 2. Інші клієнти домену синхронізують свій годинник з часом на контролері домену. Орієнтовна архітектура відображена на схемі.

Навіщо потрібно точний час?

А кому взагалі потрібно це точний час? Звичайно, воно потрібно нам, користувачам, для того, щоб ми менше спізнювалися. Уявімо собі сучасний аеропорт - для його роботи сотні пілотів і диспетчерів повинні користуватися безпомилково йдуть годинами. Система реєстрації товарів на складах, лікарняні установи, каси з продажу залізничних квитків та багато інших установ вимагають, щоб час на всіх об'єктах системи в тій чи іншій мірі було однаково. Тим більше комп'ютери. На них працює маса служб і програм, для нормальної роботи яких необхідно точний час, причому, як правило, більш точне, ніж це зазвичай потрібно нам, людям. Системні служби, компоненти системи безпеки, та й просто прикладні програми можуть бути дуже критичні до точності годин. Найбільш яскравим прикладом таких служб є протокол аутентифікації 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 1 769 (версія 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 -\u003e Administrative Templates -\u003e System -\u003e 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 сервера / клієнта

Клієнт / сервер

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

режим Manycast

Часто виникають питання

Чому після команди 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. Для вирішення цієї проблеми потрібно або вручну підвести час, або не використовувати цей вид аутентифікацію при оновленні часу.

Завдання дізнатися точний час з деяких пір стоїть не тільки перед людиною. Безлічі систем, створених ним, для правильного функціонування необхідно постійно мати в своєму розпорядженні дуже точний годинник, причому їх точність повинна бути значно вище годин, використовуваних людьми в звичайному житті. Крім власне точності годин, не менш важливою є їхня синхронізація зі шкалою всесвітнього часу. Адже навіть в шкалу 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, в яких була заявлена \u200b\u200bпідтримка 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

Це цікаво: