Przejdź do zawartości

Network Time Protocol

Z Wikipedii, wolnej encyklopedii

Network Time Protocol (NTP) – protokół komunikacyjny służący do synchronizacji zegarów komputerów i innych urządzeń w sieciach komputerowych o zmiennych opóźnieniach transmisji. NTP rozprowadza czas odniesiony do UTC, używa zwykle UDP na porcie 123 i jest jednym z najstarszych protokołów internetowych pozostających w powszechnym użyciu[1][2][3][4]. Protokół został zaprojektowany przez Davida L. Millsa(inne języki) i jest rozwijany od lat 80. XX wieku, a jego pierwszą specyfikację opublikowano w 1985 roku[5]. Aktualną podstawową specyfikacją jest NTPv4 opisana w RFC nr 5905[1].

NTP nie przesyła informacji o lokalnej strefie czasowej ani o zasadach czasu letniego; jego zadaniem jest utrzymanie zgodnego czasu systemowego, a przeliczenie UTC na czas lokalny pozostaje funkcją systemu operacyjnego albo aplikacji. W dobrze zaprojektowanych sieciach lokalnych NTP może osiągać dokładność lepszą niż milisekunda, natomiast w publicznym Internecie wynik zależy od tras pakietów, asymetrii opóźnień, przeciążenia i jakości źródeł czasu[1][6].

Sam protokół NTP należy odróżniać od konkretnych implementacji – serwerów i klientów, które realizują jego algorytmy. Do szeroko stosowanych implementacji należą klasyczna referencyjna usługa ntpd(inne języki) rozwijana w ramach NTP Project, niezależnie napisany chrony(inne języki) oraz utwardzony pod kątem bezpieczeństwa fork NTPsec(inne języki)[4][7][8][9]. Synchronizację czasu zapewniają też usługa Windows Time w systemach Microsoft Windows, która nie jest dokładną implementacją NTP, choć korzysta z jego algorytmów, oraz wbudowany w systemd komponent systemd-timesyncd, implementujący wyłącznie SNTP[10][11].

Historia i wersje

[edytuj | edytuj kod]

Prace, z których wywodzi się NTP, rozpoczęły się przed formalną specyfikacją protokołu w badaniach Davida L. Millsa nad synchronizacją zegarów w sieciach pakietowych. Wczesne rozwiązania zostały opisane między innymi w IEN 173 oraz w RFC nr 778 dotyczącym DCNET Internet Clock Service. Pierwsza specyfikacja Network Time Protocol, oznaczana później jako NTPv0, ukazała się w RFC nr 958 w 1985 roku i zawierała format pakietu oraz wzory na opóźnienie i przesunięcie zegarów używane także w późniejszych wersjach[12][13][5][14].

NTPv1 został opisany w RFC nr 1059 z 1988 roku, NTPv2 w RFC nr 1119 z 1989 roku, a szeroko stosowana wersja NTPv3 w RFC nr 1305 z 1992 roku[15]. Wersja trzecia wprowadziła bardziej rozwinięte procedury wyboru zegara i analizy błędów, a specyfikacja NTPv4 z 2010 roku zastąpiła wcześniejsze dokumenty podstawowe i zintegrowała w jednym standardzie także uproszczony wariant SNTPv4[16][14][17][1].

Po RFC nr 5905 publikowano dalsze rozszerzenia i zalecenia, między innymi dotyczące pól rozszerzeń, zmian w kodzie uwierzytelniania wiadomości, najlepszych praktyk operacyjnych, losowania portu źródłowego klienta, rejestrów IANA i trybów z przeplatanymi znacznikami czasu. Nadal jednak za podstawowy protokół produkcyjny uznaje się NTPv4, a kolejne prace rozwojowe są prowadzone w ramach dokumentów aktualizujących i projektów roboczych IETF[18][19][20][21][22][23].

Zasada działania

[edytuj | edytuj kod]
Uproszczony schemat filtrów i algorytmów wyboru źródeł czasu w implementacji NTP.

NTP jest zwykle opisywany w modelu klient–serwer: klient okresowo odpytuje jeden lub kilka serwerów czasu, oblicza przesunięcie swojego zegara i stopniowo koryguje częstotliwość zegara systemowego. Ten sam protokół może jednak pracować także w trybach symetrycznych między równorzędnymi węzłami, a w sieciach lokalnych dopuszcza również rozgłaszanie lub multicast, w których klienci nasłuchują ogłoszeń czasu po wcześniejszym oszacowaniu opóźnienia ścieżki[1][24][25].

Pomiar opóźnienia i przesunięcia

[edytuj | edytuj kod]

Podstawowa wymiana klienta z serwerem wykorzystuje cztery znaczniki czasu: chwilę wysłania zapytania przez klienta, chwilę odebrania zapytania przez serwer, chwilę wysłania odpowiedzi przez serwer oraz chwilę odebrania odpowiedzi przez klienta. Na ich podstawie klient oblicza opóźnienie w obie strony oraz przesunięcie zegara względem serwera, a następnie przekazuje próbki do filtrów i algorytmów wyboru źródeł czasu[1].

  • t0 – czas wysłania zapytania przez klienta.
  • t1 – czas odebrania zapytania przez serwer.
  • t2 – czas wysłania odpowiedzi przez serwer.
  • t3 – czas odebrania odpowiedzi przez klienta.

Przy założeniu w przybliżeniu symetrycznej ścieżki sieciowej przesunięcie czasu θ i opóźnienie rundy δ są obliczane ze wzorów stosowanych w specyfikacji NTPv4[1]:

θ=(t1−t0)+(t2−t3)2
δ=(t3−t0)−(t2−t1)

Wartości te nie są zwykle stosowane bezpośrednio jako pojedyncza korekta. Implementacja porównuje próbki z wielu zapytań i, jeśli korzysta z wielu serwerów, odrzuca źródła odstające, wybiera najlepszych kandydatów oraz dyscyplinuje zegar lokalny przez zmianę jego częstotliwości lub – przy dużym błędzie początkowym – przez skokowe ustawienie czasu[1][26].

Skokowa zmiana czasu a dyscyplinowanie zegara

[edytuj | edytuj kod]

NTP rozróżnia dwa sposoby korekcji zegara systemowego. Skokowe ustawienie czasu, czyli operacja typu step, polega na bezpośrednim przesunięciu wartości zegara do nowej chwili. Jest stosowane zwykle przy starcie usługi i przy dużym błędzie zegara, ponieważ skokowa zmiana czasu może zaburzyć działanie innych uruchomionych programów, na przykład baz danych korzystających z transakcji, które źle znoszą cofnięcie czasu[1][7][27]. Dyscyplinowanie zegara, czyli operacja typu slew albo strojenie częstotliwości, polega na delikatnym przyspieszaniu lub spowalnianiu zegara systemowego, dzięki czemu czas pozostaje monotoniczny, a różnica względem źródła jest stopniowo niwelowana[1][26].

W typowych implementacjach próg między tymi dwoma trybami można konfigurować[7]. Dokumentacja chrony zaleca zwykle dopuszczać skok tylko w kilku pierwszych aktualizacjach po starcie usługi, ale na komputerach bez zegara czasu rzeczywistego i na maszynach wirtualnych wznawianych z błędnym czasem może być konieczne dopuszczenie go przy każdej aktualizacji[28]. W referencyjnej implementacji ntpd domyślnym progiem skoku jest błąd zegara o 128 ms. Mniejsze różnice są niwelowane przez dyscyplinowanie zegara, a dopiero większe powodują skokowe ustawienie czasu[7]. Specyfikacja NTPv4 dopuszcza skok dopiero wtedy, gdy przesunięcie przekracza próg skoku dłużej niż przez 900 s[1]. Próg ten wynosi w jej tekście 125 ms, a w dołączonym kodzie wzorcowym 128 ms[1]. Chrony potrafi też wyznaczyć tempo, w jakim zegar komputera spieszy się lub późni, i na tej podstawie go korygować, a w Linuksie śledzi również dryf zegara czasu rzeczywistego, by po uruchomieniu systemu ustawić czas z jego skorygowanego odczytu[7].

Interwał zapytań klient–serwer w NTP jest opisywany wykładniczo jako 2τ sekund. Protokół dopuszcza wartości τ od 4 (16 s) do 17 (około 36 h), a typowy klient korzysta z interwału rzędu kilkudziesięciu sekund do kilkunastu minut; sugerowane przez RFC nr 5905 domyślne granice minimalnego i maksymalnego interwału odpytywania wynoszą odpowiednio 6 i 10, czyli 64 s i 1024 s[1][26].

Algorytmy wyboru i kombinacji źródeł

[edytuj | edytuj kod]

Specyfikacja NTPv4 opisuje wieloetapowy proces decydujący o tym, którym serwerom warto zaufać i jaki jest wynikowy ofset zegara. Algorytm selection wykorzystuje wariant algorytmu przedziałów pewności znanego jako algorytm Marzullo(inne języki), aby z deklarowanych przedziałów dokładności kandydatów wybrać największy zbiór wzajemnie zgodnych truechimers i odrzucić wyraźnie odstające falsetickers. Następujący po nim algorytm grupowania (clustering) zacieśnia ten zbiór, a algorytm łączenia (combine) wylicza wynikowe przesunięcie jako średnią ważoną z najlepszych źródeł[1][26].

Wybrane próbki czasu trafiają do filtru, który dla każdego skojarzenia wybiera najlepsze próbki z ostatniego okna i ogranicza wpływ chwilowych skoków opóźnienia w sieci. Wynikowe przesunięcie i częstotliwość są podawane na clock discipline – pętlę sterującą zegarem systemowym, opisaną w specyfikacji jako połączenie pętli synchronizacji fazy (PLL) i pętli synchronizacji częstotliwości (FLL). Dzięki takiej strukturze NTP może utrzymać stabilny czas także wtedy, gdy jedno ze źródeł chwilowo zawiedzie albo zacznie zgłaszać oczywiście nieprawdziwy czas[1][6].

Hierarchia stratum

[edytuj | edytuj kod]
Schemat hierarchii serwerów i klientów NTP; żółte strzałki oznaczają połączenia bezpośrednie, czerwone – połączenia sieciowe.
Zegar główny United States Naval Observatory jako przykład infrastruktury wzorca czasu, z której pośrednio mogą korzystać serwery NTP.

NTP używa półhierarchicznego modelu źródeł czasu. Odległość logiczna od zegara odniesienia jest określana numerem stratum. Wraz ze wzrostem tego numeru dokładność zwykle maleje, zależnie od ścieżki sieciowej i stabilności zegara systemowego[1][6]. Numer ten nie jest jednak sam w sobie gwarancją jakości, bo niższe stratum często, ale nie zawsze wskazuje dokładniejszy zegar[29].

  • Stratum 0 to zegary odniesienia, czyli sprzęt uznawany za dokładny, na przykład odbiorniki systemów GNSS takich jak GPS, których satelity niosą zegary atomowe, lub naziemne odbiorniki sygnałów czasu typu DCF77[1][29][30]. Urządzenia takie nie są serwerami NTP w sieci, lecz synchronizują bezpośrednio serwery pierwotne (stratum 1)[1].
  • Stratum 1 to komputery lub serwery czasu bezpośrednio podłączone do źródła stratum 0, na przykład przez odbiornik GNSS, sygnał 1PPS, łącze szeregowe RS-232 przekazujące znacznik czasu albo przemysłowy kod czasu, taki jak IRIG-B[1][28].
  • Stratum 2 i kolejne tworzą warstwy serwerów synchronizowanych przez sieć z serwerami wyższej warstwy; mogą one jednocześnie służyć jako klienci i jako źródła czasu dla kolejnych hostów[1].
  • Stratum 16 oznacza w protokole stan niesynchronizowany, a wartości od 1 do 15 są używane do budowania drzewa zależności i unikania pętli synchronizacji[1].

Oprócz numeru stratum pakiet NTP zawiera identyfikator źródła odniesienia, czyli reference identifier lub refid. Dla serwerów bezpośrednio związanych ze źródłem odniesienia refid może wskazywać typ źródła, na przykład GPS, PPS albo DCF77; dla dalszych warstw może być kodowaną informacją o serwerze nadrzędnym. Specjalne wartości pola refid są używane także w komunikatach kiss-o'-death, którymi serwer może poprosić klienta o ograniczenie albo wstrzymanie zapytań[1][31].

Format komunikatu i znaczniki czasu

[edytuj | edytuj kod]

Podstawowy nagłówek NTPv4 ma 48 bajtów, po których mogą wystąpić pola rozszerzeń oraz dane uwierzytelniające. Pierwsze pola określają między innymi ostrzeżenie o sekundzie przestępnej, wersję protokołu, tryb pracy, stratum, interwał odpytywania i precyzję lokalnego zegara, a dalsze pola przenoszą informacje o opóźnieniu do źródła odniesienia, dyspersji, identyfikatorze źródła oraz cztery 64-bitowe znaczniki czasu[1].

PoleDługośćZnaczenie
LI, VN, Mode2 + 3 + 3 bitywskaźnik sekundy przestępnej, numer wersji i tryb asocjacji
Stratum8 bitówodległość od źródła odniesienia albo stan niesynchronizowany
Poll, Precisionpo 8 bitówinterwał zapytań i deklarowana precyzja zegara lokalnego
Root Delay32 bitycałkowite opóźnienie rundy do źródła odniesienia
Root Dispersion32 bityoszacowana dyspersja względem źródła odniesienia
Reference ID32 bityidentyfikator źródła synchronizacji albo kod stanu
Reference, Origin, Receive, Transmit Timestamppo 64 bityznaczniki czasu używane do wyliczenia przesunięcia i opóźnienia

Znacznik czasu NTP ma postać liczby stałoprzecinkowej: 32 bity opisują sekundy, a 32 bity ułamek sekundy. Epoka tej skali zaczyna się 1 stycznia 1900 roku, co powoduje przepełnienie 32-bitowego pola sekund po 232 sekundach, czyli 7 lutego 2036 roku. Pojęcie ery wprowadzone w NTPv4 oraz 128-bitowy format daty mają służyć rozróżnianiu kolejnych okresów po przepełnieniu, choć standardowy pakiet w sieci pozostaje oparty na 64-bitowych znacznikach[1][32].

NTP potrafi rozgłaszać ostrzeżenie o nadchodzącej sekundzie przestępnej, ale samo wykonanie korekty zależy od implementacji systemu i konfiguracji. Niektóre infrastruktury zamiast skokowego wstawienia sekundy stosują rozsmarowanie sekundy przestępnej w dłuższym przedziale czasu, co opisano osobno w sekcji poświęconej sekundom przestępnym[1][20].

SNTP

[edytuj | edytuj kod]

Simple Network Time Protocol (SNTP) jest uproszczonym sposobem używania tego samego formatu pakietu i tego samego portu, a nie odrębnym, niezgodnym protokołem. Wczesne SNTPv3 opisano w RFC nr 1361, a SNTPv4 w RFC nr 2030 i RFC nr 4330; w RFC nr 5905 uproszczony wariant został włączony do głównej specyfikacji NTPv4 jako profil dla prostych serwerów i klientów[33][15][1].

SNTP może pomijać stałe przechowywanie stanu, zaawansowane filtrowanie, korelowanie wielu źródeł i dyscyplinowanie częstotliwości zegara typowe dla pełnych implementacji NTP. Dzięki temu nadaje się do prostych urządzeń lub środowisk, w których wymagana jest tylko podstawowa zgodność czasu, ale nie zastępuje pełnego NTP tam, gdzie potrzebna jest redundancja, wykrywanie błędnych serwerów i stabilna praca przez długi czas[15][1].

Implementacje

[edytuj | edytuj kod]

Sam protokół NTP nie jest tym samym co konkretna usługa systemowa go realizująca. W obiegu pozostaje równolegle kilka niezależnych implementacji o różnym zakresie funkcji, modelu bezpieczeństwa i typowych zastosowaniach[7][20].

ntpd – implementacja referencyjna

[edytuj | edytuj kod]

Klasyczna implementacja referencyjna NTP Project działa jako usługa systemowa o nazwie ntpd[4]. Zapoczątkował ją David L. Mills, a części jej kodu liczyły w 2017 roku co najmniej 25 lat[8]. Była portowana na wiele systemów operacyjnych, w tym Linux, FreeBSD i inne warianty uniksowe oraz Microsoft Windows, i obsługuje zarówno zdalne serwery czasu, jak i lokalne zegary odniesienia[7][8]. Jest najpełniejszą, a zarazem najbardziej złożoną implementacją protokołu, z dużą ilością przestarzałego kodu[8][34]. Sama specyfikacja NTPv4 zaznacza, że opisuje istniejącą implementację[1].

chrony

[edytuj | edytuj kod]

chrony(inne języki) jest niezależną implementacją NTP, napisaną od zera, a nie wywodzącą się z kodu ntpd[8]. Jej rozwój wspiera firma Red Hat, w której dystrybucjach Linuxa jest domyślną implementacją NTP[8]. Skompilowany demon chrony jest ponad trzykrotnie mniejszy niż w implementacji referencyjnej[7], a audyt bezpieczeństwa firmy Cure53 z 2017 roku ocenił oprogramowanie jako dobrze zaprojektowane i o minimalnej, niezbędnej złożoności[35][8]. Chrony szybko synchronizuje się także w środowiskach, w których referencyjna implementacja zachowuje się gorzej: na hostach z niestabilnym zegarem, na maszynach wirtualnych oraz przy przerywanej łączności internetowej[7][36]. Obsługuje ponadto Network Time Security i (w Linuksie) sprzętowe znaczniki czasu na kartach sieciowych[7][28].

NTPsec

[edytuj | edytuj kod]

NTPsec(inne języki) jest odgałęzieniem referencyjnej implementacji, utworzonym w czerwcu 2015 roku w odpowiedzi na narastające problemy klasycznego kodu, w tym z bezpieczeństwem[9][37]. Projekt usuwał z bazy kodu m.in. obsługę dawnych systemów uniksowych i przestarzały kod, co do 2017 roku pozwoliło wyrzucić niemal 75% kodu ntpd i zmniejszyć powierzchnię ataku[37][8]. Audyt Cure53 z 2017 roku stwierdził, że wiele zbędnego kodu udało się usunąć, ale wykazał też w NTPsec błąd regresji poprawki bezpieczeństwa, który nie dotyczył wersji referencyjnej[38].

ntpd-rs

[edytuj | edytuj kod]

ntpd-rs jest napisaną w języku Rust implementacją NTP i NTS, nastawioną na bezpieczeństwo i stabilność[39][40]. Projekt wywodzi się z inicjatywy Prossimo prowadzonej przez Internet Security Research Group(inne języki), której celem jest bezpieczeństwo pamięci najważniejszej infrastruktury internetu[40]. Od 2023 roku utrzymuje go firma Tweede golf w ramach projektu Pendulum, rozwijającego również implementację Precision Time Protocol o nazwie statime[40]. Od 2024 roku ntpd-rs działa w środowisku produkcyjnym urzędu certyfikacji Let’s Encrypt[41].

OpenNTPD

[edytuj | edytuj kod]

OpenNTPD(inne języki) wywodzi się z projektu OpenBSD, w którym pojawił się w wersji 3.6[42]. Implementuje Simple Network Time Protocol w wersji 4 (RFC nr 5905) i NTP w wersji 3 (RFC nr 1305), a czas może dodatkowo pobierać z serwerów HTTPS, by ograniczyć skutki ataków typu man-in-the-middle na nieuwierzytelnione NTP[42]. Stosuje rozdzielenie uprawnień i domyślnie nie udostępnia portu serwera NTP, a jego wersja przenośna działa m.in. w Linuksie, FreeBSD i NetBSD[7]. W symulacjach porównawczych projektu chrony we wszystkich testach osiągał mniejszą dokładność niż chrony[7].

systemd-timesyncd

[edytuj | edytuj kod]

systemd-timesyncd jest wbudowaną w systemd usługą, która implementuje wyłącznie SNTP, a nie pełne NTP[11]. Złożone zastosowania wymagające pełnego NTP nie są przez nią obsługiwane[11]. Serwery czasu pobiera z konfiguracji globalnej, z ustawień łączy sieciowych i z DHCP, a przy dużym przesunięciu ustawia zegar skokowo, przy mniejszym – stopniowo go koryguje[11]. Dokumentacja chrony opisuje go jako bardzo prostego klienta NTP, który nie potrafi odpytywać jednocześnie kilku serwerów ani wykrywać serwerów podających błędny czas, i dlatego powinien korzystać tylko z zaufanych serwerów, najlepiej w sieci lokalnej[28].

Windows Time

[edytuj | edytuj kod]

W systemach Microsoft Windows synchronizację czasu zapewnia usługa Windows Time (W32Time), niezbędna do działania uwierzytelniania Kerberos V5 w domenach Active Directory[10]. Kerberos wymaga zgodności czasu klienta i serwera w granicach 5 minut[29]. Usługa nie jest dokładną implementacją NTP, choć korzysta z algorytmów zdefiniowanych w jego specyfikacjach[10]. W wersjach wcześniejszych niż Windows 10 1607 i Windows Server 2016 zapewniała dokładność wystarczającą dla Kerberosa, a ściślejsze wymagania wykraczały poza jej założenia projektowe[43]. Od tych wersji producent dokumentuje warunki pozwalające osiągnąć dokładność 1 s, 50 ms lub 1 ms[43].

Wybór implementacji

[edytuj | edytuj kod]

W praktyce wybór implementacji zależy od celu wdrożenia. Serwery publiczne i infrastruktura przedsiębiorstwa wymagają zwykle kilku niezależnych źródeł czasu, kontroli obciążenia oraz monitorowania jakości synchronizacji, dlatego sięga się po pełne demony NTP, takie jak ntpd, chrony, NTPsec albo ntpd-rs. Stacje robocze i urządzenia wbudowane mogą korzystać z lżejszych klientów, w tym SNTP albo usług systemowych jak Windows Time lub systemd-timesyncd, ale ich możliwości w zakresie redundancji i dokładności są ograniczone[1][20][7].

Publiczne serwery i pula NTP

[edytuj | edytuj kod]

Większość użytkowników korzysta z czasu udostępnianego przez publicznie dostępne serwery NTP, którymi opiekują się instytucje metrologiczne, dostawcy usług internetowych albo wolontariusze. W Polsce szczególne znaczenie ma usługa Głównego Urzędu Miar, która przez Internet udostępnia synchronizację systemów komputerowych z czasem urzędowym obowiązującym w kraju. Według informacji GUM serwery e-CzasPL znajdują się w Laboratorium Czasu i Częstotliwości, są synchronizowane z państwowego wzorca jednostek miar czasu i częstotliwości, używają NTP, a usługa jest dostępna całodobowo i bezpłatnie[44].

Nazwa DNSAdres IPv4 podany przez GUM[44]Charakterystyka
tempus1.gum.gov.pl194.146.251.100publiczny serwer czasu urzędowego GUM
tempus2.gum.gov.pl194.146.251.101publiczny serwer czasu urzędowego GUM

Szczególne znaczenie ma projekt NTP Pool(inne języki), dostępny pod domeną pool.ntp.org – duży wirtualny klaster serwerów czasu, domyślny w większości głównych dystrybucji Linuksa[45]. Nazwy puli wskazują w DNS losowo wybrane serwery, zmieniane co godzinę, a system stara się przydzielić klientowi najbliższe dostępne serwery[46][47].

Pula udostępnia także podzbiory regionalne, na przykład europe.pool.ntp.org, oraz strefy krajowe takie jak pl.pool.ntp.org, co pozwala ograniczyć opóźnienia związane z trasami międzykontynentalnymi. W typowej konfiguracji klienta wskazuje się kilka nazw z prefiksami 0–3, co dla każdej domeny daje inną listę losowo wybranych serwerów; w dokumentacji projektu zaleca się używanie nie więcej niż czterech adresów oraz unikanie agresywnych opcji takich jak burst czy bardzo krótkich interwałów odpytywania[46].

NTP Pool prowadzi oddzielny program dla producentów urządzeń, tzw. vendor zone. Producent rejestruje własną nazwę domeny, na przykład 0.vendor.pool.ntp.org, i powinien wpisać ją w domyślną konfigurację swoich urządzeń zamiast głównych nazw puli. Bez zgody operatora producent nie powinien też wpisywać na stałe adresów ani nazw konkretnych serwerów[27]. Jako przykłady nadużyć serwerów NTP(inne języki) projekt przywołuje incydenty z 2003 roku (wadliwe routery zalewające ruchem serwer czasu University of Wisconsin) i z 2006 roku (błędna konfiguracja urządzeń D-Link)[27]. Sam projekt NTP Pool powstał w 2003 roku w odpowiedzi na szybko rosnące obciążenie popularnych serwerów NTP[27].

Projekt publikuje bieżące statystyki aktywnych serwerów według regionów i stref krajowych; wartości te zmieniają się w czasie wraz z dołączaniem i odłączaniem się wolontariuszy. Polska strefa puli pl.pool.ntp.org utrzymywała w 2026 roku kilkadziesiąt aktywnych serwerów IPv4 oraz mniejszą liczbę serwerów IPv6[45][47].

Projekt nie udziela gwarancji jakości ani dostępności[48]. Regulamin używania puli wprost zaznacza, że usługa jest świadczona przez wolontariuszy bez żadnych gwarancji, może w pojedynczych przypadkach dostarczyć całkowicie błędny czas i nie powinna być używana w zastosowaniach, w których błędny czas mógłby zaszkodzić życiu, działalności albo społeczności użytkownika[48]. W takich przypadkach strona projektu radzi skonfigurować lokalną, bezawaryjną usługę czasu odpowiednią do potrzeb[46]. Mimo tego zastrzeżenia NTP Pool jest ważnym źródłem czasu dla wielu systemów i urządzeń sieciowych; według strony projektu korzystają z niego setki milionów systemów. Badanie Beverly'ego i Rye'a z 2026 roku zebrało dziewięć miesięcy danych o puli, odnalazło ponad 15 tys. serwerów aktywnych i nieaktywnych oraz wskazało, że tylko 19,7% aktywnych serwerów było w pełni niezależnych po uwzględnieniu kont, aliasów adresowych i powiązań sieciowych, co ma znaczenie dla odporności puli na przejęcie dużej części ruchu przez jeden podmiot[46][45][49].

Sekundy przestępne i leap smear

[edytuj | edytuj kod]

NTP sygnalizuje sekundy przestępne w nagłówku pakietu w polu Leap Indicator. Wartości tego pola informują klienta, że ostatnia minuta bieżącego dnia trwa 61 sekund (dodatnia sekunda przestępna) albo 59 sekund (ujemna sekunda przestępna), pozwalają też sygnalizować stan niesynchronizowany. To, jak system operacyjny i aplikacje obsłużą tę informację, zależy od ich implementacji – wymóg ścisłej monotoniczności znaczników czasu sprawia, że niektóre systemy zatrzymują, powtarzają albo lekko spowalniają zegar w okolicy sekundy przestępnej[1][50][51].

Alternatywą wobec skokowej obsługi sekundy przestępnej jest leap smear, czyli rozsmarowanie korekty na dłuższy okres. Klasyczne wdrożenie Google Public NTP rozkłada dodatkową sekundę liniowo w oknie 24 godzin, od południa do południa czasu UTC: w tym okresie zegar serwerów puli Google biegnie o około 11,6 µs na sekundę wolniej niż czas referencyjny, a po zakończeniu okna czas znów pokrywa się z UTC. Ten sam standard stosuje Amazon w usługach AWS[52], a rozsmarowanie sekundy przestępnej na serwerach stratum 2 stosuje także Meta (dawniej Facebook)[30].

Rozsmarowanie sekundy przestępnej nie jest jedną, uniwersalną skalą czasu – różni operatorzy stosują różne okna i kształty korekty, a klient nie ma ustandaryzowanego sposobu, by rozpoznać, że serwer je stosuje[52][20]. Dlatego zalecenia najlepszych praktyk NTP (RFC nr 8633) zabraniają stosowania leap smear na publicznych serwerach NTP i konfigurowania klienta z mieszaniną serwerów rozsmarowujących i nierozsmarowujących[20]. Dokumentacja chrony zaleca z kolei, by klienci korzystali tylko z jednego serwera stosującego leap smear albo z kilku identycznie skonfigurowanych[28].

Bezpieczeństwo

[edytuj | edytuj kod]

Poprawny czas systemowy jest elementem bezpieczeństwa wielu usług, ponieważ wpływa na ważność certyfikatów, mechanizmy uwierzytelniania, dzienniki zdarzeń, odtwarzanie kolejności incydentów, TLS, DNSSEC, usługi katalogowe i protokoły routingu takie jak Border Gateway Protocol[3][29]. Fałszywe lub zmanipulowane odpowiedzi NTP mogą pośrednio osłabiać systemy zależne od poprawnej chronologii i terminów ważności kluczy[20][3].

Klasyczne mechanizmy uwierzytelniania

[edytuj | edytuj kod]

Klasyczne mechanizmy uwierzytelniania NTP obejmowały tryby z kluczami współdzielonymi oraz system Autokey opisany dla NTPv4 (RFC nr 5906), zaprojektowany przy założeniu, że rozwiązań IPsec nie da się przejąć bez zmian, bo wykluczałoby to bezstanowe serwery i poważnie pogarszało dokładność synchronizacji[53]. Badacze bezpieczeństwa wykryli jednak podatności w protokole Autokey, a aktualne zalecenia najlepszych praktyk stanowią, że nie należy go używać[20]. Tryb z kluczami współdzielonymi wymaga przekazania kluczy bezpiecznym kanałem spoza protokołu, co przy dużej liczbie potencjalnych klientów bywa kłopotliwe i zawodne[6][20]. Do obliczania kodu uwierzytelniającego zaleca się w tym trybie AES-128-CMAC zamiast uznanego za zbyt słaby MD5[20][19].

Microsoft opracował dodatkowo własne rozszerzenie uwierzytelniające MS-SNTP do NTP w wersji 3 i SNTP w wersji 4[54]. Komputery należące do domeny Active Directory synchronizują czas za pomocą zabezpieczonego protokołu NTP z uwierzytelnianiem[29]. Obsługę MS-SNTP przy współpracy z usługą Samba mają ntpd, chrony i NTPsec[7].

Network Time Security (NTS)

[edytuj | edytuj kod]

Network Time Security (NTS), zdefiniowane w RFC nr 8915, jest aktualnie podstawową nowoczesną metodą ochrony klienta przed podszyciem się pod serwer. Mechanizm rozdziela kosztowne uzgodnienie kluczy od bieżącej wymiany pakietów czasu: klient najpierw nawiązuje połączenie TLS z usługą NTS-KE (klucz: Key Establishment) zwykle na porcie 4460, negocjuje parametry kryptograficzne i otrzymuje pulę krótkotrwałych cookies wraz z materiałem kluczowym. W kolejnych krokach klient przesyła zwykłe pakiety NTP, ale opatruje je polami rozszerzeń zawierającymi unikalny identyfikator zapytania, jeden ze świeżych cookies oraz pole uwierzytelniające z wynikiem działania szyfrowania uwierzytelnianego (AEAD)[55][56].

Dzięki tej konstrukcji serwer NTP może pozostać bezstanowy, a koszt operacji asymetrycznych przenoszony jest na osobną usługę NTS-KE i ponoszony rzadziej niż przy każdej wymianie czasu. Projekt NTS świadomie dobiera wielkości pól rozszerzeń tak, aby odpowiedź serwera nie była istotnie większa niż zapytanie, co przeciwdziała wykorzystywaniu serwerów NTP w atakach wzmacniających. NTS nie eliminuje fizycznego problemu opóźniania pakietów przez napastnika, ale skutecznie utrudnia podszywanie się pod źródło czasu i modyfikowanie odpowiedzi w locie. Publiczne usługi NTP z obsługą NTS udostępniają między innymi Cloudflare i Netnod, a po stronie klienta NTS obsługują chrony, NTPsec i ntpd-rs[55][56][57][7].

Ataki wzmacniające i nadużycia

[edytuj | edytuj kod]

Serwery NTP bywały wykorzystywane w atakach odbiciowych i wzmacniających typu DRDoS, zwłaszcza gdy publicznie dostępne implementacje odpowiadały na kosztowne zapytania administracyjne, takie jak komenda monlist w starszych wersjach ntpd. W 2014 roku takie ataki generowały strumienie ruchu sięgające 100 Gb/s i wyłączały m.in. serwisy gier sieciowych, takie jak League of Legends[58]. Ograniczanie takich nadużyć wymaga aktualizacji oprogramowania, wyłączenia historycznie problematycznych poleceń monitorujących, filtrowania ruchu z fałszowanym adresem źródłowym (BCP 38), rate limitingu oraz właściwej konfiguracji serwerów publicznych i prywatnych[58][59][60].

W 2017 roku ta sama firma Cure53 zbadała w krótkim odstępie czasu trzy główne implementacje NTP[8]. Audyt chrony sfinansowała Core Infrastructure Initiative działająca przy Linux Foundation, a audyty ntpd i NTPsec – program Secure Open Source fundacji Mozilla[8]. W zestawieniu CII pod względem bezpieczeństwa najlepiej wypadło chrony, w którym wykryto tylko dwa problemy niskiej wagi, a najgorzej klasyczne ntpd[8]. Spójność czasu pozostaje krytyczna także dla aplikacji odległych od tradycyjnej administracji systemów[3]. Malhotra i in. (2015) zestawili na przykład, jak duże przesunięcie zegara wystarcza do ataku na poszczególne mechanizmy: minuty w przypadku uwierzytelniania Kerberos, dni w przypadku pamięci podręcznej DNS i infrastruktury RPKI zabezpieczającej routing BGP, miesiące w przypadku DNSSEC i rok w przypadku HSTS[3].

Dokładność i ograniczenia

[edytuj | edytuj kod]

Dokładność NTP jest ograniczona przede wszystkim przez zmienność opóźnień sieciowych, asymetrię tras w obu kierunkach oraz jakość lokalnego zegara. Jeśli pakiety klient–serwer i serwer–klient nie pokonują ścieżek o podobnym opóźnieniu, połowa różnicy między tymi opóźnieniami pojawia się jako błąd systematyczny oszacowania czasu[1][6]. Na ścieżkach o dużej asymetrii opóźnień, na przykład gdy jeden kierunek biegnie przez satelitę, a drugi łączem naziemnym, błąd może sięgać 100 ms i więcej, a bez wcześniejszej wiedzy o charakterystyce ścieżki nie da się go uniknąć[6].

W publicznym Internecie NTP jest projektowany raczej do stabilnej synchronizacji rzędu milisekund niż do ekstremalnej precyzji pomiarowej, a praktyczna dokładność zależy od trasy do serwera i obciążenia łączy[6][44]. W kontrolowanej sieci lokalnej, przy dobrych serwerach i niewielkiej zmienności opóźnień, NTP osiąga zwykle dokładności submilisekundowe, a przy sprzętowym znacznikowaniu czasu na karcie sieciowej, dobrych przełącznikach i krótkich interwałach odpytywania możliwa bywa nawet dokładność poniżej mikrosekundy[1][28][6].

Osobnym wyzwaniem jest synchronizacja w środowiskach wirtualizacji. Zegary maszyn wirtualnych mogą mieć znacznie większy dryf niż typowe, ich częstotliwość może się zmienić po migracji, a maszyna wstrzymana i wznowiona bywa uruchamiana z błędnym czasem[28]. W takich środowiskach demony NTP wymagają specjalnej konfiguracji, np. dopuszczenia skoku przy każdej aktualizacji, a niektóre implementacje, jak chrony, zaprojektowano z myślą o maszynach wirtualnych i niestabilnych zegarach[36][28][7].

Rozwój i przyszłość

[edytuj | edytuj kod]

W ramach grupy roboczej NTP w IETF prowadzone są prace nad NTPv5. Wersja opisana w marcu 2026 roku jako aktywny Internet-Draft draft-ietf-ntp-ntpv5-08 nie była jeszcze standardem produkcyjnym, lecz roboczym projektem, który zgodnie z zasadami IETF mógł zostać zmieniony, zastąpiony albo wygasnąć. Projekt definiuje przede wszystkim format protokołu przesyłanego w sieci, a nie konkretne algorytmy filtrowania pomiarów, wyboru źródeł czasu ani dyscyplinowania zegara[61].

Najważniejsze kierunki zmian w projekcie NTPv5 można traktować jako odpowiedź na wieloletnie problemy NTPv4: historyczne tryby pracy trudne do zabezpieczenia, niejednoznaczności pól rozszerzeń, ograniczenia identyfikatorów źródeł i 64-bitowych znaczników czasu oraz słabą prywatność części informacji wysyłanych przez klienta. Projekt przewiduje zachowanie kompatybilności przez negocjację wersji: serwer obsługujący wiele wersji odpowiada wersją wskazaną przez klienta, jeśli ją wspiera[61].

Obszar zmian w NTPv5Kierunek projektowy
tryby pracypozostają tylko tryby klienta i serwera; usunięto tryby symetryczne, broadcast, control i private
zakres specyfikacjidokument opisuje protokół „na drucie”, a algorytmy klienta pozostawia implementacjom
format i rozszerzenianowy format komunikatu, pola rozszerzeń jako jedyny mechanizm opcjonalnych danych, MAC przeniesiony do pola rozszerzenia
skale czasu i eraobsługa UTC, TAI, UT1 i UTC z leap smear; przesyłanie numeru ery wydłuża jednoznaczny przedział czasu z 136 lat do około 35 tys. lat
dokładnośćpole korekty pozwalające przenosić zmienne opóźnienia wprowadzane przez urządzenia pośrednie, a rozdzielczość pól root delay/root dispersion ma wzrosnąć z około 15 µs do około 4 ns
bezpieczeństwo i prywatnośćjawniejsze użycie NTS i MAC oraz ograniczenie wycieku informacji o zegarze klienta, takich jak lokalne znaczniki czasu lub szacowana dokładność

Równolegle rozwija się infrastruktura dystrybucji czasu, a nie tylko sam protokół. W Polsce projekt e-CzasPL2, zaplanowany przez Główny Urząd Miar na lata 2025–2028, ma rozbudować kanały dostarczania czasu urzędowego m.in. o zapasowe centrum utrzymania czasu, co najmniej dwa fizycznie niezależne klastry serwerów pl.ntppool.org, bazę i monitoring krajowych źródeł czasu oraz autoryzowany sygnał czasu nadawany drogą radiową. Projekt jest uzasadniany między innymi zależnością systemów IT i OT od wiarygodnych źródeł czasu oraz ryzykiem ataków destabilizujących synchronizację[62].

Relacja do innych metod synchronizacji

[edytuj | edytuj kod]

NTP jest projektowany jako protokół ogólnego przeznaczenia dla heterogenicznych sieci, w tym publicznego Internetu. W zastosowaniach wymagających większej precyzji albo silniejszych gwarancji synchronizacji uzupełnia się go innymi technikami, a w niektórych obszarach zastępuje protokołami wyspecjalizowanymi[1][63].

  • Precision Time Protocol (IEEE 1588) służy najczęściej do synchronizacji urządzeń w wyspecjalizowanych sieciach automatyki przemysłowej i pomiarowych, połączonych szybkimi segmentami Ethernet z przełącznikami, i zwykle wykorzystuje sprzętowe znaczniki czasu w kartach sieciowych i przełącznikach[63]. Oczekiwana dokładność PTP jest rzędu 100 ns, lecz aby zachować dokładność poniżej mikrosekundy, przełączniki muszą kompensować czas przebywania ramki, a przy wielu przeskokach przez routery zalety PTP mogą zostać utracone[63]. NTP nie wymaga sprzętowego wsparcia przy rejestracji znaczników czasu[63], ale według dokumentacji chrony przy takim samym wsparciu jak PTP mógłby działać równie dobrze[28].
  • Sygnał 1PPS (ang. pulse per second) to impuls podawany raz na sekundę[28]. Serwer pierwotny z odbiornikiem GPS i sygnałem PPS osiąga dokładność rzędu kilku mikrosekund, co jest własnością sprzętu i systemu operacyjnego, a nie samego protokołu NTP[6][63]. Sygnał PPS z odbiornika GNSS doprowadza się zwykle do portu szeregowego albo wyprowadzenia GPIO komputera i stanowi znacznie dokładniejsze źródło czasu niż komunikaty odbiornika, dokładne zwykle do milisekund[28].
  • Systemy GNSS, takie jak GPS, mogą służyć serwerom stratum 1 za zegar odniesienia, dostarczając zarówno komunikaty z czasem, jak i sygnał 1PPS[1][28]. Odbiorniki czasu GPS są jednak podatne na ataki polegające na nadawaniu podrobionych sygnałów satelitarnych (spoofing), które pozwalają zmanipulować podawany przez nie czas[64].
  • White Rabbit to oparte na PTP rozwiązanie do synchronizacji z dokładnością poniżej nanosekundy[65].
  • Rolę zegarów odniesienia pełnią też odbiorniki naziemnych radiowych sygnałów czasu, takich jak DCF77, MSF czy WWVB[1]. NTP udostępnia czas z takich źródeł komputerom w sieci[1].

Pokrewne standardy synchronizacji

[edytuj | edytuj kod]

Oprócz NTP i samego protokołu PTP istnieją profile i normy dostosowane do konkretnych zastosowań. Podstawową specyfikacją PTP jest IEEE 1588; aktywną wersją standardu jest IEEE 1588-2019, która zastąpiła IEEE 1588-2008[66], choć część starszych profili, np. IEEE C37.238-2017, nadal odwołuje się do wersji z 2008 roku[67]. IEEE 802.1AS-2025 opisuje synchronizację czasu w sieciach lokalnych i metropolitalnych dla zastosowań wrażliwych czasowo z rodziny Time-Sensitive Networking(inne języki)[68]. Sektor telekomunikacyjny korzysta z profili PTP opisanych w zaleceniach ITU-T serii G.8275 – wariant G.8275.1 jest stosowany przy pełnym wsparciu sieci dla precyzyjnego znacznikowania czasu[69], a G.8275.2 w sieciach z częściowym wsparciem[70]. W energetyce profil IEEE C37.238 opisuje użycie IEEE 1588/PTP w aplikacjach ochrony, sterowania, automatyki i komunikacji systemów elektroenergetycznych[67].

Zastosowania

[edytuj | edytuj kod]

NTP jest używany w serwerach, stacjach roboczych, urządzeniach sieciowych, systemach wirtualizacji, klastrach obliczeniowych, usługach monitoringu i infrastrukturze internetowej. Spójny czas jest potrzebny do korelacji logów, poprawnej pracy mechanizmów kryptograficznych, replikacji baz danych, rozliczania transakcji oraz diagnozowania awarii w systemach rozproszonych[4][20][29].

Poza środowiskiem klasycznych centrów danych z puli NTP korzystają urządzenia Internetu rzeczy i infrastruktury na całym świecie[49]. NTP Project wymienia wśród zastosowań wymagających dokładnego czasu satelity, GPS, sieci 5G, usługi finansowe i ochronę zdrowia[4]. Chrony w Linuksie może korzystać z zegarów sprzętowych PTP w kartach sieciowych jako zegarów odniesienia[28], a dokumentacja NTP Project proponuje sterownik zegara odniesienia NTP oparty na PTP[63].

W sieciach zarządzanych źródła czasu mogą być ustawiane ręcznie, przez konfigurację systemową, przez usługę katalogową albo automatycznie przez mechanizmy konfiguracji sieci. DHCPv4 przewiduje osobną opcję przekazującą klientom listę serwerów NTP, natomiast same dane strefy czasowej są zagadnieniem oddzielnym od synchronizacji zegara do UTC[71][72].

Najbardziej niezawodne wdrożenia nie opierają się na pojedynczym serwerze czasu. Typowa dobra praktyka polega na użyciu kilku niezależnych źródeł, kontrolowaniu obciążenia publicznych serwerów, monitorowaniu odchylenia i stratum, odróżnieniu wewnętrznych serwerów czasu od klientów końcowych oraz unikaniu konfiguracji, które tworzą pętle synchronizacji albo zależność od jednego dostawcy czasu[20][1][46].

Zobacz też

[edytuj | edytuj kod]

Przypisy

[edytuj | edytuj kod]
  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 David L. Mills, Jim Martin, Jack Burbank, William Kasch: RFC nr 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force, 2010-06. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  2. ↑ Service Name and Transport Protocol Port Number Registry. IANA. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-17)]. (ang.).
  3. 1 2 3 4 5 Aanchal Malhotra, Isaac E. Cohen, Erik Brakke, Sharon Goldberg: Attacking the Network Time Protocol. Boston University, 2015. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-02)]. (ang.).
  4. 1 2 3 4 5 Welcome to the home of the Network Time Protocol (NTP) Project. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-15)]. (ang.).
  5. 1 2 David L. Mills: RFC nr 958: Network Time Protocol (NTP). Internet Engineering Task Force, 1985-09. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-02-19)]. (ang.).
  6. 1 2 3 4 5 6 7 8 9 David L. Mills: Executive Summary: Computer Network Time Synchronization. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-02-23)]. (ang.).
  7. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Comparison of NTP implementations. chrony project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-11)]. (ang.).
  8. 1 2 3 4 5 6 7 8 9 10 11 CII Audit Identifies Most Secure NTP Implementation. The Linux Foundation, 2017-09-28. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2022-08-15)]. (ang.).
  9. 1 2 The Secure Network Time Protocol (NTPsec) Distribution. NTPsec project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  10. 1 2 3 Windows Time Service (W32Time). Microsoft Learn. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-12)]. (ang.).
  11. 1 2 3 4 systemd-timesyncd.service. freedesktop.org. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-18)]. (ang.).
  12. ↑ David L. Mills: IEN 173: Time Synchronization in DCNET Hosts. Internet Experiment Note, 1981-02-25. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-09-22)]. (ang.).
  13. ↑ David L. Mills: RFC nr 778: DCNET Internet Clock Service. Internet Engineering Task Force, 1981-04. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-30)]. (ang.).
  14. 1 2 David L. Mills: RFC nr 1119: Network Time Protocol (Version 2) Specification and Implementation. Internet Engineering Task Force, 1989-09. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-03-30)]. (ang.).
  15. 1 2 3 RFC nr 4330: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Internet Engineering Task Force, 2006-01. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-20)]. (ang.).
  16. ↑ David L. Mills: RFC nr 1059: Network Time Protocol (Version 1) Specification and Implementation. Internet Engineering Task Force, 1988-07. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-12-28)]. (ang.).
  17. ↑ David L. Mills: RFC nr 1305: Network Time Protocol (Version 3) Specification, Implementation and Analysis. Internet Engineering Task Force, 1992-03. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-07)]. (ang.).
  18. ↑ RFC nr 7822: Network Time Protocol Version 4 Extension Fields. Internet Engineering Task Force, 2016-03. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-20)]. (ang.).
  19. 1 2 RFC nr 8573: Message Authentication Code for the Network Time Protocol. Internet Engineering Task Force, 2019-06. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-20)]. (ang.).
  20. 1 2 3 4 5 6 7 8 9 10 11 12 RFC nr 8633: Network Time Protocol Best Current Practices. Internet Engineering Task Force, 2019-07. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  21. ↑ RFC nr 9109: Network Time Protocol Version 4: Port Randomization. Internet Engineering Task Force, 2021-08. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-12-11)]. (ang.).
  22. ↑ RFC nr 9748: Updating the NTP Registries. Internet Engineering Task Force, 2025-02. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-01-07)]. (ang.).
  23. ↑ RFC nr 9769: NTP Interleaved Modes. Internet Engineering Task Force, 2025-05. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-01-07)]. (ang.).
  24. ↑ Association Management. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-02-10)]. (ang.).
  25. ↑ Automatic Server Discovery Schemes. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-03-05)]. (ang.).
  26. 1 2 3 4 David L. Mills: Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space. CRC Press, 2011. ISBN 978-1-4398-1464-2. (ang.).
  27. 1 2 3 4 Information for vendors. NTP Pool Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-11)]. (ang.).
  28. 1 2 3 4 5 6 7 8 9 10 11 12 13 chrony – Frequently Asked Questions. chrony project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-21)]. (ang.).
  29. 1 2 3 4 5 6 Accurate Time for Windows Server 2016. Microsoft Learn. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-10)]. (ang.).
  30. 1 2 Oleg Obleukhov: Building a more accurate time service at Facebook scale. Engineering at Meta, 2020-03-18. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-03-12)]. (ang.).
  31. ↑ Event Messages and Status Words. NTPsec documentation. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-17)]. (ang.).
  32. ↑ David L. Mills: The NTP Era and Era Numbering. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-12-13)]. (ang.).
  33. ↑ RFC nr 1361: Simple Network Time Protocol (SNTP). Internet Engineering Task Force, 1992-08. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-02-19)]. (ang.).
  34. ↑ Cure53: Pentest-Report NTP 01.2017. 2017. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-07)]. (ang.).
  35. ↑ Mario Heiderich: Pentest-Report Chrony 08.2017. 2017-08. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-07)]. (ang.).
  36. 1 2 chrony – Introduction. chrony project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-04)]. (ang.).
  37. 1 2 Eric S. Raymond: NTPsec: a Secure, Hardened NTP Implementation. Linux Journal, 2017-03-30. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-02-16)]. (ang.).
  38. ↑ Cure53: Pentest-Report NTPsec 01.2017. 2017. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-07)]. (ang.).
  39. ↑ ntpd-rs documentation. Pendulum project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-18)]. (ang.).
  40. 1 2 3 ntpd-rs (README). Pendulum project, GitHub. [dostęp 2026-10-31]. [zarchiwizowane z tego adresu (2026-09-09)]. (ang.).
  41. ↑ Josh Aas: More Memory Safety for Let's Encrypt: Deploying ntpd-rs. Let's Encrypt, 2024-06-24. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-13)]. (ang.).
  42. 1 2 ntpd(8). OpenBSD manual pages. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-03-22)]. (ang.).
  43. 1 2 Support boundary for high accuracy time. Microsoft Learn. [dostęp 2026-10-31]. [zarchiwizowane z tego adresu (2023-06-01)]. (ang.).
  44. 1 2 3 O e-CzasPL. Główny Urząd Miar. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-27)]. (pol.).
  45. 1 2 3 pool.ntp.org: public ntp time server for everyone. NTP Pool Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-15)]. (ang.).
  46. 1 2 3 4 5 Jak używać puli serwerów NTP. NTP Pool Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-25)]. (pol.).
  47. 1 2 Poland — pl.pool.ntp.org. NTP Pool Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-10-23)]. (ang.).
  48. 1 2 NTP Pool Project — Terms of Service. NTP Pool Project. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-04-25)]. (ang.).
  49. 1 2 Robert Beverly, Erik Rye: On Borrowed Time: Measurement-Informed Understanding of the NTP Pool's Robustness to Monopoly Attacks. arXiv, 2026-02-12. [dostęp 2026-05-17]. (ang.).
  50. ↑ David L. Mills: The NTP Timescale and Leap Seconds. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-18)]. (ang.).
  51. ↑ Leap Second Processing. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-11)]. (ang.).
  52. 1 2 Google Public NTP – Leap Smear. Google Developers. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-07)]. (ang.).
  53. ↑ RFC nr 5906: Network Time Protocol Version 4: Autokey Specification. Internet Engineering Task Force, 2010-06. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-20)]. (ang.).
  54. ↑ [MS-SNTP: Network Time Protocol (NTP) Authentication Extensions]. Microsoft Learn. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-03-31)]. (ang.).
  55. 1 2 RFC nr 8915: Network Time Security for the Network Time Protocol. Internet Engineering Task Force, 2020-09. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  56. 1 2 Network Time Security. Cloudflare Docs. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  57. ↑ How to use NTS. Netnod. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-05-03)]. (ang.).
  58. 1 2 Dan Goodin: New DoS attacks taking down game sites deliver crippling 100Gbps floods. Ars Technica, 2014-01-13. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2017-01-20)]. (ang.).
  59. ↑ NTP Security Notice. The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2022-02-06)]. (ang.).
  60. ↑ NTP contains multiple vulnerabilities. CERT/CC Vulnerability Notes Database. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-02)]. (ang.).
  61. 1 2 Miroslav Lichvar, Tal Mizrahi: Network Time Protocol Version 5. Internet Engineering Task Force, 2026-03-02. [dostęp 2026-05-17]. (ang.).
  62. ↑ e-CzasPL2 – nowe kanały dystrybucji czasu urzędowego obowiązującego na obszarze RP w celu poprawienia i wzmocnienia cyberbezpieczeństwa kraju i obywateli. Główny Urząd Miar. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-27)]. (pol.).
  63. 1 2 3 4 5 6 IEEE 1588 Precision Time Protocol (PTP). The NTP Project. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2025-12-02)]. (ang.).
  64. ↑ Daniel P. Shepard, Todd E. Humphreys, Aaron A. Fansler. Evaluation of the vulnerability of phasor measurement units to GPS spoofing attacks. „International Journal of Critical Infrastructure Protection”. 5 (3–4), s. 146–153, 2012-12. DOI: 10.1016/j.ijcip.2012.09.003. (ang.).
  65. ↑ Maciej Lipiński, Tomasz Włostowski, Javier Serrano, Pablo Alvarez. White rabbit: a PTP application for robust sub-nanosecond synchronization. „2011 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication”, s. 25–30, 2011. DOI: 10.1109/ISPCS.2011.6070148. (ang.).
  66. ↑ IEEE 1588-2019: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. IEEE Standards Association. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-10-01)]. (ang.).
  67. 1 2 IEEE C37.238-2017: IEEE Standard Profile for Use of IEEE 1588 Precision Time Protocol in Power System Applications. IEEE Standards Association. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-01-05)]. (ang.).
  68. ↑ IEEE 802.1AS-2025: IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications. IEEE Standards Association. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-02-09)]. (ang.).
  69. ↑ ITU-T Recommendation G.8275.1: Precision time protocol telecom profile for phase/time synchronization with full timing support from the network. International Telecommunication Union. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2023-12-13)]. (ang.).
  70. ↑ ITU-T Recommendation G.8275.2: Precision time protocol telecom profile for phase/time synchronization with partial timing support from the network. International Telecommunication Union. [dostęp 2026-05-18]. [zarchiwizowane z tego adresu (2026-03-09)]. (ang.).
  71. ↑ RFC nr 2132: DHCP Options and BOOTP Vendor Extensions. Internet Engineering Task Force, 1997-03. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-05-11)]. (ang.).
  72. ↑ RFC nr 4833: Timezone Options for DHCP. Internet Engineering Task Force, 2007-04. [dostęp 2026-05-17]. [zarchiwizowane z tego adresu (2026-04-30)]. (ang.).

Linki zewnętrzne

[edytuj | edytuj kod]
  • The NTP Project
  • NTP Pool Project – wersja polska
  • Dokumenty grupy roboczej NTP w IETF
  • D.L. Mills, DCNET Internet Clock Service, RFC 778, IETF, kwiecień 1981, DOI: 10.17487/RFC0778, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D.L. Mills, DCN Local-Network Protocols, STD 44, RFC 891, IETF, grudzień 1983, DOI: 10.17487/RFC0891, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D.L. Mills, Algorithms for synchronizing network clocks, RFC 956, IETF, wrzesień 1985, DOI: 10.17487/RFC0956, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D.L. Mills, Network Time Protocol (NTP), RFC 958, IETF, wrzesień 1985, DOI: 10.17487/RFC0958, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D. Mills, Network Time Protocol (Version 3) Specification, Implementation and Analysis, RFC 1305, IETF, marzec 1992, DOI: 10.17487/RFC1305, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D. Mills, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 4330, IETF, styczeń 2006, DOI: 10.17487/RFC4330, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D. Mills, J. Martin, J. Burbank, W. Kasch, Network Time Protocol Version 4: Protocol and Algorithms Specification, RFC 5905, IETF, czerwiec 2010, DOI: 10.17487/RFC5905, ISSN 2070-1721, OCLC 943595667 (ang.).
  • B. Haberman, D. Mills, Network Time Protocol Version 4: Autokey Specification, RFC 5906, IETF, czerwiec 2010, DOI: 10.17487/RFC5906, ISSN 2070-1721, OCLC 943595667 (ang.).
  • H. Gerstung, C. Elliott, B. Haberman, Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4), RFC 5907, IETF, czerwiec 2010, DOI: 10.17487/RFC5907, ISSN 2070-1721, OCLC 943595667 (ang.).
  • R. Gayraud, B. Lourdelet, Network Time Protocol (NTP) Server Option for DHCPv6, RFC 5908, IETF, czerwiec 2010, DOI: 10.17487/RFC5908, ISSN 2070-1721, OCLC 943595667 (ang.).
  • J-M. Combes, S. Krishnan, G. Daley, Securing Neighbor Discovery Proxy: Problem Statement, RFC 5909, IETF, lipiec 2010, DOI: 10.17487/RFC5909, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D. Reilly, H. Stenn, D. Sibold, Network Time Protocol Best Current Practices, BCP 223, RFC 8633, IETF, lipiec 2019, DOI: 10.17487/RFC8633, ISSN 2070-1721, OCLC 943595667 (ang.).
  • D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad, Network Time Security for the Network Time Protocol, RFC 8915, IETF, wrzesień 2020, DOI: 10.17487/RFC8915, ISSN 2070-1721, OCLC 943595667 (ang.).
Źródło: „https://pl.wikipedia.org/w/index.php?title=Network_Time_Protocol&oldid=81129117”