Sophos Firewall jako przekaźnik NTP: przekazywanie przez NAT

Jeżeli urządzenia wewnętrzne muszą używać adresu IP bramy jako celu NTP, Sophos Firewall może przekazywać ich żądania przez NAT do serwera czasu. Ustawienie w Administration > Time synchronizuje natomiast wyłącznie zegar zapory; nie udostępnia klientom usługi serwera NTP.

Rozwiązaniem opisanym przez Sophos jest przekaźnik NTP przez NAT. Urządzenia wysyłają NTP na adres zapory, a Sophos Firewall tłumaczy adres docelowy i źródłowy oraz przekazuje pakiety do rzeczywistego zewnętrznego lub wewnętrznego serwera czasu. Zapora nie staje się źródłem czasu. Niezależnie od tego działa jako klient NTP dla własnego zegara.

Jest to szczególnie przydatne, jeśli urządzenia są na stałe skonfigurowane pod kątem adresu IP bramy, jeśli poprzednie środowisko UTM zostało zastąpione lub gdy potrzebna jest centralna kontrola celów NTP. W przypadku nowych projektów DHCP często wygodniej jest dystrybuować właściwy serwer czasu bezpośrednio za pomocą opcji DHCP. Podstawy można znaleźć w Konfigurowanie opcji DHCP w Sophos Firewall.

⚠️ Ważne: Sophos Firewall nie powinien udostępniać otwartej usługi NTP do Internetu. Strefy źródłowe, sieci źródłowe, serwery docelowe i reguły zapory muszą być celowo ograniczane. WAN jako Source Zone jest zwykle niepoprawny dla tego wzorca.

Który wariant jest odpowiedni?

NTP poprzez NAT to pragmatyczny wzorzec, ale nie zawsze najlepsza architektura.

Dla tego artykułu istotne są dwa warianty:

• Wariant A: Urządzenia wewnętrzne wykorzystują adres IP zapory jako serwer NTP, zapora przekazuje dalej do zewnętrznego serwera NTP.
• Wariant B: Urządzenia wewnętrzne wykorzystują adres IP zapory jako serwer NTP, zapora przekazuje dalej do wewnętrznego serwera NTP. Ponadto wewnętrzny serwer NTP musi mieć możliwość synchronizacji zewnętrznej.

Drugi wariant obejmuje zatem dwie odrębne ścieżki ruchu. Jeśli synchronizacja wewnętrznego serwera czasu ze źródłem zewnętrznym jest już odpowiednio dozwolona i objęta translacją, należy sprawdzić i wykorzystać istniejącą parę reguł; dodatkowe identyczne reguły nie są potrzebne.

Wymagania

Przed konfiguracją te punkty powinny być jasne:

• Które sieci wewnętrzne mogą używać NTP?
• Którego adresu IP klienci używają jako miejsca docelowego NTP, na przykład adresu IP bramy?
• Którego prawdziwego serwera NTP użyć?
• Czy należy używać wewnętrznego serwera czasu czy usługi zewnętrznej, takiej jak time.google.com lub pool.ntp.org?
• Czy firewall może niezawodnie rozwiązywać DNS dla celów FQDN?
• Czy czas systemowy zapory jest poprawnie zsynchronizowany?

Spójny przykład IPv4 ułatwia przypisanie poszczególnych wartości:

• net_Internet-LAN: 10.10.11.0/24, interfejs wejściowy klientów Port2 w strefie wewnętrznej sieci klientów.
• host_internal-firewall-ip: host 10.10.11.1, adres IP zapory używany przez tych klientów.
• host_Google-NTP: FQDN time.google.com dla wariantu A i ewentualnie jako zewnętrzne źródło czasu serwera wewnętrznego.
• NTP_Server_Internal: host 192.168.20.10, osiągalny przez Port3 w strefie DMZ, dla wariantu B.

Te adresy prywatne, nazwy obiektów i interfejsy są przykładami i należy zastąpić je rzeczywistymi wartościami. Należy wybrać wyłącznie sieci wymagające przekaźnika oraz ich rzeczywiste interfejsy wejściowe; w razie potrzeby dla IOT_NET dodaje się osobną, równie ściśle ograniczoną regułę. Obiekty sieci i hostów tworzy się w Hosts and services > IP host. Przy wielu adresach IP bramy odpowiadające im sieci źródłowe, wejścia i adresy docelowe muszą być spójne. Przed zmianami należy zapisać istniejące reguły NAT i zapory, ich kolejność oraz źródło czasu klientów; rzeczywisty serwer czasu musi być osiągalny i akceptować żądania z adresu zapory używanego przez MASQ.

Prawidłowy czas jest ważny dla funkcji krytycznych czasowo, takich jak uwierzytelnianie MFA, WAF, certyfikaty, logi, VPN i korelacja zdarzeń SIEM. Jeżeli sama zapora sieciowa ma nieprawidłowy czas, przed przekierowaniem ruchu NTP klientów należy najpierw sprawdzić czas systemowy.

Poniższe kroki opierają się na oficjalnej dokumentacji Sophos Firewall 22.0 (weryfikacja źródeł: 17.10.2026). Na potrzeby tej instrukcji nie przeprowadzono testu na urządzeniu. Ustawień NTP zapory nie można synchronizować z Sophos Fusion (wcześniej Sophos Central); należy je skonfigurować w WebAdmin, przez CLI lub API. Poniższe kroki NAT i firewall dotyczą WebAdmin.

Przykłady celowo używają konfiguracji IPv4, a podczas tworzenia hosta wybrano IP version: IPv4. W środowiskach IPv6 lub dual-stack nie należy po prostu kopiować tego wzorca. Najpierw trzeba wyjaśnić, czy klienci naprawdę potrzebują NTP przez IPv6, które funkcje firewall i NAT obowiązują w używanej wersji SFOS oraz czy DHCPv6, Router Advertisements albo bezpośredni wewnętrzny serwer czasu nie będą czystszym rozwiązaniem.

Skrót konfiguracji

Dla doświadczonych administratorów logika jest prosta: klienci wysyłają UDP 123 na adres IP firewalla lub bramy. Reguła DNAT zmienia cel na rzeczywisty serwer NTP, reguła firewall zezwala dokładnie na ten ruch, a Log Viewer potwierdza następnie Firewall Rule ID i NAT Rule ID.

Zewnętrzny serwer NTP: reguła DNAT przekazuje NTP z adresu IP firewalla do obiektu FQDN lub hosta zewnętrznego serwera NTP. Reguła firewall zezwala na NTP z odpowiednich źródeł wewnętrznych w kierunku WAN. W ogólnym przykładzie przekaźnika Sophos pozostawia Original destination jako Any; w opisanym tutaj przekaźniku z adresem IP bramy pole ogranicza się do konkretnego adresu IP zapory używanego przez klientów. Dzięki temu bezpośrednie żądania NTP do innych celów nie zostaną niezauważenie przekierowane.

Wewnętrzny serwer NTP: potrzebne są dwa przepływy. Najpierw wewnętrzny serwer NTP musi móc synchronizować się na zewnątrz przez SNAT/MASQ. Następnie reguła DNAT przekazuje żądania klientów z adresu IP firewalla do wewnętrznego serwera NTP. Obie pary reguł należy sprawdzić osobno w Log Viewer.

Przy pierwszym wdrożeniu pozycja reguły powinna być celowo wysoka, zwykle Top albo nad szerokimi regułami LAN-to-WAN i ogólnymi regułami NAT. Później można włączyć ją w istniejącą koncepcję reguł, o ile Log Viewer i Packet Capture nadal pokazują, że oczekiwana reguła pasuje jako pierwsza.

host_internal-firewall-ip zawiera wewnętrzny adres IP LAN zapory Sophos Firewall, tutaj 10.10.11.1. Klienci wpisują ten adres jako serwer NTP. Zastąp przykład wewnętrznym adresem LAN zapory we własnej sieci klientów i dostosuj net_Internet-LAN (10.10.11.0/24), interfejs wejściowy oraz strefę źródłową. Tutaj wejściem jest Port2 ze strefą wewnętrznej sieci klientów; Port1 należy do DMZ i nie jest używany. Obie reguły korzystają z wbudowanej usługi NTP; dodatkowa usługa tylko UDP nie jest wymagana. Ten przykład konfiguracji nie dowodzi udanego testu w rzeczywistym ruchu. Wybierz strefę przypisaną do sieci klientów w swoim środowisku; „wewnętrzna strefa LAN” to opis, a nie wymagana nazwa strefy.

W Hosts and services > IP host > Add utwórz dwa poniższe obiekty IPv4 i zapisz każdy przyciskiem Save. Jeśli odpowiednie obiekty już istnieją, użyj ich ponownie.

Wariant A: Zewnętrzny serwer NTP

Ten wariant jest odpowiedni, jeśli klienci mają używać adresu IP zapory jako serwera NTP i nie ma własnego wewnętrznego serwera czasu. Zapora tłumaczy żądanie NTP na zewnętrzny serwer czasu, na przykład time.google.com lub celowo wybrany serwer czasu dostawcy.

Google Public NTP (time.google.com) stosuje leap smear. Nie łącz go ze źródłami czasu bez leap smear.

Tworzenie hosta FQDN dla zewnętrznego serwera NTP

Ścieżka menu to:

Hosts and services > FQDN host

Procedura:

1. Należy wybrać Add.
2. Należy nadać Name, na przykład host_Google-NTP.
3. Należy wpisać zewnętrzny serwer NTP w polu FQDN, na przykład time.google.com.
4. Należy zapisać.

Jeśli zamiast nazwy FQDN używany jest wewnętrzny lub zewnętrzny serwer czasu ze stałym adresem IP, większy sens może mieć normalny obiekt hosta. Ważne jest, aby cel mógł być później wyraźnie rozpoznany w NAT i regule zapory.

Tworzenie reguły NAT dla zewnętrznego serwera NTP

Reguła NAT zapewnia, że żądania NTP kierowane do adresu IP zapory są przepisywane na zewnętrzny serwer czasu. Ścieżka menu to:

Rules and policies > NAT rules

Procedura:

1. Należy wybrać Add NAT rule > New NAT rule.
2. Należy ustawić Rule name, na przykład DNAT_Client_NTP_to_External.
3. Należy ustawić Rule position na Top lub umieścić ponad ogólnymi regułami NAT.
4. Należy ustawić Original source na odpowiednią sieć wewnętrzną, w przykładzie net_Internet-LAN (10.10.11.0/24).
5. Należy ustawić Original destination na host_internal-firewall-ip, w przykładzie 10.10.11.1.
6. W przypadku Original service należy usunąć Any i wybrać NTP.
7. Dla Translated source (SNAT) należy wybrać MASQ.
8. W przypadku Translated destination (DNAT) należy wybrać hosta FQDN lub hosta zewnętrznego serwera NTP.
9. W polu Inbound interface należy usunąć Any i wybrać rzeczywisty interfejs wejściowy klientów, w przykładzie Port2. Sophos dopuszcza alternatywnie Any, ale jawny wybór zapobiega dopasowaniu niezamierzonych wejść.
10. Należy pozostawić Translated service (PAT) jako Original, aby UDP 123 nie uległ zmianie. Outbound interface pozostaje dla tej reguły DNAT jako Any; wyjście określa trasa do celu po translacji.
11. Należy zapisać.

⚠️ Nie zostawiać Original destination otwartego: jeżeli Original destination nie zostanie ograniczone do adresu IP firewalla lub bramy, reguła może działać znacznie szerzej, zależnie od reszty projektu NAT. Wtedy przekierowywany może być nie tylko ruch do adresu IP firewalla, ale także ruch NTP z sieci może zostać przezroczysto zawrócony. W przypadku kontrolowanego przekaźnika reguła powinna pasować tylko wtedy, gdy klienci naprawdę używają adresu IP firewalla lub bramy jako celu NTP. W widoku szczegółowym należy zwrócić szczególną uwagę na cztery punkty: Original Destination musi wskazywać rzeczywisty adres IP zapory lub bramy, usługa musi pozostać ograniczona do NTP lub UDP 123, przetłumaczone miejsce docelowe musi wskazywać planowany serwer czasu, a SNAT powinien odpowiadać trasie powrotnej.

Jeśli podstawy NAT lub pola DNAT są niejasne, pomocne będzie Zrozum NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT. Wyjaśnia także, dlaczego NAT nie zastępuje zezwolenia udzielonego przez regułę zapory.

Zezwolenie na zewnętrzny NTP w regule zapory

Po utworzeniu reguły NAT potrzebna jest odpowiednia reguła zapory. Umożliwia to ruch NTP z sieci wewnętrznych do serwera docelowego. Ścieżka menu to:

Rules and policies > Firewall rules

Procedura:

1. Należy wybrać Add firewall rule > New firewall rule.
2. Należy ustawić Rule name, na przykład NTP_LAN_to_Google.
3. Należy ustawić Rule position na Top albo umieścić regułę nad ogólnymi regułami LAN-to-WAN, jeśli inaczej pasowałyby wcześniej.
4. Należy włączyć Log firewall traffic.
5. Należy ustawić Source zones na strefy wewnętrzne, na przykład wewnętrzną strefę LAN, DMZ lub strefę IoT. WAN i Any są niepoprawne dla tego wzorca.
6. Należy ustawić Source networks and devices dla odpowiednich sieci lub urządzeń. Nie należy wybierać ogólnego Any, jeśli tylko określone sieci mają korzystać z NTP.
7. Należy ustawić Destination zones na WAN.
8. Należy ustawić Destination networks na obiekt hosta IPv4 dla adresu IP zapory lub bramy, którego klienci używają jako celu NTP, na przykład host_internal-firewall-ip. Jeśli go brakuje, należy utworzyć go w Hosts and services > IP host > Add, wybierając Type: IP i dokładnie ten adres IP. Musi odpowiadać Original destination w regule DNAT klientów, a nie zewnętrznemu hostowi NTP.
9. Należy ustawić Services na NTP.
10. Należy ustawić Action na Accept.
11. Należy zapisać.

W oficjalnych lub uproszczonych przykładach przy Source networks and devices czasem pojawia się Any. W laboratorium jest to wygodne, ale w produkcji rzadko jest najlepszym wyborem. Czystszy jest konkretny obiekt sieciowy, taki jak net_Internet-LAN, IOT_NET albo mała grupa hostów, aby później było jasne, które urządzenia mogą używać tego przekazywania NTP.

Przy przychodzącym DNAT Sophos najpierw ustala przetłumaczony cel. Destination zones używa jego strefy, tutaj WAN; Destination networks używa natomiast pierwotnego celu, tutaj adresu IP zapory lub bramy. Rzeczywisty serwer czasu pozostaje wyłącznie w Translated destination (DNAT). Ogólny przykład NTP Sophos pomija Destination networks; to rozróżnienie wynika z jego szczegółowych przykładów DNAT i loopback. Po zmianie należy uruchomić nową sesję NTP z klienta: istniejące sesje nie są ponownie oceniane według zmienionych reguł NAT. Przed zatwierdzeniem konfiguracji należy sprawdzić Firewall Rule ID, NAT Rule ID oraz drogę pakietów przychodzących i przekazywanych zgodnie z sekcją testów; sama konfiguracja nie dowodzi udanej synchronizacji.

Reguła powinna być zarówno skuteczna, jak i czytelna. Nazwa taka jak NTP_LAN_to_Google lub IOT_to_NTP_internal jest później łatwiejsza do zrozumienia niż ogólna reguła z Any.

Rejestrowanie ruchu przez tę regułę jest pomocne podczas wdrożenia. Po teście powinno być widać w Log Viewer, z której sieci klienckiej przyszło żądanie, z jakiego Firewall Rule ID skorzystano i czy oczekiwany NAT Rule ID też jest widoczny. Jeśli nie pojawi się żaden identyfikator reguły lub pojawi się niewłaściwa reguła, kolejność lub dopasowanie reguły jest ważniejsze niż sama konfiguracja NTP.

Zasady tworzenia reguł, ich kolejność, usługi i rejestrowanie opisano również w artykule Zrozumienie i prawidłowe skonfigurowanie reguł Sophos Firewall.

Wariant B: Wewnętrzny serwer NTP

Ten wariant jest odpowiedni, jeśli źródłem czasu dla klientów ma być wewnętrzny kontroler domeny, serwer czasu Linux lub inny system wewnętrzny, ale klienci w dalszym ciągu korzystają z adresu IP zapory jako serwera NTP.

Należy sprawdzić dwie ścieżki ruchu wraz z ich parami reguł; odpowiednie istniejące reguły można wykorzystać ponownie:

Tworzenie hosta dla wewnętrznego serwera NTP

Ścieżka menu to:

Hosts and services > IP host

Procedura:

1. Należy wybrać Add.
2. Należy ustawić Name, na przykład NTP_Server_Internal.
3. Należy ustawić IP version na IPv4, jeśli używany jest IPv4.
4. Należy ustawić Type na IP.
5. Należy wpisać IP address wewnętrznego serwera NTP, w przykładzie 192.168.20.10.
6. Należy zapisać.

Para reguł 1: Wewnętrzny serwer NTP synchronizuje się zewnętrznie

Najpierw wewnętrzny serwer NTP musi mieć dostęp do zewnętrznego serwera czasu, o ile nie synchronizuje się już w inny sposób. Jego skonfigurowanym nadrzędnym źródłem czasu musi być rzeczywisty serwer czasu, a nie adres IP bramy używany jako przekaźnik. Żądania mogą zostać skierowane z powrotem do tego samego serwera tylko wtedy, gdy jego ruch pasuje również do reguły DNAT przekaźnika, której przetłumaczonym celem jest ten serwer. W powyższym przykładzie sieć źródłowa i interfejs wejściowy wykluczają takie dopasowanie do reguły DNAT klientów; błędnie wybrany adres IP bramy może wtedy nie dostarczać użytecznego czasu.

Reguła NAT:

1. Należy otworzyć Rules and policies > NAT rules.
2. Należy wybrać Add NAT rule > New NAT rule.
3. Należy ustawić Rule name, na przykład SNAT_Internal_NTP_to_WAN.
4. Należy ustawić Rule position na Top lub odpowiednio powyżej szerokich reguł NAT.
5. Należy ustawić Original source na hosta NTP_Server_Internal.
6. Należy ustawić Original destination na planowane zewnętrzne źródło czasu, w przykładzie host_Google-NTP.
7. W polu Original service należy usunąć Any i wybrać NTP.
8. Dla Translated source (SNAT) należy wybrać MASQ; Translated destination (DNAT) i Translated service (PAT) pozostają jako Original.
9. Należy ustawić Inbound interface na interfejs wejściowy serwera wewnętrznego, w przykładzie Port3; należy ograniczyć Outbound interface do rzeczywiście używanego interfejsu WAN. Przy wielu połączeniach WAN należy uwzględnić wszystkie przewidziane wyjścia.
10. Należy zapisać.

Reguła zapory sieciowej:

1. Należy otworzyć Rules and policies > Firewall rules.
2. Należy wybrać Add firewall rule > New firewall rule.
3. Należy ustawić Rule name, na przykład Internal_NTP_to_WAN.
4. Należy włączyć Log firewall traffic.
5. Należy ustawić Source zones na strefę wewnętrznego serwera NTP, w przykładzie DMZ.
6. Należy ustawić Source networks and devices na NTP_Server_Internal.
7. Należy ustawić Destination zones na WAN.
8. Należy ustawić Destination networks na to samo zewnętrzne źródło czasu co w regule SNAT, w przykładzie host_Google-NTP. Nie ma tu DNAT; pierwotny i rzeczywisty cel są identyczne.
9. Należy ustawić Services na NTP, a Action na Accept.
10. Należy umieścić regułę powyżej reguł ogólnych, które inaczej zostałyby dopasowane wcześniej, i zapisać.

Para reguł 2: Kierowanie klientów do wewnętrznego serwera NTP przez adres IP zapory

Następnie budowane jest właściwe przekazywanie: klienci wysyłają NTP na adres IP zapory, zapora przekazuje dalej do wewnętrznego serwera NTP.

Reguła NAT:

1. Należy otworzyć Rules and policies > NAT rules.
2. Należy wybrać Add NAT rule > New NAT rule.
3. Należy ustawić Rule name, na przykład DNAT_Client_NTP_to_Internal.
4. Należy ustawić Rule position na Top lub umieścić powyżej ogólnych reguł NAT.
5. Należy ustawić Original source na odpowiednie wewnętrzne sieci klienckie, w przykładzie net_Internet-LAN.
6. Należy ustawić Original destination na adres IP zapory lub bramy, którego klienci używają jako celu NTP, w przykładzie host_internal-firewall-ip.
7. W przypadku Original service należy usunąć Any i wybrać NTP.
8. Dla Translated source (SNAT) należy wybrać MASQ.
9. Dla Translated destination (DNAT) należy wybrać NTP_Server_Internal.
10. W polu Inbound interface należy wybrać odpowiednie wewnętrzne interfejsy klientów, w przykładzie Port2.
11. Należy pozostawić Translated service (PAT) jako Original; Outbound interface pozostaje dla tej reguły DNAT jako Any.
12. Należy zapisać.

Także tutaj Original destination jest kluczowe: reguła powinna tłumaczyć tylko żądania NTP kierowane do adresu IP firewalla lub bramy. Jeśli to pole pozostanie zbyt szerokie, firewall może przechwytywać także żądania NTP, które klienci chcieli wysłać bezpośrednio do innego serwera czasu.

Reguła zapory sieciowej:

1. Należy otworzyć Rules and policies > Firewall rules.
2. Należy wybrać Add firewall rule > New firewall rule.
3. Należy ustawić Rule name, na przykład LAN_to_Internal_NTP.
4. Należy włączyć Log firewall traffic.
5. Należy ustawić Source zones na wewnętrzne strefy klienckie. Należy unikać WAN i Any.
6. Należy ustawić Source networks and devices dla odpowiednich sieci klienckich.
7. Należy ustawić Destination zones na strefę wewnętrznego serwera NTP, np. wewnętrzną strefę LAN lub DMZ.
8. Należy ustawić Destination networks na obiekt hosta IPv4 dla pierwotnie adresowanego IP zapory lub bramy, na przykład host_internal-firewall-ip, tak jak Original destination w regule DNAT klientów. Nie należy wybierać NTP_Server_Internal; ten host pozostaje w Translated destination (DNAT).
9. Należy ustawić Services na NTP.
10. Należy ustawić Action na Accept. Należy umieścić regułę powyżej reguł ogólnych, które inaczej zostałyby dopasowane wcześniej, i zapisać. Także tutaj Destination zones odpowiada przetłumaczonemu celowi wewnętrznemu, natomiast Destination networks zawiera pierwotny adres IP zapory lub bramy. Dla tej pary reguł należy sprawdzić osobno nową sesję klienta, identyfikatory reguł i drogę pakietów. MASQ zapewnia jednoznaczną drogę powrotną przez firewall, ale ukrywa przed wewnętrznym serwerem NTP pierwotny adres IP klienta. Jeśli adres klienta jest potrzebny do logowania lub kontroli dostępu, należy zaplanować dostęp bezpośredni i odpowiednią trasę powrotną.

Jeśli sam wewnętrzny serwer NTP jest kontrolerem domeny, należy zachować szczególną ostrożność. Nie każda sieć kliencka musi łączyć się bezpośrednio z każdym kontrolerem domeny. Można zezwolić na NTP bez otwierania równie szerokiego dostępu kontrolera domeny.

Operacje, bezpieczeństwo i testowanie

Dobór IPS i funkcji zabezpieczeń

NTP jest niewielką usługą UDP, ale ruch na porcie UDP 123 może mieć znaczenie w przypadku nadużyć, błędnej konfiguracji lub niepożądanych celów zewnętrznych. Jeśli dostępna jest licencja Network Protection, sensowne może być ustawienie odpowiedniej polityki IPS w regule zapory.

W przypadku NTP ważniejsza niż jak największa liczba zabezpieczeń jest zwarta konstrukcja:

• Source Zone tylko wewnętrznie: zapobiega działaniu zapory ogniowej jak publiczny przekaźnik NTP.
• Konkretne sieci źródłowe: ogranicza NTP do klientów, serwerów lub urządzeń, które naprawdę potrzebują tego przekazywania.
• Określony serwer docelowy: ogranicza ruch pasujący do tej reguły przekaźnika do określonego serwera czasu i ułatwia analizę logów.
• Tylko usługa NTP: pozwala uniknąć zbyt szerokiej reguły UDP.
• Należy włączyć rejestrowanie: pokazuje w Log Viewer, czy Firewall Rule ID i NAT Rule ID działają zgodnie z oczekiwaniami.

Dlatego system IPS należy postrzegać jako dodatkową kontrolę, a nie zamiennik precyzyjnej reguły. Jeśli reguła NTP zezwala tylko kilku sieciom wewnętrznym na zdefiniowany serwer czasu, najważniejszy zysk w zakresie bezpieczeństwa został już osiągnięty dzięki zakresowi i identyfikowalności. Kiedy w grę wchodzi duża liczba sieci, urządzenia o niejasnej roli lub obszary IoT/OT, ukierunkowana polityka IPS staje się bardziej interesująca.

Jeśli IPS jest używany w tej regule NTP, przypisana polityka IPS powinna wyraźnie uwzględniać sygnatury związane z NTP (IPS patterns). Dzięki temu dodatkowa ochrona jest ukierunkowana na ataki przeciwko usługom NTP; ogólne określenie polityki jako odpowiedniej nie zastępuje wyboru tych sygnatur.

⚠️ IPS wymaga odpowiedniej licencji na ochronę sieci. Jeśli IPS jest włączony na bardzo powszechnie stosowanej regule, należy monitorować dzienniki i wydajność. W przypadku prostego przekazywania NTP precyzyjne określenie zakresu jest ważniejsze niż niepotrzebnie szeroka kombinacja funkcji bezpieczeństwa.

Jeżeli wykorzystuje się w tym celu dedykowaną politykę IPS, nie należy stosować jej bez zmian do wszystkich sieci wewnętrznych. Bardziej sensowne jest posiadanie małej reguły z jasnym źródłem, zdefiniowanym celem NTP, aktywnym rejestrowaniem i późniejszą kontrolą w Log Viewer.

Pozostałe funkcje bezpieczeństwa należy stosować do NTP z rozwagą. W przypadku tej prostej usługi UDP, Web Filtering, TLS Inspection, Application Control lub Malware Scan zwykle nie pomagają w rzeczywistej funkcji NTP. Jeśli takie profile działają na regule zbiorczej, należy sprawdzić, czy ruchu NTP nie lepiej obsłużyć osobną, wąską regułą.

Przekazywanie serwera NTP przez DHCP

Jeśli klienci otrzymują konfigurację sieci przez DHCP, należy sprawdzić, czy przekazywanie NAT jest w ogóle konieczne. W wielu środowiskach wygodniej jest dystrybuować żądany serwer NTP bezpośrednio przez DHCP.

Jeśli istnieje kontroler domeny lub centralny serwer czasu, opcja DHCP 42 może wskazywać bezpośrednio na ten serwer, o ile dany klient rzeczywiście obsługuje tę opcję i z niej korzysta. Urządzenia należące do domeny mogą zamiast tego korzystać z domenowej hierarchii czasu; dlatego skuteczne źródło czasu należy sprawdzić na kliencie. NAT jest szczególnie przydatny, jeśli urządzenia już korzystają z adresu IP bramy lub są trudne do rekonfiguracji. W przypadku niestandardowych opcji DHCP lepszym punktem wyjścia jest artykuł Konfigurowanie opcji DHCP w Sophos Firewall.

Osobna konfiguracja zapory jako klienta NTP

Przekazywanie NTP dla klientów nie jest tym samym co czas systemowy Sophos Firewall. W Administration > Time w SFOS 22.0 dostępne są trzy ustawienia:

Niezmieniona bieżąca konfiguracja zegara zapory: Use pre-defined NTP server, Europe/Zurich. To ustawienie jest niezależne od przekaźnika klientów i nie dowodzi poprawnej synchronizacji; nie użyto Sync now ani Apply.

• Use predefined NTP server jest ustawieniem domyślnym. Zapora korzysta z NTPv3 i 0.sophos.pool.ntp.org.
• Use custom NTP server akceptuje adresy IPv4, IPv6 lub nazwy DNS; maksymalnie dziesięć serwerów jest sprawdzanych w wyświetlonej kolejności.
• Do not use NTP server pozwala ręcznie ustawić datę i czas i nie jest zalecane w normalnej pracy.

Po wybraniu serwera można wybrać Sync now, a następnie Apply. Po Sync now pole Current time aktualizuje się dopiero po ponownym załadowaniu WebAdmin. Na tej samej stronie ustawia się strefę czasową odpowiednią dla lokalizacji.

⚠️ Wpływ na VPN: według Sophos zmiana serwerów czasu NTP powoduje ponowne zestawienie wszystkich połączeń IPsec. Zmianę należy więc zaplanować w odpowiednim oknie serwisowym.

Oba przepływy należy sprawdzać osobno:

• Czas systemu zapory ogniowej: dotyczy Log Viewer, certyfikatów, uwierzytelniania MFA, VPN, uwierzytelniania WAF, raportów, Syslog i analizy wsparcia.
• NTP klientów przez NAT: urządzenia w sieci wewnętrznej uzyskują czas przez adres IP bramy lub przekierowany adres NTP.

Jeśli sama zapora ma nieprawidłowy czas lub strefę czasową, korelacja wpisów w dzienniku może być trudna, sprawdzanie certyfikatów może zakończyć się niepowodzeniem lub uwierzytelnianie oparte na czasie, takie jak TOTP/MFA może powodować problemy. Następnie należy najpierw skorygować czas systemowy zapory ogniowej i dostęp zapory do NTP. Tylko wtedy ma sens sprawdzanie poprawności klienta NTP poprzez NAT.

W środowiskach SIEM lub Syslog ten punkt jest szczególnie ważny: zapora sieciowa może poprawnie kierować ruchem NTP i nadal wysyłać nieprawidłowe znaczniki czasu do SIEM, jeśli jej własny czas lub strefa czasowa jest niepoprawna.

Do przesyłania dzienników odpowiednia jest opcja Wysyłanie Syslog z Sophos Firewall do SIEM. W przypadku problemów z MFA należy również uwzględnić Włączanie MFA dla WebAdmin, VPN Portal i Remote Access w Sophos Firewall.

Testowanie NTP i lokalizowanie błędów

Po zapisaniu należy nie tylko sprawdzić, czy reguła istnieje. Kluczowe jest to, czy klient rzeczywiście może zsynchronizować czas przez NTP i czy dopasowywane są oczekiwane reguły NAT oraz zapory.

Test rozpoczyna się tak samo dla obu wariantów: klient z odpowiedniej sieci używa adresu IP zapory lub bramy jako serwera NTP. Następnie uruchamiana jest synchronizacja czasu lub następuje krótkie oczekiwanie, aż klient wyśle NTP.

Należy otworzyć Log viewer w prawym górnym rogu WebAdmin. W module Firewall opcja Add filter umożliwia filtrowanie według reguły, adresu IP lub portu; wyszukiwanie pełnotekstowe znajdzie też 123, adres IP klienta lub nazwę reguły. Logi sesji nie zawsze pojawiają się od razu: zapora zapisuje sesję przy wewnętrznym zdarzeniu Destroy. W przypadku UDP może być konieczne oczekiwanie na koniec sesji; UDP nie ma mechanizmu zamykania połączenia TCP.

W wariancie A powinno być widoczne:

• Klient pochodzi z oczekiwanej sieci wewnętrznej.
• Dopasowywana jest reguła zapory zezwalająca na zewnętrzny NTP.
• Reguła DNAT odpowiada zewnętrznemu źródłu czasu.
• Celem jest planowany zewnętrzny serwer NTP.

Dla wariantu B należy sprawdzić dwie rzeczy:

• Wewnętrzny serwer NTP może wysyłać NTP na zewnątrz.
• Żądania klientów są przekazywane przez DNAT z adresu IP zapory do wewnętrznego serwera NTP.

Jeżeli Log Viewer nie pokazuje jednoznacznie, która reguła jest dopasowywana, pomocne jest Diagnostics > Packet capture. W Configure wyrażenie BPF port 123 ogranicza przechwytywanie do NTP. Po włączeniu Packet capture pakiet przychodzący powinien pokazywać adres IP klienta, adres IP zapory i UDP 123; pakiet przekazywany pokazuje cel po translacji. NAT ID i Rule ID muszą odpowiadać utworzonym regułom. Incoming i Forwarded potwierdzają ścieżkę, natomiast Consumed oznacza pakiet przeznaczony dla samej zapory; Violation i Reason wyjaśniają odrzucenie.

Samo skuteczne przekazanie ruchu nie potwierdza jeszcze synchronizacji czasu. Dodatkowo status NTP na kliencie musi wskazywać prawidłową odpowiedź i stan synchronizacji; w wariancie B należy też sprawdzić status synchronizacji wewnętrznego serwera czasu. W przechwyconych pakietach oczekuje się odpowiedzi od rzeczywistego serwera czasu, a na drodze powrotnej do klienta ponownie adresu IP wskazanej bramy jako nadawcy. Jeśli odpowiedź nie nadchodzi, należy najpierw sprawdzić osiągalność, drogę powrotną i kontrolę dostępu serwera czasu dla adresu MASQ.

W ramach testu negatywnego klient z niedopuszczonej sieci wewnętrznej wysyła nowe żądanie NTP na adres IP bramy. Utworzona reguła DNAT klientów i odpowiadająca jej reguła zezwalająca nie mogą zostać dopasowane do tego ruchu. Jeśli żądanie mimo to zostaje przekazane, należy poszukać wcześniejszej lub szerszej reguły NAT albo zapory. Również żądanie dopuszczonego klienta skierowane bezpośrednio do innego adresu NTP nie może zostać przekierowane przez tę regułę DNAT adresu IP bramy. O tym, czy bezpośredni ruch NTP jest dozwolony czy blokowany, decydują pozostałe reguły zapory; sam przekaźnik nie wymusza centralnego źródła czasu dla całego ruchu.

Jeśli nie są widoczne żadne dzienniki, klient może w ogóle nie wysyłać żądania, reguła zapory nie rejestruje danych lub ruch odbywa się inną ścieżką. Testuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture nadaje się do systematycznej kontroli.

W przypadku problemów z NTP samej zapory istotny jest również dziennik klienta NTP. Przegląd dzienników znajduje się w Sophos Firewall Troubleshooting: Services and Logs.

Krótka weryfikacja końcowa

Przed zakończeniem wdrożenia produkcyjnego należy potwierdzić pięć punktów:

1. Klienci rzeczywiście używają adresu IP zapory lub bramy jako serwera NTP.
2. Reguły NTP dopuszczają jedynie zamierzone wewnętrzne sieci źródłowe.
3. Oczekiwane Firewall Rule ID i NAT Rule ID są widoczne w Log Viewer.
4. Czas systemowy zapory jest prawidłowy niezależnie od przekaźnika.
5. Po zmianach DHCP, VLAN, NAT lub reguł należy ponownie sprawdzić NTP.

Typowe błędy

• WAN dozwolony jako Source Zone: Zapora sieciowa może w niezamierzony sposób działać jak otwarty przekaźnik NTP. Należy ograniczyć strefy źródłowe do stref wewnętrznych.
• Any dla źródła i miejsca docelowego: Reguła jest trudna do kontrolowania. Należy zdefiniować konkretnie sieci źródłowe i serwery docelowe.
• Reguła NAT istnieje, ale brakuje reguły zapory: Ruch jest tłumaczony, ale nie jest dozwolony. Należy sprawdzić Log Viewer pod kątem Rule ID i NAT ID.
• Reguła zapory sieciowej bez logowania: Analiza błędów staje się niepotrzebnie trudna. Należy włączyć Log firewall traffic przynajmniej podczas testu.
• Nie rozwiązano nazwy FQDN celu: cel DNAT jest nieosiągalny. Należy sprawdzić rozwiązywanie nazw DNS na zaporze.
• Klient korzysta z innego serwera NTP: Reguła nigdy nie jest dopasowywana. Należy sprawdzić konfigurację klienta lub opcję DHCP.
• Serwer czasu nie odpowiada: Klient pozostaje niezsynchronizowany. Należy sprawdzić serwer docelowy, routing i UDP 123.

Wycofanie zmian

Jeśli przekaźnik powoduje problemy, najpierw należy wyłączyć nową regułę DNAT klientów i uruchomić nowy test NTP, a następnie wyłączyć powiązaną regułę firewall. W wariancie B należy usunąć reguły SNAT i firewall do WAN serwera wewnętrznego tylko wtedy, gdy nie są już potrzebne do jego własnej synchronizacji. Reguły i obiekty hostów utworzone wyłącznie dla tego przekaźnika należy usuwać dopiero po potwierdzeniu, że nie ma już trafień ani zależności. Następnie należy skonfigurować klientom bezpośrednio osiągalny serwer NTP, na przykład przez opcję DHCP 42; w przeciwnym razie utracą źródło czasu.

Często zadawane pytania