Jak synchronizacja czasu stała się bezpieczna

Jak upewnić się, że czas sam w sobie nie kłamie, jeśli masz milion dużych i małych urządzeń komunikujących się za pośrednictwem TCP/IP? W końcu każde z nich ma zegar, a czas musi być poprawny na wszystkich z nich. Tego problemu nie da się uniknąć bez ntp.

Wyobraźmy sobie na chwilę, że w jednym segmencie infrastruktury przemysłowego IT występują trudności z synchronizacją usług w czasie. Klaster oprogramowania Enterprise natychmiast zaczyna zawodzić, domeny się rozpadają, mastery i węzły Standby bezskutecznie próbują przywrócić status quo.

Możliwe jest również, że atakujący celowo próbuje obniżyć czas poprzez atak MiTM lub DDOS. W takiej sytuacji może się zdarzyć wszystko:

• hasła do kont użytkowników wygasną;
• Certyfikaty X.509 wygasną;
• Dwuskładnikowe uwierzytelnianie TOTP przestanie działać;
• kopie zapasowe staną się „nieaktualne” i system je usunie;
• DNSSec ulegnie uszkodzeniu.

Oczywistym jest, że każdemu działowi IT zależy na niezawodnym działaniu usług synchronizacji czasu i dobrze byłoby, gdyby były one niezawodne i bezpieczne w eksploatacji przemysłowej.

Złamanie NTP w 25 minut

Protokół sieciowy – pokolenie millenialsów ma jedną wspólną cechę: od dawna przestarzały i nie nadają się już do niczego, a zastąpienie ich nie jest takie proste, nawet gdy uda się uzyskać krytyczną masę entuzjastów i funduszy.

Główną wadą klasycznego NTP jest brak niezawodnych mechanizmów ochrony przed złośliwymi atakami. Podejmowano różne próby rozwiązania tego problemu. W tym celu najpierw wprowadzono mechanizm wstępnie ustalonego klucza (PSK) do wymiany kluczy symetrycznych.

Niestety, ta metoda nie sprawdziła się z prostego powodu - nie skaluje się dobrze. Wymagana jest ręczna konfiguracja po stronie klienta, w zależności od serwera. Oznacza to, że nie można po prostu dodać kolejnego klienta. Jeśli coś się zmieni na serwerze NTP, należy ponownie skonfigurować wszystkich klientów.

Potem wymyślili AutoKey, ale natychmiast odkryto szereg poważnych luk w samym projekcie algorytmu i trzeba było go porzucić. Cały problem polega na tym, że początkowa liczba (seed) zawiera tylko 32 bity, jest zbyt mała i nie zawiera wystarczającej złożoności obliczeniowej do ataku siłowego.

• Klucz ID jest symetrycznym kluczem 32-bitowym;
• MAC (kod uwierzytelnienia wiadomości) — suma kontrolna pakietu NTP;

Autokey oblicza się w następujący sposób.

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

Gdzie H() jest kryptograficzną funkcją skrótu.

Ta sama funkcja służy do obliczenia sumy kontrolnej pakietu.

MAC=H(Autokey||NTP packet)

Okazuje się, że cała integralność kontroli pakietów opiera się na autentyczności plików cookie. Po ich przechwyceniu można przywrócić autokey, a następnie sfałszować MAC. Jednak serwer NTP używa początkowego numeru (seed) podczas ich generowania. W tym tkwi haczyk.

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

Funkcja MSB_32 odcina 5 starsze bity od wyniku obliczenia skrótu md32. Plik cookie klienta nie zmienia się, dopóki parametry serwera pozostają niezmienione. Następnie atakujący musi jedynie przywrócić początkową liczbę i uzyskać możliwość niezależnego generowania plików cookie.

Najpierw połącz się z serwerem NTP jako klient i pobierz plik cookie. Następnie atakujący odzyskuje początkowy numer za pomocą prostego algorytmu.

Algorytm ataku na liczbę początkową metodą siłową.

   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

Adresy IP są znane, więc pozostaje tylko utworzenie 2^32 haszy, aż utworzony plik cookie będzie pasował do pliku otrzymanego z serwera NTP. Na typowej stacji domowej z procesorem Intel Core i5 zajmie to 25 minut.

NTS — nowy Autokey

Nie można było tolerować takich luk w zabezpieczeniach Autokey i w 2012 r. nowa wersja protokół. Aby skompromitować nazwę, postanowili zmienić jej nazwę, więc Autokey v.2 został nazwany Network Time Security.

Protokół NTS jest rozszerzeniem bezpieczeństwa NTP i obecnie obsługuje tylko tryb unicast. Zapewnia silną ochronę kryptograficzną przed manipulacją pakietami, zapobiega podsłuchiwaniu, dobrze skaluje się, jest odporny na utratę pakietów sieciowych i zapewnia najniższą utratę dokładności w procesie zabezpieczania połączenia.

Połączenie NTS składa się z dwóch etapów, w których wykorzystywane są protokoły niższego poziomu. pierwszy Na tym etapie klient i serwer uzgadniają różne parametry połączenia i wymieniają pliki cookie zawierające klucze ze wszystkimi towarzyszącymi danymi. drugi Na tym etapie następuje właściwa bezpieczna sesja NTS pomiędzy klientem a serwerem NTP.

NTS składa się z dwóch protokołów niższej warstwy: Network Time Security Key Exchange (NTS-KE), który inicjuje bezpieczne połączenie przez TLS, oraz NTPv4, najnowsza wersja protokołu NTP. Więcej na ten temat poniżej.

Pierwszy etap - NTS KE

Na tym etapie klient NTP inicjuje sesję TLS 1.2/1.3 przez oddzielne połączenie TCP do serwera NTS KE. Podczas tej sesji następuje:

• Strony ustalają parametry AEAD algorytm dla drugiego etapu.
• Strony definiują drugi protokół niższego poziomu, ale na razie obsługiwany jest tylko NTPv4.
• Strony ustalają adres IP i port serwera NTP.
• Serwer NTS KE wysyła pliki cookie w protokole NTPv4.
• Strony wyodrębniają parę kluczy symetrycznych (C2S i S2C) z pliku cookie.

To podejście ma dużą zaletę, ponieważ cały ciężar przesyłania tajnych informacji o parametrach połączenia spoczywa na sprawdzonym i niezawodnym protokole TLS. Nie ma więc potrzeby ponownego wyważania otwartych drzwi w celu bezpiecznego uzgadniania NTP.

Etap 2 - NTP pod ochroną NTS

W drugim etapie klient bezpiecznie synchronizuje czas z serwerem NTP. W tym celu przesyła cztery specjalne pola rozszerzeń w strukturze pakietu NTPv4.

• Rozszerzenie Unique Identifier zawiera losowy znak jednorazowy, zapobiegający atakom typu replay.
• Rozszerzenie pliku cookie NTS zawiera jeden z plików cookie NTP przechowywanych przez klienta. Ponieważ tylko klient ma symetryczne klucze AAED C2S i S2C, serwer NTP musi je wyodrębnić z materiału cookie.
• Rozszerzenie NTS Cookie Placeholder to sposób, w jaki klient może zażądać dodatkowych plików cookie od serwera. To rozszerzenie jest konieczne, aby zapewnić, że odpowiedź serwera NTP nie będzie dużo dłuższa niż żądanie. Pomaga to zapobiegać atakom amplifikacji.
• Rozszerzenie NTS Authenticator i Encrypted Extension Fields zawiera szyfr algorytmu AAED z kluczem C2S, nagłówkiem NTP, znacznikami czasu i wspomnianym powyżej EF jako danymi pomocniczymi. Bez tego rozszerzenia możliwe jest fałszowanie znaczników czasu.

Po otrzymaniu żądania od klienta serwer weryfikuje autentyczność pakietu NTP. Aby to zrobić, musi odszyfrować pliki cookie, wyodrębnić algorytm AAED i klucze. Po pomyślnym sprawdzeniu poprawności pakietu NTP serwer odpowiada klientowi w następującym formacie.

• Rozszerzenie unikalnego identyfikatora jest lustrzaną kopią żądania klienta, zabezpieczeniem przed atakami typu replay.
• Rozszerzenie plików cookie NTS Więcej plików cookie, aby kontynuować sesję.
• Rozszerzenie NTS Authenticator i Encrypted Extension Fields zawiera szyfr AEAD z kluczem S2C.

Drugie uściśnięcie dłoni można powtarzać wielokrotnie, pomijając pierwszy etap, ponieważ każde żądanie i odpowiedź daje klientowi dodatkowe pliki cookie. Ma to tę zaletę, że stosunkowo zasobochłonne operacje TLS obliczania i przesyłania danych PKI są dzielone przez liczbę powtarzanych żądań. Jest to szczególnie wygodne w przypadku wyspecjalizowanych zegarów FPGA, gdy wszystkie podstawowe funkcje można spakować do kilku funkcji z dziedziny kryptografii symetrycznej, przenosząc cały stos TLS do innego urządzenia.

NTPsec

Co jest szczególnego w NTP? Pomimo faktu, że autor projektu, Dave Mills, starał się jak najlepiej udokumentować swój kod, rzadki programista będzie w stanie zrozumieć zawiłości algorytmów synchronizacji czasu sprzed 35 lat. Część kodu została napisana przed erą POSIX, a API Uniksa bardzo różniło się od tego, które jest używane dzisiaj. Ponadto, znajomość statystyki jest potrzebna do oczyszczenia sygnału z zakłóceń na zaszumionych liniach.

NTS nie był pierwszą próbą naprawy NTP. Po tym, jak atakujący nauczyli się wykorzystywać luki w zabezpieczeniach NTP do wzmacniania ataków DDoS, stało się jasne, że potrzebne są radykalne zmiany. A podczas gdy projekty NTS były przygotowywane i finalizowane, US National Science Foundation pilnie przyznała grant na modernizację NTP pod koniec 2014 r.

Grupą roboczą kierował nie kto inny, jak Eric Steven Raymond — jeden z założycieli i filarów społeczności Open Source oraz autor książki Katedra i BazarPierwszą rzeczą, którą Eric i jego towarzysze próbowali zrobić, było przeniesienie kodu NTP z platformy BitKeeper do git, ale to nie zadziałało w ten sposób. Lider projektu Harlan Stenn był przeciwny tej decyzji i negocjacje osiągnęły ślepy zaułek. Wtedy postanowiono rozwidlić kod projektu i tak powstał NTPSec.

Mając solidne podstawy, w tym GPSD, matematyczne podstawy i magiczną zdolność czytania starożytnego kodu, Eric Raymond był hakerem, który zrealizował taki projekt. Zespół znalazł specjalistę od migracji kodu i w ciągu zaledwie 10 tygodni NTP zadomowionyna GitLab. Praca zaczęła wrzeć.

Zespół Erica Raymonda zajął się problemem tak, jak Auguste Rodin zająłby się blokiem skalnym. Usuwając 175 KLOC starego kodu, byli w stanie znacznie zmniejszyć powierzchnię ataku, zamykając wiele luk w zabezpieczeniach.

Oto niekompletna lista osób dotkniętych tą sytuacją:

• Nieudokumentowany, przestarzały, nieaktualny lub uszkodzony refclock.
• Nieużywana biblioteka ICS.
• libopts/autogen.
• Stary kod dla Windows.
• ntpdc.
• Klucz automatyczny.
• Kod C ntpq przepisany w Pythonie.
• Kod C sntp/ntpdig przepisany w Pythonie.

Oprócz czyszczenia kodu projekt miał inne zadania. Oto niekompletna lista osiągnięć:

• Ochrona kodu przed przepełnieniem bufora została znacznie wzmocniona. Aby zapobiec przepełnieniu bufora, wszystkie niebezpieczne funkcje string (strcpy / strcat / strtok / sprintf / vsprintf / gets) zostały zastąpione bezpiecznymi wersjami, które implementują ograniczenie rozmiaru bufora.
• Dodano obsługę NTS.
• Dokładność kroku czasowego wzrosła dziesięciokrotnie dzięki fizycznemu wiązaniu sprzętowemu. Dzieje się tak, ponieważ współczesne zegary komputerowe stały się o wiele dokładniejsze niż te, które były na miejscu, gdy po raz pierwszy wprowadzono NTP. Największymi beneficjentami tego są GPSDO i dedykowane stacje radiowe czasu.
• Liczba języków programowania została zredukowana do dwóch. Zamiast Perla, awk, a nawet skryptów S, teraz jest to cały Python. Daje to więcej możliwości ponownego wykorzystania kodu.
• Zamiast skryptów autotools projekt zaczął używać systemu kompilacji oprogramowania WAF.
• Zaktualizowano i zreorganizowano dokumentację projektu. Z niespójnej i czasami archaicznej kolekcji dokumentów stworzyliśmy całkiem znośną dokumentację. Każdy przełącznik wiersza poleceń i każda jednostka konfiguracji ma teraz jedną wersję prawdy. Ponadto strony podręcznika i dokumentacja internetowa są teraz generowane z tych samych plików rdzeniowych.

NTPSec jest dostępny dla wielu dystrybucji Linuksa. Najnowsza stabilna wersja to obecnie 1.1.8, dla Gentoo Linux jest to przedostatnia.

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

kronika

Podjęto kolejną próbę zastąpienia starego NTP bezpieczniejszym analogiem. Chrony, w przeciwieństwie do NTPSec, jest napisany od podstaw i zaprojektowany tak, aby działał niezawodnie w szerokim zakresie warunków, w tym niestabilnych połączeń sieciowych, częściowej dostępności lub przeciążenia sieci i zmian temperatury. Ponadto chrony ma inne zalety:

• chrony może synchronizować zegar systemowy szybciej i dokładniej;
• chrony jest mniejszy, używa mniej pamięci i uzyskuje dostęp do procesora tylko wtedy, gdy jest to potrzebne. To duży plus dla oszczędzania zasobów i energii;
• chrony obsługuje sprzętowe znaczniki czasu w systemie Linux, co pozwala na niezwykle dokładną synchronizację w sieciach lokalnych.

Jednak chrony nie ma niektórych funkcji starego NTP, takich jak broadcast i multicast client/server. Ponadto klasyczny NTP obsługuje większą liczbę systemów operacyjnych i platform.

Aby wyłączyć funkcjonalność serwera i żądania NTP do procesu chronyd, wystarczy określić port 0 w pliku chrony.conf. Robi się to w przypadkach, gdy nie ma potrzeby utrzymywania czasu dla klientów NTP lub równorzędnych urządzeń. Począwszy od wersji 2.0, port serwera NTP jest otwarty tylko wtedy, gdy dostęp jest dozwolony przez dyrektywę allow lub odpowiednie polecenie, lub gdy skonfigurowany jest równorzędny komputer NTP, lub gdy używana jest dyrektywa broadcast.

Program składa się z dwóch modułów.

• chronyd to usługa działająca w tle, która otrzymuje informacje o różnicy między zegarem systemowym a zewnętrznym serwerem czasu i dostosowuje czas lokalny. Implementuje również protokół NTP i może działać jako klient lub serwer.
• chronyc to narzędzie wiersza poleceń do monitorowania i kontrolowania programu. Służy do dostrajania różnych parametrów usług, na przykład umożliwia dodawanie lub usuwanie serwerów NTP, podczas gdy chronyd nadal działa.

Od wersji RedHat Linux 7 używa chrony jako usługa synchronizacji czasu. Pakiet jest również dostępny dla innych dystrybucji Linuksa. Najnowsza stabilna wersja to 3.5, a v4.0 jest w przygotowaniu.

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

Jak skonfigurować własny zdalny serwer chrony w Internecie, aby synchronizować czas w sieci biurowej. Poniżej znajduje się przykład konfiguracji na VPS.

Przykład konfiguracji Chrony na RHEL/CentOS na VPS

Teraz trochę poćwiczmy i podnieśmy nasz własny serwer NTP na VPS. To bardzo proste, wystarczy wybrać odpowiednią taryfę na stronie RuVDS, zdobyć gotowy serwer i wpisać kilkanaście prostych poleceń. Do naszych celów ta opcja jest całkiem odpowiednia.

Przejdźmy do konfiguracji usługi i przede wszystkim zainstalujmy pakiet chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 używają innego menedżera pakietów.

[root@server ~]$ dnf install chrony

Po zainstalowaniu chrony należy uruchomić i aktywować usługę.

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

Jeśli chcesz, możesz edytować plik /etc/chrony.conf i zastąpić serwery NPT najbliższymi, lokalnymi serwerami, co skróci czas reakcji.

# 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

Następnie konfigurujemy synchronizację serwera NTP z węzłami z określonej puli.

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

Należy również otworzyć port NTP na zewnątrz, w przeciwnym razie zapora będzie blokować połączenia przychodzące z węzłów klienckich.

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

Po stronie klienta wystarczy ustawić prawidłową strefę czasową.

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

W pliku /etc/chrony.conf należy podać adres IP lub nazwę hosta serwera VPS, na którym uruchomiony jest serwer NTP chrony.

server my.vps.server

Na koniec uruchom synchronizację czasu na kliencie.

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

Następnym razem powiem wam, jakie są możliwości synchronizacji czasu bez korzystania z Internetu.

Źródło: www.habr.com