Paano naging secure ang pag-synchronize ng oras

Paano makasigurado na ang oras per se ay hindi nagsisinungaling kung mayroon kang isang milyong malalaki at maliliit na device na nakikipag-ugnayan sa pamamagitan ng TCP/IP? Pagkatapos ng lahat, ang bawat isa sa kanila ay may orasan, at ang oras ay dapat na tama para sa kanilang lahat. Ang problemang ito ay hindi maiiwasan nang walang ntp.

Isipin natin sa isang minuto na sa isang bahagi ng pang-industriyang imprastraktura ng IT ay may mga kahirapan sa pag-synchronize ng mga serbisyo sa paglipas ng panahon. Kaagad na nagsimulang mabigo ang cluster stack ng Enterprise software, ang mga domain ay naghiwa-hiwalay, ang mga master at Standby node ay hindi matagumpay na nagsusumikap na ibalik ang status quo.

Posible rin na ang isang umaatake ay sadyang sumusubok na guluhin ang oras sa pamamagitan ng pag-atake ng MiTM o DDOS. Sa ganoong sitwasyon, anumang bagay ay maaaring mangyari:

• Mag-e-expire ang mga password ng user account;
• Ang mga sertipiko ng X.509 ay mawawalan ng bisa;
• Ang TOTP two-factor authentication ay hihinto sa paggana;
• magiging lipas na ang mga backup at tatanggalin sila ng system;
• Masisira ang DNSSec.

Malinaw na ang bawat departamento ng IT ay interesado sa maaasahang operasyon ng mga serbisyo sa pag-synchronize ng oras, at magiging maganda kung sila ay maaasahan at ligtas sa operasyong pang-industriya.

Hatiin ang NTP sa loob ng 25 minuto

Mga protocol ng network - ang mga millennial ay may isang kakaiba, sila ay naging lipas na sa panahon at hindi na mabuti para sa anumang bagay, ngunit ang pagpapalit sa kanila ay hindi napakadali kahit na ang isang kritikal na masa ng mga mahilig at pagpopondo ay naipon.

Ang pangunahing reklamo tungkol sa klasikong NTP ay ang kakulangan ng maaasahang mekanismo para sa pagprotekta laban sa mga pag-atake ng mga nanghihimasok. Iba't ibang mga pagtatangka ang ginawa upang malutas ang problemang ito. Para makamit ito, nagpatupad muna kami ng mekanismong pre-shared key (PSK) para sa pagpapalitan ng mga simetriko na key.

Sa kasamaang palad, ang pamamaraang ito ay hindi nagbunga para sa isang simpleng dahilan - hindi ito mahusay na sukat. Kinakailangan ang manu-manong pagsasaayos sa panig ng kliyente depende sa server. Nangangahulugan ito na hindi ka maaaring magdagdag ng isa pang kliyente nang ganoon lang. Kung may magbabago sa NTP server, dapat na muling i-configure ang lahat ng kliyente.

Pagkatapos ay nakabuo sila ng AutoKey, ngunit agad nilang natuklasan ang isang bilang ng mga seryosong kahinaan sa disenyo ng algorithm mismo at kinailangan nilang iwanan ito. Ang bagay ay ang buto ay naglalaman lamang ng 32-bits, ito ay masyadong maliit at hindi naglalaman ng sapat na computational complexity para sa isang frontal attack.

• Key ID - simetriko 32-bit na key;
• MAC (message authentication code) - NTP packet checksum;

Ang autokey ay kinakalkula bilang mga sumusunod.

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

Kung saan ang H() ay isang cryptographic hash function.

Ang parehong function ay ginagamit upang kalkulahin ang checksum ng mga packet.

MAC=H(Autokey||NTP packet)

Lumalabas na ang buong integridad ng mga pagsusuri sa package ay nakasalalay sa pagiging tunay ng cookies. Kapag nakuha mo na ang mga ito, maaari mong ibalik ang autokey at pagkatapos ay i-spoof ang MAC. Gayunpaman, ang NTP server ay gumagamit ng isang binhi kapag bumubuo ng mga ito. Dito nakasalalay ang huli.

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

Pinutol ng MSB_32 function ang 5 pinaka makabuluhang bits mula sa resulta ng pagkalkula ng md32 hash. Hindi nagbabago ang cookie ng kliyente hangga't nananatiling hindi nagbabago ang mga parameter ng server. Pagkatapos ay maibabalik lamang ng umaatake ang paunang numero at makapag-iisa na makakabuo ng cookies.

Una, kailangan mong kumonekta sa NTP server bilang isang kliyente at tumanggap ng cookies. Pagkatapos nito, gamit ang isang brute force na paraan, ibinabalik ng umaatake ang paunang numero kasunod ng isang simpleng algorithm.

Algorithm para sa pag-atake sa pagkalkula ng paunang numero gamit ang brute-force na paraan.

   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

Ang mga IP address ay kilala, kaya ang natitira na lang ay lumikha ng 2^32 hash hanggang ang nilikhang cookie ay tumugma sa natanggap mula sa NTP server. Sa isang regular na home station na may Intel Core i5, aabutin ito ng 25 minuto.

NTS - bagong Autokey

Imposibleng pagtiisan ang gayong mga butas sa seguridad sa Autokey, at noong 2012 ito ay lumitaw isang bagong bersyon protocol. Upang makompromiso ang pangalan, nagpasya silang mag-rebrand, kaya ang Autokey v.2 ay tinawag na Network Time Security.

Ang protocol ng NTS ay isang extension ng seguridad ng NTP at kasalukuyang sumusuporta lamang sa unicast mode. Nagbibigay ito ng malakas na cryptographic na proteksyon laban sa pagmamanipula ng packet, pinipigilan ang pag-snooping, mahusay na pag-scale, nababanat sa pagkawala ng packet ng network, at nagreresulta sa hindi bababa sa halaga ng pagkawala ng katumpakan na natamo sa panahon ng seguridad ng koneksyon.

Ang isang koneksyon sa NTS ay binubuo ng dalawang yugto na gumagamit ng mas mababang layer ng mga protocol. Naka-on una Sa yugtong ito, sumasang-ayon ang kliyente at server sa iba't ibang parameter ng koneksyon at nagpapalitan ng cookies na naglalaman ng mga key kasama ang lahat ng kasamang set ng data. Naka-on pangalawa Sa yugtong ito, ang aktwal na protektadong sesyon ng NTS ay nagaganap sa pagitan ng kliyente at ng NTP server.

Binubuo ang NTS ng dalawang lower-layer na protocol: Network Time Security Key Exchange (NTS-KE), na nagpapasimula ng secure na koneksyon sa TLS, at NTPv4, ang pinakabagong incarnation ng NTP protocol. Kaunti pa tungkol dito sa ibaba.

Unang yugto - NTS KE

Sa yugtong ito, ang NTP client ay nagpasimula ng isang TLS 1.2/1.3 session sa isang hiwalay na koneksyon ng TCP sa NTS KE server. Sa session na ito nangyayari ang mga sumusunod.

• Tinutukoy ng mga partido ang mga parameter AeAD algorithm para sa ikalawang yugto.
• Tinukoy ng mga partido ang pangalawang lower-layer na protocol, ngunit sa ngayon ay ang NTPv4 lang ang sinusuportahan.
• Tinutukoy ng mga partido ang IP address at port ng NTP server.
• Nag-isyu ang server ng NTS KE ng cookies sa ilalim ng NTPv4.
• Kinukuha ng mga partido ang isang pares ng simetriko na key (C2S at S2C) mula sa materyal ng cookie.

Ang diskarte na ito ay may malaking kalamangan na ang buong pasanin ng pagpapadala ng lihim na impormasyon tungkol sa mga parameter ng koneksyon ay nahuhulog sa napatunayan at maaasahang TLS protocol. Inaalis nito ang pangangailangang muling likhain ang iyong sariling gulong para sa isang secure na NTP handshake.

Pangalawang yugto - NTP sa ilalim ng proteksyon ng NTS

Sa pangalawang hakbang, ligtas na sini-synchronize ng kliyente ang oras sa NTP server. Para sa layuning ito, nagpapadala ito ng apat na espesyal na extension (mga patlang ng extension) sa istraktura ng packet ng NTPv4.

• Ang Natatanging Identifier Extension ay naglalaman ng isang random na nonce upang maiwasan ang pag-atake ng replay.
• Ang NTS Cookie Extension ay naglalaman ng isa sa mga NTP cookies na magagamit ng kliyente. Dahil ang kliyente lang ang may C2S at S2C symmetric AAED key, dapat i-extract ng NTP server ang mga ito mula sa cookie material.
• Ang NTS Cookie Placeholder Extension ay isang paraan para sa isang kliyente na humiling ng karagdagang cookies mula sa server. Ang extension na ito ay kinakailangan upang matiyak na ang tugon ng server ng NTP ay hindi mas mahaba kaysa sa kahilingan. Nakakatulong ito na maiwasan ang mga pag-atake ng amplification.
• Ang NTS Authenticator at Encrypted Extension Fields Extension ay naglalaman ng AAED cipher na may C2S key, NTP header, timestamp, at EF sa itaas bilang kasamang data. Kung wala ang extension na ito, posibleng mag-spoof ng mga timestamp.

Sa pagtanggap ng kahilingan mula sa isang kliyente, ibe-verify ng server ang pagiging tunay ng NTP packet. Upang gawin ito, dapat niyang i-decrypt ang cookies, kunin ang AAED algorithm at mga susi. Matapos matagumpay na suriin ang NTP packet para sa bisa, tumugon ang server sa kliyente sa sumusunod na format.

• Ang Unique Identifier Extension ay isang mirror na kopya ng kahilingan ng kliyente, isang panukala laban sa mga pag-atake ng replay.
• NTS Cookie Extension mas maraming cookies para ipagpatuloy ang session.
• Ang NTS Authenticator at Encrypted Extension Fields Extension ay naglalaman ng AEAD cipher na may S2C key.

Ang pangalawang pagkakamay ay maaaring ulitin nang maraming beses, na lumalampas sa unang hakbang, dahil ang bawat kahilingan at tugon ay nagbibigay sa kliyente ng karagdagang cookies. Ito ay may kalamangan na ang medyo resource-intensive na operasyon ng TLS ng pag-compute at pagpapadala ng data ng PKI ay nahahati sa bilang ng mga paulit-ulit na kahilingan. Ito ay lalong maginhawa para sa mga dalubhasang FPGA timekeeper, kapag ang lahat ng pangunahing pag-andar ay maaaring i-package sa ilang mga function mula sa larangan ng simetriko cryptography, paglilipat ng buong TLS stack sa isa pang device.

NTPSec

Ano ang espesyal sa NTP? Sa kabila ng katotohanan na ang may-akda ng proyekto, si Dave Mills, ay sinubukang idokumento ang kanyang code hangga't maaari, ito ay isang bihirang programmer na magagawang maunawaan ang mga intricacies ng time synchronization algorithm na 35 taong gulang. Ang ilan sa mga code ay isinulat bago ang panahon ng POSIX, at ang Unix API noon ay ibang-iba sa ginagamit ngayon. Bilang karagdagan, ang kaalaman sa mga istatistika ay kinakailangan upang i-clear ang signal mula sa interference sa maingay na mga linya.

Ang NTS ay hindi ang unang pagtatangka na ayusin ang NTP. Sa sandaling natutunan ng mga umaatake na samantalahin ang mga kahinaan ng NTP upang palakasin ang mga pag-atake ng DDoS, naging malinaw na kailangan ng mga radikal na pagbabago. At habang inihahanda at tinatapos ang mga draft ng NTS, ang US National Science Foundation sa pagtatapos ng 2014 ay agarang naglaan ng grant para sa modernisasyon ng NTP.

Ang grupong nagtatrabaho ay pinamumunuan hindi lamang ng sinuman, ngunit Eric Steven Raymond - isa sa mga tagapagtatag at haligi ng Open Source na komunidad at may-akda ng aklat Katedral at Bazaar. Ang unang bagay na sinubukan ni Eric at ng kanyang mga kaibigan ay ilipat ang NTP code mula sa BitKeeper platform patungo sa git, ngunit hindi ito gumana sa ganoong paraan. Ang pinuno ng proyekto na si Harlan Stenn ay tutol sa desisyong ito at natigil ang mga negosasyon. Pagkatapos ay napagpasyahan na i-fork ang code ng proyekto, at ipinanganak ang NTPSec.

Solid na karanasan, kabilang ang trabaho sa GPSD, isang mathematical background at ang mahiwagang kasanayan sa pagbabasa ng sinaunang code - si Eric Raymond ang eksaktong hacker na maaaring gumawa ng ganoong proyekto. Nakahanap ang team ng isang code migration specialist at sa loob lang ng 10 linggo NTP lumagay sa tahimiksa GitLab. Puspusan ang trabaho.

Ginawa ng pangkat ni Eric Raymond ang gawain sa parehong paraan na ginawa ni Auguste Rodin sa isang bloke ng bato. Sa pamamagitan ng pag-alis ng 175 KLOC ng lumang code, nagawa nilang makabuluhang bawasan ang ibabaw ng pag-atake sa pamamagitan ng pagsasara ng maraming butas sa seguridad.

Narito ang isang hindi kumpletong listahan ng mga kasama sa pamamahagi:

• Hindi dokumentado, lipas na sa panahon, lipas na o sirang refclock.
• Hindi nagamit na library ng ICS.
• libopts/autogen.
• Lumang code para sa Windows.
• ntpdc.
• Autokey.
• Ang ntpq C code ay muling isinulat sa Python.
• Ang sntp/ntpdig C code ay muling isinulat sa Python.

Bilang karagdagan sa paglilinis ng code, ang proyekto ay may iba pang mga gawain. Narito ang isang bahagyang listahan ng mga nakamit:

• Ang proteksyon ng code laban sa buffer overflow ay makabuluhang napabuti. Upang maiwasan ang mga buffer overflow, lahat ng hindi ligtas na string function (strcpy/strcat/strtok/sprintf/vsprintf/gets) ay pinalitan ng mga ligtas na bersyon na nagpapatupad ng mga limitasyon sa laki ng buffer.
• Nagdagdag ng suporta sa NTS.
• Pinahusay na katumpakan ng hakbang ng oras nang sampung beses sa pamamagitan ng pag-link ng pisikal na hardware. Ito ay dahil sa ang katunayan na ang mga modernong orasan ng computer ay naging mas tumpak kaysa noong ipinanganak ang NTP. Ang pinakamalaking benepisyaryo nito ay ang GPSDO at mga dedikadong time radio.
• Ang bilang ng mga programming language ay nabawasan sa dalawa. Sa halip na Perl, awk at maging ang mga S script, Python na ang lahat. Dahil dito, mas maraming pagkakataon para sa muling paggamit ng code.
• Sa halip na mga pansit ng autotools script, nagsimulang gumamit ang proyekto ng isang software build system waf.
• Na-update at muling inayos ang dokumentasyon ng proyekto. Mula sa isang kontradiksyon at kung minsan ay archaic na koleksyon ng mga dokumento, lumikha sila ng medyo maipapasa na dokumentasyon. Ang bawat command line switch at bawat configuration entity ay mayroon na ngayong iisang bersyon ng katotohanan. Bilang karagdagan, ang mga man page at dokumentasyon sa web ay nilikha na ngayon mula sa parehong mga pangunahing file.

Available ang NTPSec para sa ilang distribusyon ng Linux. Sa ngayon, ang pinakabagong stable na bersyon ay 1.1.8, para sa Gentoo Linux ito ang penultimate.

(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]

Chrony

May isa pang pagtatangka na palitan ang lumang NTP ng mas secure na alternatibo. Ang Chrony, hindi katulad ng NTPSec, ay isinulat mula sa simula at idinisenyo upang gumana nang mapagkakatiwalaan sa ilalim ng malawak na hanay ng mga kundisyon, kabilang ang mga hindi matatag na koneksyon sa network, bahagyang pagkakaroon o pagsisikip ng network, at mga pagbabago sa temperatura. Bilang karagdagan, ang chrony ay may iba pang mga pakinabang:

• maaaring i-synchronize ng chrony ang system clock nang mas mabilis na may higit na katumpakan;
• Ang chrony ay mas maliit, kumokonsumo ng mas kaunting memorya, at ina-access lamang ang CPU kapag kinakailangan. Ito ay isang malaking plus para sa pag-save ng mga mapagkukunan at enerhiya;
• Sinusuportahan ng chrony ang mga timestamp ng hardware sa Linux, na nagbibigay-daan sa napakatumpak na pag-synchronize sa mga lokal na network.

Gayunpaman, kulang ang chrony ng ilan sa mga feature ng lumang NTP, gaya ng broadcast at multicast client/server. Bilang karagdagan, sinusuportahan ng klasikong NTP ang mas malaking bilang ng mga operating system at platform.

Para i-disable ang functionality ng server at NTP request sa chronyd process, isulat lang ang port 0 sa chrony.conf file. Ginagawa ito sa mga kaso kung saan hindi na kailangang magpanatili ng oras para sa mga kliyente ng NTP o mga kapantay. Dahil ang bersyon 2.0, ang NTP server port ay bukas lamang kapag ang pag-access ay pinahihintulutan ng isang allow directive o naaangkop na command, o isang NTP peer ay na-configure, o isang broadcast directive ay ginamit.

Ang programa ay binubuo ng dalawang module.

• Ang chronyd ay isang serbisyo na tumatakbo sa background. Tumatanggap ito ng impormasyon tungkol sa pagkakaiba sa pagitan ng system clock at ng external na server ng oras at inaayos ang lokal na oras. Ipinapatupad din nito ang NTP protocol at maaaring kumilos bilang isang kliyente o server.
• Ang chronyc ay isang command line utility para sa pagsubaybay at kontrol ng programa. Ginagamit upang i-fine-tune ang iba't ibang mga parameter ng serbisyo, halimbawa na nagpapahintulot sa iyong magdagdag o mag-alis ng mga NTP server habang patuloy na tumatakbo ang chronyd.

Mula noong bersyon 7 ng RedHat Linux gumagamit chrony bilang isang serbisyo sa pag-synchronize ng oras. Available din ang package para sa iba pang mga distribusyon ng Linux. Ang pinakabagong stable na bersyon ay 3.5, naghahanda para sa paglabas ng 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]

Paano i-set up ang iyong sariling remote chrony server sa Internet upang i-synchronize ang oras sa isang network ng opisina. Nasa ibaba ang isang halimbawa ng pag-set up ng VPS.

Halimbawa ng pag-set up ng Chrony sa RHEL / CentOS sa VPS

Magsanay tayo ngayon ng kaunti at mag-set up ng sarili nating NTP server sa isang VPS. Napakasimple nito, piliin lamang ang naaangkop na taripa sa website ng RuVDS, kumuha ng handa na server at mag-type ng isang dosenang simpleng utos. Para sa aming mga layunin, ang pagpipiliang ito ay lubos na angkop.

Magpatuloy tayo sa pag-set up ng serbisyo at i-install muna ang chrony package.

[root@server ~]$ yum install chrony

Gumagamit ang RHEL 8 / CentOS 8 ng ibang manager ng package.

[root@server ~]$ dnf install chrony

Pagkatapos i-install ang chrony, kailangan mong simulan at i-activate ang serbisyo.

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

Kung ninanais, maaari kang gumawa ng mga pagbabago sa /etc/chrony.conf, palitan ang mga NPT server ng pinakamalapit na lokal upang mabawasan ang oras ng pagtugon.

# 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

Susunod, nag-set up kami ng pag-synchronize ng NTP server na may mga node mula sa tinukoy na pool.

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

Kinakailangan din na buksan ang NTP port sa labas, kung hindi man ay haharangin ng firewall ang mga papasok na koneksyon mula sa mga node ng kliyente.

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

Sa panig ng kliyente, sapat na upang maitakda nang tama ang time zone.

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

Ang /etc/chrony.conf file ay tumutukoy sa IP o host name ng aming VPS server na nagpapatakbo ng NTP server chrony.

server my.vps.server

At sa wakas, pagsisimula ng pag-synchronize ng oras sa kliyente.

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

Sa susunod na sasabihin ko sa iyo kung anong mga opsyon ang mayroon para sa pag-synchronize ng oras nang walang Internet.

Pinagmulan: www.habr.com