Hogyan biztosíthatjuk, hogy az idő ne hazudjon, ha milliónyi nagy és kicsi eszköz kommunikál TCP/IP-n? Mert mindegyiken vannak órák, és az időnek mindenhol pontosnak kell lennie. E problémát NTP nélkül nem lehet megoldani.
Képzeljük el egy percre, hogy egy ipari IT infrastruktúra egyik szegmensében időszinkronizálási nehézségek merültek fel. Azonnal összeomlik a klaszteres Enterprise szoftver, a domain-ek szétesnek, a mester és standby csomópontok hiába próbálnak visszaállítani a status quo-t.
Olyan helyzet is előfordulhat, amikor egy rosszindulatú támadó szándékosan megpróbálja megzavarni az időt MiTM vagy DDoS támadás révén. Ilyen helyzetben bármi megtörténhet:
- lejárnak a felhasználói fiókok jelszavainak érvényessége;
- lejárnak az X.509 tanúsítványok;
- a TOTP kétfaktoros azonosítás leáll;
- a mentések „elavulnak”, és a rendszer törli őket;
- megsérül a DNSSec.
Nyilvánvaló, hogy minden IT osztály érdekel a megbízható időszinkronizáló szolgáltatások működésében, és jó lenne, ha azok megbízhatóak és biztonságosak lennének az ipari környezetben.
Az NTP 25 perc alatt történő feltörése
A hálózati protokollok — a millenniumi generációknak van egy sajátossága, hogy régóta és már nem működnek, de még akkor sem könnyű őket kicserélni, amikor kritikus tömegű lelkesedés és finanszírozás áll rendelkezésre.
A klasszikus NTP fő kritikája az, hogy nincsenek megbízható védelmi mechanizmusok a rosszindulatú támadások ellen. Különböző próbálkozásokat tettek a probléma megoldására. Első lépésként bevezették az előre beállított kulcsok (PSK) mechanizmusát a szimmetrikus kulcsok cseréjéhez.
Sajnos ez a megoldás nem vált be egy egyszerű okból — nem skálázódik jól. Kézi beállítás szükséges a kliens oldalán a kiszolgáló függvényében. Ez azt jelenti, hogy nem lehet egyszerűen hozzáadni egy új klienst. Ha valami változik az NTP kiszolgálón, akkor az összes klienst újra kell konfigurálni.
Akkor feltalálták az AutoKey-t, de azonnal komoly sebezhetőségeket fedeztek fel a tervezési algoritmusban, ezért el kellett vetni. Az a helyzet, hogy a különböző szám (seed) mindössze 32 bitet tartalmaz, ez túl kicsi, és nem biztosít elegendő számítási összetettséget egy brutális támadáshoz.
- Kulcsazonosító — szimmetrikus 32 bites kulcs;
- MAC (üzenet-hitelesítési kód) — az NTP csomag ellenőrző összege;
Az Autokey a következőképpen számítódik ki.
Autokey=H(Küldő-IP||Fogadó-IP||Kulcsazonosító||Süti)Ahol H() — kriptográfiai hash függvény.
A csomagok ellenőrző összegének kiszámításához ugyanez a függvény használatos.
MAC=H(Autokey||NTP csomag)Így a csomagok integritása a süti hitelességén múlik. Ha valaki megszerzi őket, helyre tudja állítani az autokey-t, és hamisítani tudja a MAC-ot. Az NTP szerver azonban génereáláskor egy inicializáló számot (seed) használ. Itt rejlik a csapda.
Süti=MSB_32(H(Ügyfél IP||Szerver IP||0||Szerver Seed))Az MSB_32 függvény a md5 hash számításának 32 legfelső bitjét vágja le az eredményből. Az ügyfél sütije nem változik addig, amíg a szerver paraméterei változatlanok. Ekkor az elkövetőnek csak az inicializáló számot kell helyreállítania, hogy lehetősége legyen önállóan sütiket generálni.
Első lépésként csatlakozni kell az NTP szerverhez mint kliens, és meg kell szerezni a sütit. Ezt követően visszaállítja az inicializáló számot az elkövető egyszerű algoritmus alapján.
Az inicializáló szám visszaállítására irányuló támadási algoritmus.
for i=0:2^32 − 1 do
Ci=H(Szerver-IP||Ügyfél-IP||0||i)
if Ci=Süti then
return i
end if
end forAz IP címek ismertek, így annyi kell, hogy 2^32 hash-t hozzunk létre, amíg a létrehozott süti meg nem egyezik azzal, amit az NTP szervertől kaptunk. Egy átlagos otthoni állomáson Intel Core i5 processzorral ez körülbelül 25 percet venne igénybe.
NTS — új Autokey
Az Autokey biztonsági réseivel nem lehetett megbékélni, így 2012-ben megjelent a protokollból. A kompromittált név miatt átnevezést döntöttek, így az Autokey v.2-t Network Time Security néven emlegették.
Az NTS protokoll az NTP biztonsági kiterjesztése, és jelenleg csak unicast üzemmódot támogat. Megbízható kriptográfiai védelmet nyújt a csomagok manipulációja ellen, megelőzi a nyomkövetést, jól skálázható, ellenáll a hálózati csomagok elvesztésének, és a kapcsolat védelme során a legkisebb pontosságvesztést eredményezi.
NTS kapcsolat két szakaszból áll, amelyekben az alsó szintű protokollok használatosak. Az első szakaszban a kliens és a szerver megállapodik a kapcsolat különböző paramétereiről és megosztja a sütiket, amelyek kulcsokat tartalmaznak a hozzá tartozó adathalmazon belül. A második a szakaszban ténylegesen zajlik a védett NTS kapcsolat az NTP ügyfél és a szerver között.
Az NTS két alsó szintű protokollból áll: a Network Time Security Key Exchange (NTS-KE) a TLS alapú biztonságos kapcsolat inicializálásához és az NTPv4 — az NTP protokoll legújabb verziója. Erről részletesebben lentebb olvashat.
Első szakasz — NTS KE
Ebben a szakaszban az NTP ügyfél külön TCP kapcsolaton TLS 1.2/1.3 kapcsolatot indít az NTS KE szerverrel. Ez alatt az ülés alatt a következő történik.
- A felek meghatározzák a paramétereket algoritmus a második szakaszhoz.
- A felek meghatározzák a második alsó szintű protokollt, de jelenleg csak az NTPv4 támogatott.
- A felek meghatározzák az NTP szerver IP címét és portját.
- Az NTS KE szerver NTPv4 cookie-t bocsát ki.
- A felek a cookie anyagából kinyerik a szimmetrikus kulcspárokat (C2S és S2C).
Ez a megközelítés nagy előnyt jelent, mivel a titkos információk átadásának terhe egy megbízható és tesztelt TLS protokollra hárul. Így nem szükséges saját megoldást kitalálni a biztonságos NTP kézfogóra.
Második szakasz — NTP NTS védelemmel
A második szakaszban az ügyfél biztonságosan szinkronizálja az időt az NTP szerverrel. Ehhez négy speciális kiterjesztést (extension field) továbbít az NTPv4 csomag struktúrájában.
- A Unique Identifier Extension tartalmaz egy véletlenszerű nonce-ot a visszaéléses támadások megelőzése érdekében.
- A NTS Cookie Extension tartalmaz egy meglévő NTP cookie-t, amely a kliensnél van. Mivel csak a kliens rendelkezik szimmetrikus AAED kulcsokkal C2S és S2C, az NTP szervernek ki kell nyernie ezeket a cookie anyagából.
- A NTS Cookie Placeholder Extension lehetőséget ad a kliensnek, hogy további cookie-kat kérjen a szervertől. Ez a kiterjesztés szükséges ahhoz, hogy az NTP szerver válasza ne legyen sokkal hosszabb, mint a kérés. Ez segít megelőzni a fokozó támadásokat.
- A NTS Authenticator and Encrypted Extension Fields Extension tartalmazza az AAED algoritmus titkosítását a C2S kulccsal, az NTP fejlécet, időbélyegeket és a fent említett EF-t kísérő adatként. Ez a kiterjesztés nélkül hamisíthatják az időbélyegeket.
Miután megkapta a kérést az ügyféltől, a szerver ellenőrzi az NTP csomag hitelességét. Ehhez dekódolnia kell a cookie-t, ki kell nyernie az AAED algoritmust és kulcsokat. Az NTP csomag érvényességének sikeres ellenőrzése után a szerver a következő formátumban válaszol az ügyfélnek.
- A Unique Identifier Extension a kliens kérésének tükörképét adja, mint védelmi intézkedés a visszaéléses támadások ellen.
- NTS Cookie Extension több süti a munkamenet folytatásához.
- NTS Authenticator és Titkosított Kiterjesztésmezők Kiterjesztés AEAD titkot tartalmaz S2C kulccsal.
A második kézfogás többször is megismételhető, kihagyva az első fázist, mivel minden kérés és válasz további sütiket ad a kliensnek. Ez azzal az előnnyel jár, hogy a viszonylag allokáló TLS műveletek kiszámítása és a PKI adatok továbbítása megoszlik a megismételt kérések számával. Ez különösen hasznos a speciális FPGA órák számára, amikor az egész alapvető funkcionalitás visszacsomagolható a szimmetrikus kriptográfia területéről származó néhány funkcióba, átadva az egész TLS verem egy másik eszköznek.
NTPSec
Mi a különlegessége az NTP-nek? Bár a projekt szerzője, Dave Mills a lehető legjobban igyekezett dokumentálni a kódját, ritka programozó tudja megérteni az időszinkronizálás 35 éves algoritmusainak bonyodalmait. A kód egy része a POSIX korszak előtt íródott, és a Unix API akkor nagyon eltért attól, amit ma használunk. Ezen kívül statisztikai tudás szükséges a zajos vonalakon a jelzavar eltávolításához.
Az NTS nem volt az első kísérlet az NTP javítására. Miután a támadók megtanulták kihasználni az NTP sebezhetőségeit a DDoS támadások fokozására, világossá vált, hogy radikális változásokra van szükség. Miközben az NTS tervezetét készítették és finomították, az Egyesült Államok Nemzeti Tudományos Alapítványa 2014 végén sürgősen támogatást biztosított az NTP modernizálásához.
A munkacsoportot nem akárki vezette, hanem — az Open Source közösség egyik alapítója és pillére, valamint a című könyv szerzője. Először Eric és társai megpróbálták átkonvertálni az NTP kódját a BitKeeper platformról git-re, de ez nem vált be. A projekt vezetője, Harlan Stenn ellenkezett ezzel a döntéssel, és a tárgyalások zsákutcába jutottak. Ekkor úgy döntöttek, hogy leválasztják a projekt kódját, így jött létre az NTPSec.
Szilárd tapasztalat, köztük a GPSD-n végzett munka, matematikai háttér és az ősi kód olvasásának varázslatos képessége — Eric Raymond pontosan az a hacker volt, aki képes volt egy ilyen projektet megvalósítani. A csapatban akadt kód migrációs szakember, és mindössze 10 hét alatt az NTP a GitLab-on. A munka beindult.
Eric Raymond csapata úgy látott hozzá a feladathoz, mint Auguste Rodin a kőblokkhoz. A régi kód 175 KLOC-jának eltávolításával jelentősen csökkentették a támadási felületet, számos biztonsági réseket lezárva.
Itt van egy rövid lista az érintettekről:
- Nem dokumentált, elavult, elavult vagy meghibásodott refclock.
- Nem használt ICS könyvtár.
- libopts/autogen.
- Régi kód Windowsra.
- ntpdc.
- Autokulcs.
- Az ntpq C kódját Pythonra írták át.
- Az sntp/ntpdig C kódját Pythonra írták át.
A kód tisztítása mellett a projektnek más feladatai is voltak. Itt van egy rövid lista az elért eredményekről:
- Jelentősen megerősítettük a kód védelmét a puffertúlcsordulás ellen. A puffertúlcsordulás megakadályozása érdekében minden nem biztonságos karakterlánc-függvényt (strcpy / strcat / strtok / sprintf / vsprintf / gets) biztonságos verziókkal helyettesítettünk, amelyek implementálják a pufferméret korlátozását.
- NTS támogatás került hozzáadásra.
- Tízszeresére növeltük az időbeli lépték pontosságát a fizikai berendezések lehorgonyzásával. Ennek az az oka, hogy a modern számítógépes órák sokkal pontosabbak lettek, mint azok, amelyek az NTP megszületésének időpontjában voltak. A GPSDO és a dedikált időállomások a legnagyobb haszonnal jártak.
- A programozási nyelvek száma kettőre csökkent. A Perl, awk és még az S skriptek helyett most már csak Python van. Ennek következtében több lehetőség nyílt a kód újrafelhasználására.
- A régi autotools rendszerről a projekt szoftverépítési rendszerre váltott. .
- Frissítettük és átszerveztük a projekt dokumentációját. Az ellentmondásos és némelyest elavult dokumentumgyűjteményből elég elfogadható dokumentációt hoztunk létre. Most minden parancssori kulcs és minden konfigurációs entitás rendelkezik egy egyesített igazsággal. Ezenkívül a kézikönyv oldalak és a webes dokumentáció most már azonos alapfájlokból készülnek.
Az NTPSec számos Linux disztribúcióhoz elérhető. Jelenleg a legfrissebb stabil verzió 1.1.8, a Gentoo Linuxhoz a második legfrissebb.
(1:696)$ sudo emerge -av ntpsec
Ezek azok a csomagok, amelyeket egyesíteni fognak, a következő rendben:
A függőségek kiszámítása... kész!
[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
Összesen: 1 csomag (1 újrainstallálás), Letöltések mérete: 0 KiB
Szeretné egyesíteni ezeket a csomagokat? [Igen/Nem]
Chrony
Volt még egy kísérlet arra, hogy a régi NTP-t egy biztonságosabb alternatívára cseréljék. A Chrony, ellentétben az NTPSec-kel, nulláról íródott, és megbízható működésre lett tervezve széles körű körülmények között, beleértve a nem stabil hálózati kapcsolatok, a részleges elérhetőséget vagy a hálózati túlterhelést és a hőmérséklet-változásokat. Ezen kívül a chrony további előnyökkel is rendelkezik:
- a chrony gyorsabban tudja szinkronizálni a rendszeren belüli órákat, és nagyobb pontossággal;
- a chrony kevesebb erőforrást fogyaszt, kevesebb memóriát igényel, és csak akkor használja a CPU-t, ha szükséges. Ez nagy előny a források és az energia megtakarítása szempontjából;
- a chrony támogatja a hardver szintű időbélyegeket Linuxon, ami rendkívül pontos szinkronizálást biztosít helyi hálózatokon.
A chrony-ban azonban hiányoznak bizonyos funkciók, amelyeket a régi NTP kínált, például a széles körű és multicast kliens/szerver támogatás. Ráadásul a klasszikus NTP több operációs rendszert és platformot támogat.
A chronyd folyamat szerver és NTP kérések funkciójának letiltásához elegendő a port 0 beírása a chrony.conf fájlba. Ezt akkor kell megtenni, amikor nem szükséges időt szolgáltatni NTP kliensek vagy peer csomópontok számára. A 2.0 verziótól kezdődően az NTP szerver portja csak akkor van megnyitva, ha a allow direktíva vagy a megfelelő parancs engedélyezi a hozzáférést, vagy ha egy peer NTP csomópont van beállítva, vagy a broadcast direktíva van használatban.
A program két modulból áll.
- A chronyd egy háttérben futó szolgáltatás. Ez információt gyűjt a rendszeren belüli órák eltéréséről külső időszolgáltatótól, és korrigálja a helyi időt. Ezen kívül megvalósítja az NTP protokollt, és működhet kliensként vagy szerverként.
- A chronyc egy parancssori segédprogram a program monitorozására és vezérlésére. Használják különféle szolgáltatásparaméterek finomhangolására, például lehetővé teszi NTP szerverek hozzáadását vagy eltávolítását, miközben a chronyd továbbra is működik.
A 7. verziótól kezdődően RedHat Linuxban a chrony időszinkronizáló szolgáltatásként. A csomag más Linux disztribúciók számára is elérhető. A legújabb stabil verzió 3.5, a v4.0 kiadása készül.
(1:712)$ sudo emerge -av chrony
Ezek a csomagok fognak összevonódni, az alábbiak szerint:
Függőségek számítása... kész!
[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
Összesen: 1 csomag (1 új, 1 bináris), a letöltési méret: 246 KiB
Szeretné ezeket a csomagokat egyesíteni? [Igen/Nem]
Hogyan állítsunk be saját távoli chrony szervert az interneten az irodai hálózat időszinkronizálásához. Az alábbiakban egy példa beállítás a VPS-en.
Chrony beállítás példa RHEL / CentOS VPS-en
Most pedig gyakoroljunk kicsit, és indítsuk el a saját NTP szerverünket a VPS-en. Ez nagyon egyszerű, elegendő választani egy megfelelő csomagot a RuVDS webhelyén, kapni egy kész szervert, és beírni egy tucat egyszerű parancsot. A céljainkhoz ez a megoldás tökéletesen megfelel.
Lépjünk a szolgáltatás beállításához, és először telepítsük a chrony csomagot.
[root@server ~]$ yum install chronyA RHEL 8 / CentOS 8 más csomagkezelőt használ.
[root@server ~]$ dnf install chronyA chrony telepítése után el kell indítani és aktiválni a szolgáltatást.
[root@server ~]$ systemctl enable chrony --nowHa szeretnénk, módosíthatjuk a /etc/chrony.conf fájlt, kicserélve az NPT szervereket a legközelebbi helyi szerverekre a válaszidő csökkentése érdekében.
# 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
Ezután állítsuk be az NTP szerver szinkronizálását a megadott poolból származó csomópontokkal.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
Nyissuk meg az NTP portot is, különben a tűzfal blokkolni fogja a bejövő kapcsolatokat az ügyfél csomópontoktól.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Az ügyfél oldalán elegendő a helyes időzónát beállítani.
[root@client ~]$ timedatectl set-timezone Europe/MoscowA /etc/chrony.conf fájlban meg kell adni a VPS szerverünk IP-címét vagy hosztnevét, ahol a chrony NTP szerver fut.
server my.vps.serverVégül indítsuk el az idő szinkronizációját az ügyfélen.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
Legközelebb mesélek a hálózaton kívüli idő szinkronizálásának lehetőségeiről.
Forrás: habr.com
