Sophos Firewall jako relay NTP przez NAT

W wielu sieciach klienci, serwery, przełączniki, punkty dostępowe lub urządzenia specjalne powinny po prostu używać Gateway-IP jako serwera czasu. Jednak w tym scenariuszu nie ma kompletnego wewnętrznego serwera NTP działającego na Sophos Firewall, który sam zapewnia czas klientom.

Praktycznym obejściem jest relay NTP przez NAT. Urządzenia wysyłają NTP na adres IP firewalla, a Sophos Firewall przekazuje te żądania do rzeczywistego zewnętrznego lub wewnętrznego serwera czasu. Firewall nie staje się przez to właściwym źródłem czasu; tłumaczy i zezwala na odpowiedni ruch.

Jest to szczególnie przydatne, jeśli urządzenia są na stałe skonfigurowane pod kątem Gateway-IP, jeśli poprzednie środowisko UTM zostało zastąpione lub jeśli chcesz centralnie kontrolować cele 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 Sophos Firewall Konfigurowanie opcji DHCP.

⚠️ 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ą zaporę IP jako serwer NTP, zapora przekazuje dalej do zewnętrznego serwera NTP.
• Wariant B: Urządzenia wewnętrzne wykorzystują zaporę IP jako serwer NTP, zapora przekazuje dalej do wewnętrznego serwera NTP. Ponadto wewnętrzny serwer NTP musi mieć możliwość synchronizacji zewnętrznej.

Dlatego drugi wariant wymaga dwóch reguł NAT i dwóch reguł zapory sieciowej. Tego właśnie brakuje w wielu krótkich notatkach na ten temat.

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 Gateway-IP?
• 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? Prawidłowy czas jest ważny dla funkcji krytycznych czasowo, takich jak uwierzytelnianie MFA, WAF, certyfikaty, logi, korelacja VPN i SIEM. Jeżeli sama zapora sieciowa ma nieprawidłowy czas, przed przekierowaniem Client-NTP należy najpierw sprawdzić czas systemowy.

Kroki w tym artykule opierają się na Sophos Firewall 22.0. Ścieżki menu i nazwy pól mogą się nieznacznie różnić w starszych lub nowszych wersjach SFOS. Konfiguracja należy do interfejsu WebAdmin Sophos Firewall albo do starannie sprawdzonej automatyzacji API/CLI. W Sophos Central ten zestaw reguł NAT i firewall zwykle nie jest utrzymywany jako osobna konfiguracja NTP relay.

Przykłady są celowo opisane jako konfiguracja IPv4, ponieważ Sophos w oficjalnej instrukcji również pokazuje tworzenie hosta z 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.

Quick Reference

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. Krytyczne jest pole Original destination: powinno wskazywać adres IP firewalla lub bramy.

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.

Wariant A: Użyj zewnętrznego serwera NTP

Ten wariant jest odpowiedni, jeśli klienci mają używać zapory ogniowej IP 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 1.sophos.pool.ntp.org, time.google.com lub celowo wybrany serwer czasu dostawcy.

Utwórz hosta FQDN dla zewnętrznego serwera NTP

Ścieżka menu to:

Hosts and services > FQDN host

Procedura:

1. Wybierz Add.
2. Przypisz Nazwa, na przykład NTP_1_sophos_pool.
3. Wpisz zewnętrzny serwer NTP w polu FQDN, na przykład 1.sophos.pool.ntp.org.
4. Zapisz.

Jeśli zamiast nazwy FQDN używany jest wewnętrzny lub zewnętrzny serwer czasu ze stałym numerem 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.

Utwórz regułę NAT dla zewnętrznego serwera NTP

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

Rules and policies > NAT rules

Procedura:

1. Wybierz Add NAT rule > New NAT rule.
2. Ustaw Rule name, na przykład DNAT_Client_NTP_to_External.
3. Ustaw Rule position na Top lub umieść ponad ogólnymi regułami NAT.
4. Ustaw Original source na odpowiednią sieć wewnętrzną, na przykład LAN_NET lub IOT_NET.
5. Ustaw Original destination na zaporę sieciową lub Gateway-IP, którego klienci używają jako serwera NTP.
6. W przypadku Original service usuń Any i wybierz NTP.
7. Dla Translated source (SNAT) wybierz MASQ.
8. W przypadku Translated destination (DNAT) wybierz hosta FQDN lub hosta zewnętrznego serwera NTP.
9. W przypadku Inbound interface wybierz interfejs wewnętrzny lub interfejsy wewnętrzne, których to dotyczy.
10. Zapisz.

    

⚠️ 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. Dla kontrolowanego relay 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: Pierwotnym miejscem docelowym musi naprawdę być zapora ogniowa lub Gateway-IP, 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 wersji zapory ogniowej.

Zezwól na regułę zapory sieciowej dla zewnętrznego NTP

Zgodnie z regułą NAT wymagana jest odpowiednia reguła firewalla. Umożliwia to ruch NTP z sieci wewnętrznych do serwera docelowego. Ścieżka menu to:

Rules and policies > Firewall rules

Procedura:

1. Wybierz Add firewall rule > New firewall rule.
2. Ustaw Rule name, na przykład LAN_to_External_NTP.
3. Ustaw Rule position na Top albo umieść regułę nad ogólnymi regułami LAN-to-WAN, jeśli inaczej pasowałyby wcześniej.
4. Aktywuj Log firewall traffic.
5. Ustaw Source zones na strefy wewnętrzne, na przykład LAN, DMZ lub strefę IoT. WAN i Any są niepoprawne dla tego wzorca.
6. Ustaw Source networks and devices dla odpowiednich sieci lub urządzeń. Nie jest to ogólny Any, jeśli tylko niektóre sieci powinny używać NTP.
7. Ustaw Destination zones na WAN.
8. Ustaw Services na NTP.
9. Ustaw Action na Accept.
10. Zapisz.

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 LAN_NET, IOT_NET albo mała grupa hostów, aby później było jasne, które urządzenia mogą używać tego przekazywania NTP.

Reguła jest ograniczona głównie przez Source Zone, Source Network, usługę, pozycję reguły i cel NAT. Jeżeli ma być zastosowany również Destination networks to należy wówczas sprawdzić efekt w Log Viewer, ponieważ reguły DNAT mogą zmieniać widoczny adres docelowy w analizie.

Zalogowanie się do tej reguły jest pomocne przy wprowadzeniu. 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.

W przypadku struktury reguł, sekwencji, Services i rejestrowania pasuje również Zrozumienie i prawidłowe skonfigurowanie reguł Sophos Firewall.

Wariant B: Użyj wewnętrznego serwera 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 zapory ogniowej IP jako serwera NTP.

Potrzebne są tutaj dwie pary reguł:

Utwórz host dla wewnętrznego serwera NTP

Ścieżka menu to:

Hosts and services

Procedura:

1. Wybierz Add.
2. Ustaw Nazwa, na przykład NTP_Server_Internal.
3. Ustaw IP version na IPv4, jeśli używany jest IPv4.
4. Ustaw Type na IP.
5. Wpisz IP address wewnętrznego serwera NTP.
6. Zapisz.

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

Po pierwsze, wewnętrzny serwer NTP musi sam móc połączyć się z zewnętrznym serwerem czasu, jeśli nie jest on już zsynchronizowany gdzie indziej.

Reguła NAT:

1. Otwórz Rules and policies > NAT rules.
2. Wybierz Add NAT rule > New NAT rule.
3. Ustaw Rule name, na przykład SNAT_Internal_NTP_to_WAN.
4. Ustaw Rule position odpowiednio powyżej ogólnych zasad NAT.
5. Ustaw Original source na hosta NTP_Server_Internal.
6. W przypadku Original service usuń Any i wybierz NTP.
7. Dla Translated source (SNAT) wybierz MASQ.
8. Zapisz.

Reguła zapory sieciowej:

1. Otwórz Rules and policies > Firewall rules.
2. Wybierz Add firewall rule > New firewall rule.
3. Ustaw Rule name, na przykład Internal_NTP_to_WAN.
4. Aktywuj Log firewall traffic.
5. Ustaw Source zones na strefę wewnętrznego serwera NTP, np. LAN.
6. Ustaw Source networks and devices na NTP_Server_Internal.
7. Ustaw Destination zones na WAN.
8. Ustaw Services na NTP.
9. Zapisz.

Para reguł 2: Prowadź klientów do wewnętrznego serwera NTP przez zaporę ogniową-IP

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

Reguła NAT:

1. Otwórz Rules and policies > NAT rules.
2. Wybierz Add NAT rule > New NAT rule.
3. Ustaw Rule name, na przykład DNAT_Client_NTP_to_Internal.
4. Umieść Rule position nad ogólnymi zasadami NAT.
5. Ustaw Original source na wewnętrzne sieci klienckie, których dotyczy problem.
6. Ustaw Original destination na zaporze lub Gateway-IP, którego klienci używają jako miejsca docelowego NTP.
7. W przypadku Original service usuń Any i wybierz NTP.
8. Dla Translated source (SNAT) wybierz MASQ.
9. Dla Translated destination (DNAT) wybierz NTP_Server_Internal.
10. Zapisz.

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. Otwórz Rules and policies > Firewall rules.
2. Wybierz Add firewall rule > New firewall rule.
3. Ustaw Rule name, na przykład LAN_to_Internal_NTP.
4. Aktywuj Log firewall traffic.
5. Ustaw Source zones na wewnętrzne strefy klienckie. Unikaj WAN i Any.
6. Ustaw Source networks and devices dla odpowiednich sieci klienckich.
7. Ustaw Destination zones na strefę wewnętrznego serwera NTP, np. LAN lub DMZ.
8. Ustaw Services na NTP.
9. Zapisz. Jeśli ustawiono także Sieć docelową, należy w szczególności sprawdzić, czy reguła zapory nadal jest zgodna zgodnie z DNAT. W przypadku wstępnej akceptacji sieć źródłowa, strefa docelowa, usługa, reguła NAT i Log Viewer są zwykle wyraźniejszymi punktami kontrolnymi.

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

Klasyfikuj IPS i funkcje zabezpieczeń

NTP jest technicznie małą usługą UDP, ale UDP 123 staje się również przydatna w praktyce 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.
• W szczególności sieci źródłowe: ogranicza NTP do klientów, serwerów lub urządzeń, które naprawdę potrzebują tego przekazywania.
• Ustaw Destination Server: zapobiega zewnętrznym serwerom czasu i umożliwia ocenę logów.
• Tylko usługa NTP: pozwala uniknąć zbyt szerokiej reguły UDP.
• Aktywuj 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 czystej zasady. 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, niejasne urządzenia lub obszary IoT/OT, ukierunkowana polityka IPS staje się bardziej interesująca.

⚠️ 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 czyste 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 jej kopiować po wszystkich sieciach 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.

Do innych funkcji bezpieczeństwa należy celowo podchodzić ostrożnie z NTP. 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 NTP nie byłoby lepiej umieścić na własnej, małej regule.

Dystrybuuj NTP w czysty sposób za pomocą 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. NAT jest szczególnie przydatny, jeśli urządzenia już korzystają z Gateway-IP lub są trudne do rekonfiguracji. W przypadku specjalnych opcji DHCP lepszym początkiem będzie opcja Sophos Firewall Skonfiguruj opcje DHCP.

Sprawdź osobno czas systemu zapory ogniowej

Przekierowanie klienta NTP nie jest tym samym, co czas systemowy Sophos Firewall. Obydwa należy sprawdzić osobno:

• Czas systemu zapory ogniowej: dotyczy Log Viewer, certyfikatów, uwierzytelniania MFA, VPN, WAF, raportów, Syslog i analizy wsparcia.
• Klient-NTP poprzez NAT: Urządzenia w sieci wewnętrznej odbierają czas poprzez Gateway-IP 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 do zapory 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 jego własny czas lub strefa czasowa jest niepoprawna.

Do przesyłania dzienników odpowiednia jest opcja Wyślij Sophos Firewall Syslog do SIEM. W przypadku problemów z MFA należy również uwzględnić MFA dla Sophos Firewall WebAdmin, VPN Włącz portal i dostęp zdalny.

Przetestuj NTP i wyizoluj błędy

Po zapisaniu należy nie tylko sprawdzić, czy reguła istnieje. Kluczowe jest to, czy klient rzeczywiście może zsynchronizować NTP i czy spełniona jest oczekiwana reguła NAT i firewall.

Test rozpoczyna się tak samo dla obu wariantów: Klient z sieci, której dotyczy problem, używa zapory ogniowej lub Gateway-IP jako serwera NTP. Następnie uruchamiana jest synchronizacja czasu lub następuje krótkie oczekiwanie, aż klient wyśle ​​NTP.

W Log Viewer filtrujesz według usługi NTP lub UDP 123.

W wariancie A powinno być widoczne:

• Klient pochodzi z oczekiwanej sieci wewnętrznej.
• Reguła zapory ogniowej NTP dla zewnętrznych trafień 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.
• Klienci są kierowani poprzez DNAT z firewalla-IP do wewnętrznego serwera NTP. Jeśli Log Viewer nie wskazuje wyraźnie, która reguła ma zastosowanie, pomocne będzie Diagnostics > Przechwytywanie pakietów. Tam należy sprawdzić, czy pakiety od klienta do UDP 123 docierają do firewalla i czy następnie pakiety są dalej kierowane do oczekiwanego zewnętrznego lub wewnętrznego serwera czasu.

Jeśli nie są widoczne żadne dzienniki, żądanie w ogóle nie może zostać wysłane do klienta, 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 NTP specyficznych dla zapory ogniowej istotny jest również dziennik klienta NTP. Przegląd dzienników znajduje się w Sophos Firewall Troubleshooting: Services and Logs.

Krótka akceptacja

Przed zakończeniem produktywnym pięć punktów powinno być poprawnych:

1. Klienci naprawdę używają zapory ogniowej lub Gateway-IP 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 systemu firewall jest prawidłowy osobno.
5. Po zmianie protokołu DHCP, VLAN, NAT lub reguł, NTP zostanie ponownie przetestowany.

Typowe błędy

• WAN dozwolony jako Source Zone: Zapora sieciowa może w niezamierzony sposób działać jak otwarty przekaźnik NTP. Ogranicz strefy źródłowe do stref wewnętrznych.
• Any dla źródła i miejsca docelowego: Reguła jest trudna do kontrolowania. Zdefiniuj konkretnie sieci źródłowe i serwery docelowe.
• Reguła NAT występuje, ale nie ma reguły zapory sieciowej: Ruch jest tłumaczony, ale nie jest dozwolony. Sprawdź Log Viewer pod kątem identyfikatora reguły i identyfikatora NAT.
• Reguła zapory sieciowej bez logowania: Analiza błędów staje się niepotrzebnie trudna. Aktywuj Log firewall traffic przynajmniej podczas testu.
• Cel FQDN nie został rozwiązany: Cel DNAT nie został osiągnięty. Sprawdź rozdzielczość DNS zapory sieciowej.
• Klient korzysta z innego serwera NTP: Reguła nigdy nie jest spełniona. Sprawdź konfigurację klienta lub opcję DHCP.
• Serwer czasu nie odpowiada: Klient pozostaje niezsynchronizowany. Sprawdź serwer docelowy, routing i UDP 123.

Często zadawane pytania