🥇Як сінхранізацыя часу стала бяспечнай

Як зрабіць так, каб час per se не хлусіў, калі ў вас ёсць мільён вялікіх і малых прылад, якія ўзаемадзейнічаюць па TCP/IP? Бо на кожным з іх ёсць гадзіннік, а час павінен быць правільным на ўсіх. Гэтую праблему без ntp немагчыма абысці.

Уявім сабе на адну хвіліну, што ў адным сегменце прамысловай ІТ інфраструктуры ўзніклі цяжкасці з сінхранізацыяй сэрвісаў па часе. Неадкладна пачынае збаіць кластарны стэк Enterprise ПА, распадаюцца дамены, майстры і Standby вузлы беспаспяхова імкнуцца аднавіць status quo.

Магчымая таксама сітуацыя, калі зламыснік наўмысна імкнецца збіць час праз MiTM, ці DDOS напад. У такой сітуацыі можа адбыцца ўсё, што заўгодна:

скончыцца тэрмін дзеяння пароляў уліковых запісаў карыстальнікаў;
скончыцца тэрмін дзеяння X.509 сертыфікатаў;
двухфактарная аўтэнтыфікацыя TOTP перастане працаваць;
бэкапы "састарэюць" і сістэма выдаліць іх;
зламаецца DNSSec.

Зразумела, што кожны першы дэпартамент ІТ зацікаўлены ў надзейнай працы службаў сінхранізацыі часу, і добра б яны былі надзейныя і бяспечныя ў прамысловай эксплуатацыі.

Зламаць NTP за 25 хвілін

Сеткавыя пратаколы - мілініялы маюць адну асаблівасць, яны даўно састарэлі і нікуды ўжо не падыходзяць, але замяніць іх не так лёгка нават тады, калі набіраецца крытычная маса энтузіястаў і фінансавання.

Асноўная прэтэнзія да класічнага NTP у адсутнасці надзейных механізмаў абароны ад нападаў зламыснікаў. Прадпрымаліся разнастайныя спробы вырашыць гэтую праблему. Для гэтага спачатку ўкаранілі механізм загадзя ўсталяваных ключоў (PSK) для абмену сіметрычнымі ключамі.

Нажаль гэты спосаб сябе не апраўдаў у сяду простай чынніку ён дрэнна маштабуецца. Патрэбна ручная настройка на баку кліента ў залежнасці ад сервера. Гэта значыць, што вось дык вось проста нельга дадаць яшчэ аднаго кліента. Калі на серверы NTP нешта мяняецца, трэба пераналаджваць усе кліенты.

Тады прыдумалі AutoKey, але адразу ж у ім выявілі шэраг сур'ёзных уразлівасцяў у самім дызайне алгарытму і ад яго прыйшлося адмовіцца. Уся справа ў тым, што пачатковы лік (seed) утрымоўвае ўсяго толькі 32-біта, яно занадта мала і не ўтрымоўвае досыць вылічальнай складанасці для лэбавага нападу.

Key ID - сіметрычны 32-бітны ключ;
MAC (message authentication code) - кантрольная сума NTP пакета;

Autokey разлічваецца наступным чынам.

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

Дзе H() — крыптаграфічная хэш функцыя.

Для разліку кантрольнай сумы пакеты выкарыстоўваецца тая ж функцыя.

MAC=H(Autokey||NTP packet)

Так атрымліваецца, што ўся цэласнасць праверак пакетаў трымаецца на аўтэнтычнасці кукіс. Завалодаўшы імі, можна аднавіць autokey і затым падрабіць MAC. Аднак сервер NTP пры іх генерацыі выкарыстоўвае пачатковы лік (seed). Менавіта тут крыецца падвох.

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

Функцыя MSB_32 адразае ад выніку вылічэнні md5 хэша 32 старэйшых біта. Кліенцкі печыва не змяняецца да таго часу, пакуль параметры сервера нязменныя. Далей зламысніку застаецца толькі аднавіць пачатковы лік і атрымаць магчымасць самастойна генераваць печыва.

Для пачатку варта падлучыцца да сервера 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 and Encrypted Extension Fields Extension змяшчае шыфр AEAD з S2C ключом.

Другое поціск рукі можна паўтарыць шмат разоў, абыходзячы першы этап, бо кожны запыт і адказ дае кліенту дадатковыя печыва. Гэта дае тую перавагу, што адносна рэсурсаёмістыя TLS аперацыі вылічэнні і перадачы PKI дадзеных дзеляцца на лік паўторных запытаў. Гэта асабліва зручна для спецыялізаваных FPGA хранометраў, калі ўвесь асноўны функцыянал можна спакаваць у некалькі функцый з вобласці сіметрычнай крыптаграфіі, перадаўшы ўвесь TLS стэк на іншую прыладу.

NTPSec

У чым асаблівасць NTP? Нягледзячы на тое, што аўтар праекту Dave Mills імкнуўся як мага лепш дакументаваць свой код, рэдкі праграміст здолее разабрацца ў хітраспляцення алгарытмаў сінхранізацыі часу 35-дзетняй даўнасці. Частка кода напісана да эпохі POSIX, а Unix API тады моцна адрозніваўся ад таго, што выкарыстоўваецца ў нашыя дні. Акрамя таго, патрэбны веды па статыстыцы, каб ачысціць сігналу ад перашкод на шумных лініях.

NTS была не першай спробай паправіць NTP. Пасля таго, як зламыснікі навучыліся выкарыстоўваць уразлівасці NTP для ўзмацнення DDoS нападаў, стала ясна, што патрэбныя радыкальныя змены. І пакуль рыхтаваліся і даводзіліся да розуму чарнавікі NTS, National Science Foundation ЗША ў канцы 2014 г. тэрмінова вылучыў грант на мадэрнізацыю NTP.

Працоўную групу ўзначаліў не абы хто, а Эрык Стывен Рэйманд - Адзін з заснавальнікаў і слупоў супольнасці Open Source і аўтар кнігі Сабор і Кірмаш. Перш за ўсё Эрык са таварышы паспрабавалі перанесці код NTP з платформы BitKeeper на git, але не тут-то было. Лідэр праекту Harlan Stenn быў супраць гэтага рашэння і перамовы зайшлі ў тупік. Тады было вырашана форкнуць код праекту, так узнік 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 праект стаў выкарыстоўваць сістэму зборкі праграмнага забеспячэння. вафля.
Абнавілі і рэарганізавалі дакументацыю праекта. З супярэчлівай, і месцамі архаічнай калекцыі дакументаў стварылі суцэль ніштаватую дакументацыю. Кожны ключ каманднага радка і кожная сутнасць канфігурацыі зараз маюць адзіную версію праўды. Акрамя таго, старонкі кіраўніцтва і вэб дакументацыя зараз ствараюцца з адных і тых жа асноўных файлаў.

NTPSec даступны для шэрагу Linux дыстрыбутываў. У дадзены момант апошняя стабільная версія 1.1.8, для Gentoo Linux – перадапошняя.

(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[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
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]

Хранія

Была яшчэ адна спроба замяніць стары 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
These are the packages that would be merged, in order:
Calculating dependencies... done!
[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
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]

Як наладзіць уласны выдалены сервер 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 server chrony.

server my.vps.server

І нарэшце запуск сінхранізацыі часу на кліенце.

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

У наступны раз раскажу, якія ёсць варыянты сінхранізацыі часу без інтэрнэту.

Крыніца: habr.com

Як сінхранізацыя часу стала бяспечнай