🥇 Как синхронизацията на времето стана безопасна

Как да направите времето per se да не лъже, ако имате милион големи и малки устройства, взаимодействащи по TCP/IP? В края на краищата, на всяко от тях има часовник, а времето трябва да бъде вярно навсякъде. Тази проблема не може да бъде избегната без ntp.

Да си представим за миг, че в един сегмент на индустриалната ИТ инфраструктура възникват затруднения с времевата синхронизация на услугите. Незабавно започва да се срива кластерният стек на Enterprise софтуера, домейните се разпадат, майсторските и резервните възли безуспешно се опитват да възстановят status quo.

Възможна е и ситуация, при която злонамерен потребител умишлено се опитва да наруши времето чрез MiTM или DDOS атака. В такава ситуация може да се случи всичко:

да изтече срокът на паролите на потребителските акаунти;
да изтече срокът на X.509 сертификатите;
двуфакторната автентикация TOTP да спре да работи;
бекъпите да „остареят“ и системата да ги изтрие;
да се счупи DNSSec.

Разбира се, всеки ИТ отдел е заинтересован от надеждното функциониране на услугите за времева синхронизация, и би било добре те да бъдат надеждни и безопасни в индустриална експлоатация.

Да се счупи NTP за 25 минути

Мрежовите протоколи — милениалите имат едно свойство, те отдавна остарели и вече не стават, но тяхната замяна не е толкова лесна дори когато се събере критична маса от ентусиасти и финансиране.

Основната претенция към класическия NTP е липсата на надеждни механизми за защита от атаки на злонамерени потребители. Бяха направени разнообразни опити за решаване на този проблем. Първо беше внедрен механизъм за предварително установени ключове (PSK) за обмен на симетрични ключове.

За съжаление, този метод не оправда очакванията поради простата причина — той не се мащабира добре. Изисква ръчна конфигурация на клиента в зависимост от сървъра. Това означава, че не може просто така да добавите още един клиент. Ако на NTP сървъра нещо се променя, трябва да се пренастроят всички клиенти.

Тогава беше измислен AutoKey, но веднага в него бяха открити редица сериозни уязвимости в самия дизайн на алгоритъма и от него се наложи да се откажат. Всичко се дължи на факта, че началното число (seed) съдържа само 32 бита, което е твърде малко и не осигурява достатъчно изчислителна сложност за атака с груба сила.

Key ID — симетричен 32-битов ключ;
MAC (код для аутентификации сообщения) — контрольная сумма NTP пакета;

Autokey се изчислява по следния начин.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Където H() е криптографска хеш функция.

За изчисляване на контролната сума на пакетите се използва същата функция.

MAC=H(Autokey||NTP пакет)

Получава се, че цялата цялост на проверките на пакетите се основава на автентичността на кукис. Завладявайки ги, може да се възстанови autokey и след това да се подправи MAC. Въпреки това, NTP сървърът при тяхната генерация използва начално число (seed). Именно тук се крие капанът.

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

Функцията MSB_32 отрязва 32-те най-горни бита от резултата на изчислението на md5 хеш. Клиентският куки не се променя, докато параметрите на сървера са неизменни. След това злоумышленникът само трябва да възстанови начално число и да получи възможност да генерира куки самостоятелно.

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

Алгоритъм на нападение за изчисляване на началното число с помощта на метод на проба и грешка.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

IP адресите са известни, така че остава само да се създадат 2^32 хеш-а, докато генерираният куки не съвпадне с този, получен от NTP сървъра. На обикновена домашна станция с Intel Core i5, това ще отнеме 25 минути.

NTS — нов Autokey

Беше невъзможно да се примирим с такива дупки в сигурността на Autokey и през 2012 г. се появи нова версия протокол. С цел да се избере компрометирано име, решиха да проведат ребрандиране, така Autokey v.2 нарекоха Network Time Security.

Протоколът NTS е разширение на сигурността на NTP и в момента поддържа само едноадресен режим (unicast). Той осигурява надеждна криптографска защита от манипулации на пакети, предотвратява проследяването, добре се мащабира, устойчив е на загуба на мрежови пакети и води до минимална загуба на точност, възникваща в процеса на защита на връзката.

NTS връзката се състои от два етапа, в които се използват протоколи от по-ниско ниво. На первия етап клиентът и сървърът се договарят по различни параметри на връзката и обменят куки, съдържащи ключове с целия съпъстващ набор от данни. На втория етап се извършва самата защитена NTS сесия между клиента и NTP сървъра.

NTS се състои от два протокола на ниско ниво: Network Time Security Key Exchange (NTS-KE), инициализация на защитена връзка върху TLS, и NTPv4 — последната версия на протокола NTP. Малко повече за това по-долу.

Първата стъпка — NTS KE

В този етап клиентът NTP инициализира сесия TLS 1.2/1.3 по отделно TCP свързване със сървера NTS KE. По време на тази сесия се случва следното.

Страните определят параметрите AEAD алгоритъм за втория етап.
Страните определят втория протокол на ниско ниво, но в момента се поддържа само NTPv4.
Страните определят IP адреса и порта на NTP сървера.
Сървърът NTS KE издава бисквитки под NTPv4.
Страните извлекат от материала бисквитки двойка симетрични ключове (C2S и S2C).

Такъв подход има голямо предимство, тъй като всяко натоварване по предаването на защитната информация за параметрите на връзката се поема от проверен и надежден протокол TLS. Така отпада необходимостта да се изобретява собствен велосипед за безопасно NTP ръкостискане.

Втората стъпка — NTP защитен от NTS

На втория етап клиентът безопасно синхронизира времето с NTP сървера. За тази цел той предава четири специални разширения (extension field) в структурата на NTPv4 пакета.

Unique Identifier Extension съдържа случайно nonce, за да се предотвратят атаки чрез повторение.
NTS Cookie Extension съдържа една от наличните бисквитки на клиента NTP. Тъй като само клиентът разполага със симетричните AAED ключове C2S и S2C, NTP сървърът трябва да ги извлече от материала на бисквитката.
NTS Cookie Placeholder Extension е начин за клиента да поиска допълнителни бисквитки от сървера. Това разширение е необходимо, за да не е отговорът на NTP сървъра значително по-дълъг от заявката. Това позволява да се предотвратят атаки на усилване.
NTS Authenticator and Encrypted Extension Fields Extension съдържа шифър на алгоритъма AAED с C2S ключа, NTP заглавие, времеви отметки и споменатите по-горе EF като съпътстващи данни. Без това разширение е възможно манипулиране на времевите отметки.

Получавайки заявка от клиента, сървърът проверява автентичността на NTP пакета. За целта той трябва да дешифрира бисквитките, да извлече алгоритъма AAED и ключовете. След успешна проверка на валидността на NTP пакета, сървърът отговаря на клиента в следния формат.

Unique Identifier Extension е зеркално копие на клиентската заявка, мярка срещу атаки чрез повторение.
NTS Cookie Extension още бисквитки за продължаване на сесията.
Разширението NTS Authenticator и шифровани полета на разширения съдържат шифър AEAD с ключ S2C.

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

NTPSec

Каква е особеността на NTP? Въпреки че авторът на проекта Дейв Милс се е опитвал да документира своето код, рядък програмист може да разбере сложностите на алгоритмите за синхронизация на времето с 35-годишна давност. Част от кода е написана преди епохата на POSIX, а Unix API тогава много се различаваше от това, което се използва днес. Освен това, нужни са знания по статистика, за да се очисти сигналът от смущения на шумни линии.

NTS не беше първият опит да се поправи NTP. След като хакерите научиха как да използват уязвимостите на NTP за усилване на DDoS атаки, стана ясно, че са необходими радикални промени. Докато се подготвяха и усъвършенстваха черновите на NTS, National Science Foundation на САЩ спешно одобри грант в края на 2014 г. за модернизация на NTP.

Работната група беше оглавена от не кой да е, а Ерик Стивън Реймонд — един от основателите и стълбовете на общността Open Source и автор на книгата Кафене и Базар. Първото нещо, което Ерик и колегите му опитаха, беше да прехвърлят кода на NTP от платформата BitKeeper на git, но не успяха. Лидерът на проекта Харлан Стен беше против това решение и преговорите зациклиха. Тогава беше решено да се форкне кода на проекта, така се появи NTPSec.

Солидният опит, включително работа по GPSD, математическият фон и магическият талант да чел древен код — Ерик Реймонд беше именно този хакер, който можа да извади такъв проект. В екипа имаше специалист по миграция на код и за само 10 седмици NTP се настанив GitLab. Работата започна.

Екипът на Ерик Реймонд се захвана с проекта, както Огюст Роден с блок от камък. Премахвайки 175 KLOC стар код, успяха значително да намалят площта на атака, закривайки множество дупки в сигурността.

Ето непълен списък на попадналите под раздаването:

Недокументирани, остарели или повредени refclock.
Непотребна библиотека ICS.
libopts/autogen.
Стар код за Windows.
ntpdc.
Autokey.
C кодът на ntpq е пренаписан на Python.
C кодът на sntp/ntpdig е пренаписан на Python.

Освен почистването на кода, проектът имаше и други задачи. Ето непълен списък на постиженията:

Значително е подобрена защитата на кода от препълване на буфера. За предотвратяване на препълване на буфера, всички небезопасни низови функции (strcpy / strcat / strtok / sprintf / vsprintf / gets) са заменени с безопасни версии, които реализират ограничение на размера на буфера.
Добавена е поддръжка на NTS.
Десетократно е повишена точността на времевия интервал чрез свързване на физическо оборудване. Това се дължи на факта, че съвременните компютърни часовници са много по-точни от онези, съществували при създаването на NTP. Най-много от този напредък печелят GPSDO и специализирани радиостанции за време.
Броят на програмистките езици е намален до два. Вместо сценарии на Perl, awk и дори S, сега единствено Python. Това предоставя повече възможности за повторна употреба на кода.
Вместо непригодната система за автоматизация, проектът започна да използва система за изграждане на софтуер. waf.
Актуализирани и реорганизирани документацията на проекта. От противоречивата и местами остаряла колекция документи беше създадена нормална документация. Всеки ключ на командния ред и всяка конфигурационна единица вече имат единна версия на истината. Освен това, страниците на ръководството и уеб документацията сега се създават от едни и същи основни файлове.

NTPSec е наличен за множество дистрибуции на Linux. В момента последната стабилна версия е 1.1.8, а за Gentoo Linux — предпоследната.

(1:696)$ sudo emerge -av ntpsec
Това са пакетите, които ще бъдат сглобени, в следния ред:
Изчисляване на зависимости... готово!
[ebuild   R    ] net-misc/ntpsec-1.1.7-r1::gentoo  USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Общо: 1 пакет (1 преинсталация), размер на изтеглянията: 0 KiB
Искате ли да обедините тези пакети? [Да/Не]

Chrony

Имаше още една опит да се замени стария NTP с по-сигурен аналог. Chrony, за разлика от NTPSec, е написан от нулата и е предназначен за надеждна работа в широк спектър от условия, включително нестабилни мрежови връзки, частична наличност или натоварвания в мрежата и промени в температурата. Освен това chrony притежава и други предимства:

chrony може по-бързо да синхронизира системните часовници с по-голяма точност;
chrony е по-малък, консумира по-малко памет и се обръща към процесора само когато е необходимо. Това е голям плюс за икономия на ресурси и енергия;
chrony поддържа времеви печати на хардуерно ниво в Linux, което осигурява изключително точно синхронизиране в локални мрежи.

Въпреки това, в chrony липсват някои функции на стария NTP, като широковещателен и многоадресен (multicast) клиент/сървър. Освен това класическият NTP поддържа повече операционни системи и платформи.

За деактивиране на функционалността на сървера и NTP заявките към процеса chronyd е достатъчно да се запише port 0 в файла chrony.conf. Това се прави в случаите, когато няма нужда да се обслужва време за NTP клиенти или однорангови възли. От версия 2.0, портът на NTP сървъра е отворен само в случаите, когато достъпът е разрешен с директивата allow или със съответната команда, или когато е настроен однорангов възел NTP, или се използва директивата broadcast.

Програмата се състои от два модула.

chronyd — услуга, работеща във фонов режим. Тя получава информация за разликата между системните часовници и външния времеви сървър и коригира локалното време. Също така реализира протокола NTP и може да действа като клиент или сървър.
chronyc — команден инструмент за мониторинг и контрол на програмата. Използва се за фина настройка на различни параметри на услугата, например позволява добавяне или премахване на NTP сървъри, докато chronyd продължава да работи.

Започвайки от 7-ата версия на RedHat Linux използва chrony като услуга за синхронизация на времето. Пакетът е наличен и за останалите дистрибуции на Linux. Последната стабилна версия 3.5, подготвя се за излизане v4.0.

(1:712)$ sudo emerge -av chrony
Това са пакетите, които ще бъдат сляти, в ред:
Изчисляване на зависимости... готово!
[binary  N     ] net-misc/chrony-3.5-r2::gentoo  USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Общо: 1 пакет (1 нов, 1 бинарен), Размер на изтеглянията: 246 KiB
 Искате ли да слеете тези пакети? [Да/Не]

Как да настроите собствен сървър Chrony в интернет за синхронизация на времето в офисната мрежа. По-долу е пример за настройка на VPS.

Пример за настройка на Chrony на RHEL / CentOS на VPS

Сега нека да се упражним и да стартираме собствен NTP сървър на VPS. Това е много просто, достатъчно е да изберете подходящия тарифен план на сайта RuVDS, да получите готов сървър и да напишете десетина несложни команди. За нашите цели вариантът е напълно подходящ.

Преминаваме към настройката на услугата и първо инсталираме пакета chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 използват различен пакетен мениджър.

[root@server ~]$ dnf install chrony

След инсталацията на chrony трябва да стартирате и активирате услугата.

[root@server ~]$ systemctl enable chrony --now

Ако желаете, можете да направите промени в /etc/chrony.conf, заменяйки NPT сървърите с най-близките локални за намаляване на времето за реакция.

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst

След това настройваме синхронизацията на NTP сървъра с възлите от указаното пула.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

Необходимо е също така да отворите NTP порта, в противен случай защитната стена ще блокира входящите връзки от клиентските възли.

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

На страната на клиента е достатъчно правилно да настроите часовата зона.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

В файла /etc/chrony.conf посочете IP адреса или името на хоста на нашия VPS сървър, на който е стартиран NTP сървърът chrony.

server my.vps.server

И накрая, стартиране на синхронизацията на времето на клиента.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

Следващия път ще разкажа за опциите за синхронизация на времето без интернет.

Източник: habr.com