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

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

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

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

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

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

Да се провали NTP за 25 минути

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

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

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

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

Ключ 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, Националната научна фондация на САЩ в края на 2014 г. спешно осигури грант за модернизация на NTP.

Работната група беше ръководена от никого друг освен Ерик Стивън Реймонд — един от основателите и стълбовете на общността с отворен код и автор на книгата Кафе и базар. Първото, което Ерик и неговите колеги се опитаха, беше да прехвърлят кода на 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. Благодарение на това има повече възможности за повторно използване на кода.
Вместо заплетените скриптове autotools, проектът започна да използва система за компилация на софтуер. 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, подготвя се за пускане версия 4.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, замествайки NTP сървърите с най-близките локални за намаляване на времето за отговор.

# 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

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