Publikowanie serwera przez DNAT na Sophos Firewall

Za pomocą DNAT można opublikować serwer wewnętrzny przez publiczny adres IP lub port. Sophos Firewall przekazuje następnie ruch przychodzący do wewnętrznego serwera docelowego. Typowe przykłady to serwery WWW, reverse proxy, bramy VPN i inne usługi w strefie DMZ.

Szerszy kontekst hardening opisuje hub Sophos Firewall Hardening: best practices dla bezpiecznej konfiguracji.

Artykuł wyjaśnia, co należy sprawdzić przed utworzeniem reguły DNAT i po nim oraz jak możliwie ściśle zabezpieczyć publikację.

Planowanie przed publikacją

Przed opublikowaniem usługi przez DNAT należy ustalić, czy dostęp publiczny jest naprawdę potrzebny i który wariant techniczny pasuje najlepiej. Dobre planowanie zapobiega niepotrzebnie otwartym portom, duplikatom reguł NAT i trudnym do prześledzenia ścieżkom powrotnym.

Wymagania wstępne

• Publiczny adres IP lub interfejs WAN
• Serwer wewnętrzny ze stałym adresem IP
• Znana usługa i port, na przykład TCP 443
• Pasująca reguła zapory sieciowej
• Opcjonalnie: IPS, ochrona serwera WWW lub odwrotne proxy w zależności od usługi

⚠️ DNAT publikuje usługę wewnętrzną dla świata zewnętrznego. Każda opublikowana usługa zwiększa powierzchnię ataku. Publikowane powinno być tylko to, co jest naprawdę konieczne. Źródło, port i miejsce docelowe powinny być jak najwęższe.

Wyjaśnij wcześniej

Przed utworzeniem reguły należy odpowiedzieć na następujące pytania:

• Który publiczny adres IP lub interfejs WAN jest używany?
• Który zewnętrzny port ma być osiągalny?
• Na który wewnętrzny adres IP ma być przekierowany ruch?
• Czy port pozostaje taki sam, czy został przetłumaczony?
• Czy dostęp powinien być dozwolony zewsząd, czy tylko z określonych sieci źródłowych?
• Czy trzeba uwzględnić Source NAT lub Reflexive NAT?
• Czy istnieje potrzeba stosowania reguły pętli zwrotnej dla klientów wewnętrznych korzystających z publicznego FQDN?
• Czy zostanie opublikowany tylko jeden serwer wewnętrzny, czy wiele serwerów z równoważeniem obciążenia?
• Czy istnieje już reguła korzystająca z tego samego portu?
• Czy Sophos Firewall znajduje się bezpośrednio w Internecie, czy za routerem dostawcy?
• Czy w grupie zabezpieczeń Cloud należy otworzyć dodatkowe reguły?

Ta informacja zapobiega późniejszym konfliktom z istniejącymi NAT lub regułami zapory.

Jeśli terminy Original source, Original destination, Translated destination, Translated service, pętla zwrotna lub reguła zwrotna są w dalszym ciągu niejasne, powinieneś najpierw przeczytać Zrozumienie NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT. Ta strona skupia się na konkretnej publikacji usługi wewnętrznej.

DNAT, WAF, VPN czy ZTNA?

Nie każda publicznie dostępna usługa powinna być automatycznie publikowana za pośrednictwem DNAT. DNAT jest technicznie proste, ale także bardzo bezpośrednie: zapora ogniowa przekazuje port do wewnętrznego miejsca docelowego. To, czy ma to sens, zależy od usługi, źródeł i potrzeby ochrony.

• Usługa inna niż HTTP z jasno określonymi źródłami: DNAT ze ścisłym ograniczeniem źródeł, rejestrowaniem zdarzeń i IPS może być odpowiednie.
• Aplikacja HTTP lub HTTPS: Najpierw sprawdź Sophos Firewall WAF.
• Dostęp administracyjny, taki jak SSH lub RDP: dla pojedynczych stałych celów użyć Clientless SSL VPN, w pozostałych przypadkach VPN, ZTNA lub stałego źródłowego adresu IP zamiast otwartego DNAT.
• Dostęp tylko dla kilku partnerów lub lokalizacji: Preferuj źródłowy adres IP, VPN lub połączenie typu site-to-site.
• Aplikacja powinna być dostępna wewnętrznie i zewnętrznie pod tą samą nazwą: Sprawdź podział DNS lub celowo zaplanowaną regułę pętli zwrotnej.

W przypadku klasycznych aplikacji internetowych WAF jest często lepszym punktem wyjścia, ponieważ można uwzględnić nazwy hostów, certyfikaty, ścieżki, profile ochrony sieci i opcjonalnie uwierzytelnianie. W przypadku dostępu administracyjnego DNAT należy używać tylko w wyjątkowych przypadkach. Jeśli usługa wewnętrzna tak naprawdę nie musi być publiczna, VPN lub architektura ZTNA są zwykle czystszym rozwiązaniem. Istniejące podstawy ZTNA są dostępne w Jak skonfigurować Sophos ZTNA i Utwórz bramkę Sophos ZTNA.

Jeśli zapora sieciowa znajduje się za routerem

DNAT działa również, jeśli Sophos Firewall nie ma bezpośrednio publicznego adresu IP, ale znajduje się za routerem NAT od dostawcy.

W tym przypadku potrzebne są dwa przekierowania:

1. Na routerze dostawcy port publiczny jest przekazywany do adresu IP WAN Sophos Firewall.
2. W Sophos Firewall port jest przekazywany do serwera wewnętrznego poprzez DNAT.

Wielu dostawców routerów oferuje klasyczne przekierowanie portów lub funkcję taką jak Exposed Host lub DMZ Host. W przypadku funkcji Exposed Host wiele lub wszystkie porty przychodzące są często przekazywane do zapory ogniowej. Może to być praktyczne, ale powinno być celowo zabezpieczone, ponieważ faktyczna kontrola leży wtedy całkowicie w rękach Sophos Firewall.

Jeśli nie ma stałego publicznego adresu IP, można skonfigurować Dynamic DNS na Sophos Firewall, aby nazwa DNS zawsze wskazywała aktualny publiczny adres IP. Przekierowanie portów na routerze dostawcy nadal musi prowadzić do Sophos Firewall.

W przypadku dodatkowego publicznego adresu IPv4 w bezpośrednio podłączonym segmencie WAN może nadal brakować wcześniejszego rozpoznania ARP. Osobna procedura konfiguracji Proxy ARP na Sophos Firewall ma zastosowanie dopiero wtedy, gdy przechwytywanie potwierdzi zapytanie i brak odpowiedzi zapory; DNAT nie wymaga tego ręcznego kroku w każdym przypadku.

Ta sama zasada ma zastosowanie w środowiskach chmurowych. W przypadku platformy Azure sama reguła DNAT dotycząca Sophos Firewall nie wystarczy. Dodatkowo w Network Security Group należy otworzyć odpowiednie Inbound rules, w przeciwnym razie ruch w ogóle nie dotrze do firewalla.

Konfiguracja DNAT i reguły zapory

Publikacja serwera zawsze składa się z dwóch części: reguła NAT tłumaczy miejsce docelowe lub port, reguła zapory sieciowej zezwala na ruch i kontroluje go.

Asystent dostępu do serwera czy ręczna reguła DNAT?

Sophos Firewall oferuje dwa sposoby publikowania serwerów:

• Server access assistant (DNAT): sprawdza się jako szybki wariant standardowy dla pojedynczej publikacji. Kreator automatycznie tworzy kilka reguł i umieszcza je na górze bazy reguł.
• Ręczna reguła DNAT: pasuje do bardziej złożonych środowisk z aliasami IP, PAT, Load Balancing, specjalnymi źródłami lub świadomie zaprojektowanymi regułami. Każde pole trzeba ustawić i przetestować samodzielnie.

Kreator może być pomocny, ponieważ nie tylko tworzy przychodzącą regułę DNAT, ale w zależności od wyboru tworzy także regułę pętli zwrotnej, regułę zwrotną SNAT i odpowiednią regułę zapory ogniowej. Oszczędza to czas, ale nie zastępuje sprawdzania utworzonych reguł.

⚠️ Dla tego samego wpisu hosta DNS nie można jednocześnie skonfigurować DNAT i Weighted Load Balancing. Jeśli ten host DNS jest już używany do rozkładu ważonego, oba wymagania trzeba zaplanować oddzielnie przed publikacją; kreator nie łączy obu funkcji w jednej regule.

Użyj Asystenta dostępu do serwera

Kreator to najszybszy sposób na pierwszą publikację. Jest to szczególnie przydatne, gdy pojedynczy serwer wewnętrzny musi być dostępny poprzez adres WAN i przejrzystą usługę.

Potrzebne niestandardowe obiekty usług należy utworzyć przed rozpoczęciem. Wybór Services nie konfiguruje translacji portów: Translated source (SNAT) i Translated service (PAT) w wygenerowanej regule DNAT początkowo pozostają ustawione na Original. Aby skonfigurować PAT, po zapisaniu należy edytować wygenerowaną regułę NAT i sprawdzić pola PAT oraz pasującą regułę zapory. Po edycji jej usługi i pozostałe kryteria dopasowania muszą ponownie odpowiadać regule NAT. Wpisanie publicznego adresu IP w WAN IP address ustawia Inbound interface wygenerowanej reguły DNAT na Any; nie jest to równoznaczne ze świadomym wyborem interfejsu WAN. Nie należy rozszerzać źródeł zewnętrznych do Any tylko po to, aby uzyskać automatyczną regułę pętli zwrotnej.

Gdy Original destination jest adresem IP aliasu, asystent ustawia bazowy interfejs fizyczny jako Translated source w wygenerowanych regułach SNAT i loopback, a nie automatycznie adres aliasu. Jeżeli ten adres aliasu ma być przetłumaczonym źródłem, utwórz dla niego host IP i ręcznie wybierz go jako Translated source w odpowiednich wygenerowanych regułach. Nie jest to ogólny wymóg SNAT dla każdej publikacji; zachowaj ograniczenia źródeł przychodzących. Po zapisaniu sprawdź ID wygenerowanych reguł i rzeczywistą wartość Translated source, zweryfikuj oczekiwane adresy źródłowe w nowych sesjach na potrzebnych ścieżkach loopback i inicjowanych przez serwer oraz zachowaj spójność kryteriów zapory po zmianach.

Procedura:

1. Otwórz Rules and policies > NAT rules.
2. Wybierz IPv4 lub IPv6.
3. Wybierz Add NAT rule > Server access assistant (DNAT). Alternatywnie można uruchomić asystenta także przez Rules and policies > Firewall rules > Add firewall rule.
4. W obszarze Internal server IP address wybierz serwer wewnętrzny lub wprowadź adres IP.
5. W polu WAN IP address wybierz interfejs WAN albo publiczny adres IP.
6. Wybierz usługę wewnętrzną w Services, na przykład HTTPS.
7. Ustaw dozwolone źródła w External source networks and devices. W przypadku usług publicznych Any jest odpowiedni tylko wtedy, gdy usługa naprawdę musi być dostępna z całego Internetu.
8. ⚠️ Save and finish natychmiast aktywuje wygenerowane reguły i umieszcza je na górze obu tabel: NAT i zapory. Najpierw zakończ przygotowanie do uruchomienia: potwierdź publiczny cel, dozwolone źródła, usługi, konflikty i kolejność reguł oraz udokumentowany zakres wycofania zmian. Dopiero potem sprawdź ustawienia i reguły oraz zapisz za pomocą Save and finish.

Po tej wstępnej kontroli przeprowadź również przegląd po zapisaniu: zanotuj wygenerowane reguły i ich ID, sprawdź rzeczywistą kolejność w obu tabelach i w razie potrzeby świadomie zmień ich pozycje. Następnie zweryfikuj potrzebne ścieżki za pomocą nowych sesji. Automatycznie wygenerowana reguła może technicznie działać, a mimo to być zbyt szeroka, umieszczona zbyt wysoko lub mieć niewłaściwą nazwę do działania.

Aby reguła pętli zwrotnej została utworzona automatycznie, muszą być spełnione dwa warunki: jako cel WAN należy wybrać interfejs zapory, a External source networks and devices ustawić na Any. Kreator nie tworzy reguły pętli zwrotnej po wpisaniu publicznego adresu IP ani po ograniczeniu źródeł zewnętrznych. W wielu środowiskach Split DNS jest i tak czytelniejszy niż Loopback NAT.

Po użyciu asystenta należy zawsze sprawdzić:

• Czy NAT i reguła zapory sieciowej znajdują się we właściwej pozycji?
• Czy źródło jest naprawdę tak ciasne, jak planowano, czy nadal znajduje się na poziomie Any?
• Czy utworzono regułę pętli zwrotnej, mimo że podział DNS byłby czystszym rozwiązaniem?
• Czy utworzono regułę refleksyjną, która nie jest potrzebna dla wychodzącego ruchu serwerowego?
• Czy reguła zapory sieciowej pasuje do strefy docelowej po NAT i publicznego obiektu docelowego przed NAT?

W środowiskach produkcyjnych ręcznie nazwana i celowo umieszczona reguła DNAT jest często łatwiejsza do zrozumienia. Kreator jest dobry do szybkiego startu, ale utworzone reguły podlegają tej samej recenzji, co reguły utworzone ręcznie.

Tworzenie reguły DNAT

Typowy ręczny przykład DNAT publikuje zewnętrzny port TCP 443 na wewnętrznym serwerze WWW w strefie DMZ. Reguła tłumaczy wyłącznie adres docelowy i opcjonalnie port docelowy. Nie zastępuje reguły zapory.

Procedura:

1. Otwórz Rules and policies > NAT rules.
2. Wybierz IPv4 lub IPv6.
3. Wybierz Add NAT rule > New NAT rule.
4. Nadaj opisową nazwę w Rule name, na przykład DNAT_WEB_DMZ_HTTPS.
5. Wybierz Rule position, aby określone reguły DNAT poprzedzały reguły ogólne.
6. Ustaw Original source na dozwolone źródła zewnętrzne. Używaj Any wyłącznie w przypadku celowo usług publicznych.
7. Ustaw Original destination na obiekt hosta WAN, publiczny adres IP lub odpowiedni interfejs WAN.
8. Ustaw Original service na usługę dostępną zewnętrznie, na przykład HTTPS.
9. Ustaw Translated destination (DNAT) na serwer wewnętrzny lub grupę serwerów.
10. Pozostaw Translated service (PAT) na Original lub ustaw wewnętrzny port docelowy, jeśli konieczne jest przekierowanie portów.
11. Ustaw świadomie Inbound interface. W przypadku dostępu z Internetu jest to zazwyczaj interfejs WAN; W szczególnych przypadkach może być konieczne Any.
12. Outbound interface w DNAT na serwerach wewnętrznych powinien zwykle pozostać w Any, aby routing i strefa docelowa działały prawidłowo.
13. Aktywuj pętlę zwrotną, regułę refleksyjną, równoważenie obciążenia i kontrolę stanu tylko wtedy, gdy są one potrzebne ze względów technicznych.
14. Zapisz i aktywuj regułę.

Jeśli dostęp jest potrzebny tylko z kilku zewnętrznych adresów IP, Original source należy ograniczyć do tych źródeł zamiast używać Any.

W publikacjach produkcyjnych obiekt hosta dla publicznego adresu IP jest zwykle czytelniejszy niż bezpośredni wybór interfejsu WAN. Obiekt pozostaje jednoznaczny, gdy później zmienią się interfejsy, adresy aliasów lub dane dostawcy.

Poprawne rozumienie Original i Translated

W przypadku reguł NAT ważne jest rozróżnienie pomiędzy Original i Translated.

• Original source / destination / service opisuje ruch docierający do Sophos Firewall.
• Translated source / destination / service opisuje ruch opuszczający Sophos Firewall po tłumaczeniu.

Dla przychodzącej reguły DNAT oznacza to:

• Original destination to publiczny adres IP lub adres WAN zapory ogniowej.
• Original service to port zewnętrzny adresowany przez klienta.
• Translated destination (DNAT) to serwer wewnętrzny.
• Translated service (PAT) to wewnętrzny port na serwerze docelowym, jeśli port ma zostać przetłumaczony.
• Translated source (SNAT) przeważnie pozostaje przy Original z normalnymi regułami DNAT.

Przekierowanie portów i PAT

Przekierowanie portów jest technicznie tłumaczeniem usługi. W Sophos Firewall używana jest do tego Translated service (PAT).

Przykład:

• Zewnętrzny: TCP 20120
• Wewnętrzny: TCP 22

Klient zewnętrzny łączy się z portem 20120, ale Sophos Firewall przekazuje wewnętrznie do portu SSH 22. Może to być przydatne, ale nie zastępuje ograniczeń dostępu. Zmiana portu zewnętrznego może zmniejszyć część szumów tła, ale nie zapewnia bezpieczeństwa usługi.

Ważne: Protokół musi pozostać taki sam. TCP można przetłumaczyć na inny port TCP, UDP na inny port UDP. TCP na UDP nie jest prawidłową translacją portów.

Przy publikowaniu HTTPS należy najpierw w Administration > Admin and user settings ustalić faktycznie skonfigurowane porty WebAdmin, User Portal i VPN Portal. Starsze przykłady NAT podają 4444 dla WebAdmin i 443 dla User Portal; nie potwierdza to przypisania portów w zainstalowanym buildzie ani we własnej konfiguracji. W miarę możliwości rozwiązuj konflikty przez użycie innego publikowanego adresu IP lub innego zewnętrznego portu usługi. Nie zmieniaj portów zarządzania jako drogi na skróty w diagnostyce; jeśli zmiana jest konieczna, najpierw zapewnij niezależny dostęp do zarządzania, a następnie osobno sprawdź portale, klientów VPN i zewnętrzny dostęp przez DNAT.

Świadomie planuj źródłowy adres IP i ścieżkę zwrotną

W typowej publikacji DNAT Translated source (SNAT) powinno zazwyczaj pozostać ustawione na Original. Serwer wewnętrzny widzi wtedy rzeczywisty zewnętrzny adres źródłowy. Ma to znaczenie dla logów serwera, limitów szybkości, mechanizmów podobnych do Fail2Ban, logów aplikacji, analizy WAF lub reverse proxy oraz późniejszej analizy incydentu.

SNAT na zaporze lub adres wewnętrzny może być w dalszym ciągu konieczny, jeśli ścieżka powrotna nie przebiega przez Sophos Firewall. Jest to możliwe, jeśli na przykład opublikowany serwer korzysta z innej bramy domyślnej, znajduje się w obcym segmencie routingu lub ma asymetryczny routing.

Decyzję należy podjąć świadomie:

• Źródło pozostaje Original: Serwer widzi prawdziwy zewnętrzny adres IP. Aby to zrobić, ścieżka powrotna musi przebiegać bez zakłóceń przez zaporę.
• Źródło jest tłumaczone przez SNAT: Ścieżka powrotna jest łatwiejsza do kontrolowania. W tym celu serwer widzi tylko zaporę sieciową lub adres IP SNAT, a prawdziwy adres IP klienta zostaje utracony w dzienniku serwera.

Jeśli usługa działa tylko z SNAT, nie powinieneś się jej trzymać i zostawić temat za sobą. Lepiej najpierw sprawdzić, czy można poprawić bramę, trasę, VLAN, zaporę serwera lub projekt routingu. SNAT może być uzasadnionym obejściem problemu, ale utrudnia późniejszą analizę.

Podczas testowania należy zawsze sprawdzić, jaki źródłowy adres IP faktycznie widzi serwer. Jeśli zamiast adresu IP klienta zewnętrznego pojawia się tylko adres IP zapory sieciowej, należy wyraźnie udokumentować, czy jest to zamierzone.

Sprawdź regułę zapory

Sama reguła NAT nie zezwala automatycznie na ruch. Dodatkowo wymagana jest odpowiednia reguła zapory sieciowej.

W DNAT widok w regule zapory jest nietypowy, ponieważ zapora musi jednocześnie znać pierwotny dostęp z zewnątrz i przetłumaczony cel wewnętrzny.

Najważniejsza praktyczna zasada:

⚠️ W DNAT reguła zapory używa strefy docelowej po NAT, ale sieć docelowa przed NAT.

Proces jest ważny: Kiedy nadchodzi ruch, Sophos Firewall najpierw szuka odpowiedniej reguły DNAT i w ten sposób określa przetłumaczone miejsce docelowe. Następnie dopasowywana jest reguła zapory sieciowej. Dla Destination zone zapora wykorzystuje strefę, w której znajduje się przetłumaczony cel. Jednakże pierwotny obiekt docelowy z reguły DNAT pozostaje istotny dla Destination networks.

Typowe przypisanie:

• Source zones: Przeważnie WAN, gdy dostęp pochodzi z Internetu.
• Source networks and devices: W miarę możliwości ograniczone, na przykład pojedyncze adresy IP, sieci, kraje lub grupy.
• Destination zones: Strefa serwera wewnętrznego po DNAT, na przykład DMZ lub SERVER.
• Destination networks: Publiczny adres docelowy lub obiekt hosta WAN z Original destination.
• Services: Bez PAT wystarczy usługa z Original service. Przy translacji portu reguła zapory musi zawierać zarówno oryginalną usługę zewnętrzną, jak i usługę wewnętrzną z Translated service. Przykład TCP 20120 na TCP 22 wymaga więc obu obiektów usług.
• Profil bezpieczeństwa: W zależności od usługi IPS, skanowanie w poszukiwaniu złośliwego oprogramowania, Web Policy lub inna odpowiednia kontrola.
• Logowanie: Włącz dla opublikowanych usług.

Bez odpowiedniej reguły zapory sieciowej ruch jest przerywany pomimo DNAT.

Ten punkt jest częstym źródłem błędów: jeśli jako sieć docelową wpiszesz serwer wewnętrzny, nawet jeśli reguła oczekuje publicznego obiektu WAN, reguła nie będzie pasować. Dokładną logikę opisano bardziej szczegółowo w artykule NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Kolejność dotyczy również reguł NAT. Sophos sprawdza reguły NAT od góry do dołu i używa pierwszej pasującej reguły. Dlatego też powyższa zbyt ogólna reguła NAT może uniemożliwić zastosowanie konkretnej reguły DNAT.

Istniejące połączenia zachowują tłumaczenie NAT, nawet jeśli później zmienisz regułę NAT. Dlatego podczas testowania po zmianie powinieneś utworzyć nowe sesje lub całkowicie zakończyć stare połączenia, w przeciwnym razie możesz nadal oceniać stary stan.

Rozszerzone opcje NAT

Opcje te mają znaczenie tylko wtedy, gdy klienci wewnętrzni używają nazw publicznych, ścieżki powrotne wymagają specjalnego przetłumaczenia lub gdy zaangażowanych jest wiele serwerów docelowych.

Reguły pętli zwrotnej, zwrotne i połączone NAT

Sophos Firewall oferuje kilka opcji NAT, które można łatwo pomylić:

• Reguła pętli zwrotnej (Loopback rule): pomaga, gdy klienci wewnętrzni mają łączyć się z wewnętrznym serwerem przez publiczny adres IP lub publiczną nazwę DNS.
• Reguła refleksyjna (Reflexive rule): tworzy lustrzaną regułę SNAT dla nowych połączeń inicjowanych przez opublikowany serwer. Nie jest potrzebna dla stanowych pakietów odpowiedzi przychodzącej sesji DNAT.
• Połączona reguła NAT: Utworzona na podstawie reguły zapory sieciowej i jest powiązaną regułą SNAT. Połączona reguła NAT nie jest tym samym, co przychodząca reguła DNAT dla opublikowanego serwera.

Te reguły NAT również nie udzielają zezwolenia na dostęp. Dla potrzebnego dostępu przez pętlę zwrotną należy sprawdzić istniejącą, odpowiednio ograniczoną regułę w Rules and policies > Firewall rules albo w razie potrzeby utworzyć pasującą regułę:

• Source zones: Rzeczywista strefa klienta, na przykład LAN.
• Source networks and devices: Tylko potrzebna wewnętrzna podsieć klientów.
• Destination zones: Strefa przetłumaczonego serwera, na przykład DMZ.
• Destination networks: Pierwotny publiczny cel z Original destination, a nie wewnętrzny adres IP serwera.
• Services: Przy PAT oba obiekty usług z Original service i Translated service (PAT); w istniejącym przykładzie TCP 20120 i TCP 22.

Dla połączeń niezależnie inicjowanych przez serwer reguła zapory musi zezwalać na jego rzeczywistą strefę w Source zones oraz wewnętrzny adres IP lub listę adresów IP serwerów w Source networks and devices. Destination zones, Destination networks i Services należy ograniczyć do potrzebnych celów i usług zamiast bezwarunkowo kopiować Any. Może wystarczyć istniejąca, odpowiednio ograniczona reguła; nowa reguła nie zawsze jest potrzebna. Stanowe odpowiedzi na przychodzące sesje DNAT nie wymagają ani refleksyjnej reguły NAT, ani nowego zezwolenia na ruch wychodzący. Kolejność NAT i trasę powrotną należy sprawdzić oddzielnie, włączyć logowanie i przetestować potrzebne ścieżki wewnętrzne oraz inicjowane przez serwer osobno, używając nowych sesji.

W przypadku klasycznych publikacji serwerowych niezależna reguła DNAT plus odpowiednia reguła zapory sieciowej jest zwykle najjaśniejsza. Połączone reguły NAT mogą być przydatne, jeśli reguła zapory wymaga bezpośrednio specjalnego tłumaczenia SNAT. Jednak w środowiskach ogólnych samodzielne reguły o wyraźnie nazwanych NAT są zwykle łatwiejsze do zrozumienia i utrzymania.

Ważne: reguły loopback (pętli zwrotnej) i reflexive (refleksyjne) wywodzą się z pierwotnej reguły DNAT. Jeżeli pierwotna reguła DNAT zostanie później zmieniona, należy osobno sprawdzić reguły pochodne. W przeciwnym razie może się zdarzyć, że dostęp zewnętrzny został poprawnie dostosowany, ale dostęp do wewnętrznej pętli zwrotnej lub ruch wychodzący z serwera nadal będzie przebiegał zgodnie ze starą logiką.

To nie jest kosmetyczny szczegół. Sophos tworzy reguły loopback (pętli zwrotnej) i reflexive (refleksyjne) w oparciu o nazwę i identyfikator pierwotnej reguły DNAT, ale późniejsze zmiany tej reguły nie powodują automatycznej aktualizacji reguł pochodnych. Po zmianach w publicznym adresie IP, serwerze docelowym, usłudze lub źródłach należy zatem świadomie otworzyć i porównać te reguły.

Równoważenie obciążenia i Health Check

Kiedy wiele serwerów wewnętrznych jest opublikowanych za publicznym adresem IP, DNAT może być również użyte do równoważenia obciążenia lub przełączania awaryjnego.

Możliwe metody obejmują:

• Round-robin
• First alive
• Random
• Sticky IP
• One-to-one

Jeśli chcesz, aby zapora sieciowa wykrywała, czy serwer docelowy jest dostępny, należy skonfigurować Health check. Bez Health Check zapora sieciowa może również przekazywać ruch do serwera, do którego nie można się dostać.

Wdrażanie publikacji DNAT przez XML API

XML API może utworzyć lub zmienić planowaną publikację za pomocą NATRule. Nie zastępuje ani osobnego zezwolenia w zaporze, ani weryfikacji przepływu danych. Pełny model NAT i ogólną strukturę obiektów opisuje artykuł Zrozumienie NAT na Sophos Firewall; tutaj omawiamy bezpieczne wprowadzenie zmiany dla opublikowanego serwera. Najpierw przygotuj dostęp, weryfikację TLS, konto usługowe, sekrety i jawne operacje zapisu zgodnie z artykułem Zabezpieczanie dostępu do XML API.

Przeniesienie planowanego przepływu danych do żądania

W istniejącym przykładzie HTTPS OriginalSourceNetworks wraz z wpisami Network opisuje dozwolone źródła zewnętrzne, OriginalDestinationNetworks — publiczny cel, a OriginalServices wraz z Service — usługę zewnętrzną. TranslatedDestination wskazuje serwer wewnętrzny; bez PAT TranslatedService pozostaje ustawione na Original, a w przeciwnym razie określa usługę wewnętrzną. W zwykłym DNAT, bez świadomie zaplanowanego SNAT, TranslatedSource również pozostaje ustawione na Original. Pola Original ograniczają przepływ przychodzący, a pola Translated określają jego translację. Najpierw odczytaj istniejące obiekty hostów i usług wraz z rodziną adresów i porównaj je z planowaną zmianą; nie zakładaj, że przykładowe nazwy odpowiadają rzeczywistym obiektom. Reguła zapory nadal musi obejmować strefę docelową po NAT, publiczny cel przed NAT, a przy PAT — obie usługi.

InboundInterfaces i OutboundInterfaces zawierają wpisy Interface i ograniczają dopasowanie. Nie służą do translacji źródła specyficznej dla interfejsu: tylko gdy jest ona rzeczywiście potrzebna, używa się OverrideInterfaceNATPolicy z Enable i powiązaną listą InterfaceNATPolicyList. Jej wpisy Override przypisują specific_interface do specific_translatedsourceid. Nie włączaj tego szczególnego wariantu na zapas przy zwykłej publikacji serwera. Komentarz w udokumentowanym przykładzie podaje inną nazwę, OverrideInterfaceDefaultNATPolicy, podczas gdy element XML nazywa się OverrideInterfaceNATPolicy. Nie wyciągaj z tego wniosku, że istnieje drugi przełącznik lub prawidłowy alternatywny znacznik; jeśli składnia Override pozostaje niewyjaśniona, wstrzymaj żądanie i skorzystaj z API help zainstalowanego buildu lub pomocy technicznej.

Pozycja wstawienia wymaga osobnej decyzji: Position oferuje top, bottom, after i before. Przy after nazwa istniejącej reguły odniesienia znajduje się w After > Name, a przy before — w Before > Name; w przykładzie te elementy odniesienia są przewidziane dla żądań Set. Nie ustawiaj obu kierunków jednocześnie i nie myl nazwy reguły odniesienia z nazwą własnej reguły NATRule. Przed zapisem odczytaj regułę odniesienia i sprawdź konflikty powyżej niej; po zapisie skontroluj rzeczywistą pozycję. Kolejność NAT i kolejność reguł zapory pozostają w dwóch oddzielnych tabelach. W przykładzie LinkedFirewallrule jest przewidziane wyłącznie do tworzenia Linked NAT w żądaniu Set, a nie jako automatyczne zezwolenie zapory dla przychodzącej reguły DNAT.

Opcjonalny rozkład ruchu nie jest obowiązkowy

Przy prostej publikacji na jednym serwerze równoważenie obciążenia i kontrola stanu nie są obowiązkowe. Zgodnie z opisem obiektu HealthCheck ma zastosowanie tylko przy włączonym rozkładzie ruchu. Parametry kontroli w LoadBalance dotyczą włączonej kontroli stanu: ProbeMethod to ICMP lub TCP; Port jest wymagany tylko dla TCP i mieści się w zakresie od 1 do 65535. Tabela parametrów podaje dla ProbeInterval zakres od 5 do 65535 sekund i wartość domyślną 60, dla ResponseTimeOut — od 1 do 10 sekund i wartość domyślną 2, a dla DeactivateHostAfter — od 1 do 10 prób i wartość domyślną 3. Oznaczenia Mandatory przy parametrach kontroli w tej tabeli nie oznaczają obowiązku ich podawania w każdym żądaniu NAT. Potwierdź odpowiednią metodę, włączoną kontrolę i prawidłowe wartości w API help używanego buildu; nie dołączaj w pełni wypełnionego szablonu równoważenia obciążenia do każdej zmiany DNAT. Ponadto powodzenie kontroli ICMP nie potwierdza działania usługi aplikacyjnej.

Zapis, odczyt stanu i weryfikacja publikacji

1. Udokumentuj planowany przepływ, dozwolone źródła, usługę publiczną i wewnętrzną, identyfikatory NAT i reguł zapory oraz ich pozycje. Zabezpiecz istniejący stan i sprawdź zależności, w tym osobno utworzone reguły loopback i refleksyjne. Również w automatyzacji stosuj istniejącą procedurę uruchomienia i wycofania zmian.
2. Wykonaj bezpieczne zapytanie odczytu z hosta przewidzianego do automatyzacji. Następnie użyj wyłącznie jawnej operacji Set potwierdzonej dla NATRule i zainstalowanego buildu. Nie zakładaj ani działania przy pominiętej wartości operacji, ani ogólnego zachowania typu upsert; jeśli konkretny payload pozostaje niewyjaśniony, nie wykonuj zapisu. Świadomie ustaw IPFamily i Status, zamiast przyjmować z wartości domyślnej nieoczekiwaną regułę IPv4 lub natychmiastową aktywację.
3. Zachowaj odpowiedź i status XML specyficzny dla obiektu, usuń z nich sekrety i ponownie odczytaj zapisaną regułę lub otwórz ją w Rules and policies > NAT rules. Porównaj wartości Original/Translated, interfejsy, status, ID i rzeczywistą pozycję z planem. Osobno skontroluj również oddzielną regułę zapory i potrzebne reguły pochodne; nie wnioskuj o ich utworzeniu lub aktualizacji wyłącznie na podstawie żądania NATRule.
4. Dopiero potem wykonaj zaplanowany krok aktywacji i za pomocą nowych sesji sprawdź dozwolone źródło zewnętrzne oraz kontrolowane niedozwolone źródło zewnętrzne, potrzebny dostęp wewnętrzny i potrzebne połączenia inicjowane przez serwer. Log Viewer, NAT Rule ID, Firewall Rule ID, zapis przechwyconych pakietów i log serwera muszą odpowiadać planowanemu przepływowi i oczekiwanemu źródłowemu adresowi IP. Zapisany obiekt lub status XML nie potwierdza jeszcze bezpiecznej, działającej publikacji.
5. W przypadku rozbieżności nie ponawiaj operacji w ciemno. Najpierw porównaj rzeczywisty stan z odpowiedzią; następnie wycofaj tylko nowe reguły używane wyłącznie przez tę zmianę lub przywróć zmienione reguły współdzielone do udokumentowanego stanu i ich poprzedniej pozycji. Osobno utworzone reguły obsługuj oddzielnie, nie wyłączaj bezwarunkowo współdzielonych zezwoleń i sprawdź ścieżkę powrotną za pomocą nowych sesji.

Interpretacja odpowiedzi NATRule z uwzględnieniem specyfiki obiektu

Dokumentacja SFOS 22 i 23 podaje następujące przypisania operacji, kodów i symboli. Message.* to nierozwinięte klucze komunikatów ze strony dokumentacji, a nie rozwinięte tutaj teksty odpowiedzi ani potwierdzone wyniki działania w środowisku wykonawczym. Nie traktuj kodów jako statusów HTTP i nie wyciągaj wyłącznie z nazwy symbolu wniosków o jednoznacznej przyczynie błędu, pomyślnym zapisie ani zasadach ponawiania operacji.

To, że 548 i 549 mają ten sam klucz, właśnie nie pozwala na jednoznaczne rozróżnienie na podstawie tej etykiety. Przypisań NATRule dla 503 i 504 również nie wolno zastępować ogólnymi objaśnieniami kodów API. W przypadku nieoczekiwanej odpowiedzi zachowaj pełną odpowiedź oczyszczoną z sekretów, operację, zainstalowany build i odczytany stan reguły; skorzystaj z sekcji Status Message Information właściwej dla tego obiektu, a w razie potrzeby z pomocy technicznej. Główny poradnik bezpieczeństwa API wyjaśnia postępowanie przy częściowym powodzeniu, ostrzeżeniach i kontrolnych odczytach przed ponowną próbą zapisu.

Zabezpieczanie i uruchamianie

Opublikowana usługa natychmiast staje się częścią publicznej powierzchni ataku. Dlatego też ściśle ograniczony dostęp, rejestrowanie, profile bezpieczeństwa i jasny plan wycofania zmian stanowią część uruchomienia.

Zaplanuj uruchomienie i wycofanie

Publikację DNAT należy traktować jako niewielką zmianę produkcyjną. Po aktywowaniu reguły usługa może stać się dostępna z Internetu. Przed uruchomieniem trzeba więc udokumentować, która reguła zostanie aktywowana, jak zostanie przetestowany dostęp i jak wykonać rollback w razie problemów.

Sprawdź przed uruchomieniem:

• Utwórz kopię zapasową bieżącej konfiguracji zapory lub przynajmniej udokumentuj reguły NAT i zapory objęte zmianą.
• Zapisać ID wszystkich reguł DNAT, pętli zwrotnej, refleksyjnych reguł NAT i reguł zapory należących do tej zmiany; dla zmienionych istniejących reguł zanotować wcześniejszy stan aktywacji i pozycję.
• Sprawdź istniejące reguły NAT dla tego samego publicznego adresu IP, portu zewnętrznego i interfejsu WAN.
• Dopasuj router dostawcy, grupę zabezpieczeń w chmurze lub reguły zapory nadrzędnej do konfiguracji Sophos.
• Weź pod uwagę DNS-TTL, gdy nazwa hosta wskazuje na opublikowany adres.
• Przygotuj źródło testowe poza własnym LAN, na przykład sieć komórkową, lokalizację zewnętrzną lub test kontrolowanego portu online.
• Ustaw oczekiwane lokalizacje dzienników: Log Viewer, NAT Rule ID, Firewall Rule ID, Packet Capture i dziennik serwera.
• Zdefiniuj kryteria wycofywania, na przykład dostępna niewłaściwa usługa, brak odpowiedzi serwera, błąd certyfikatu, profil zabezpieczeń blokuje prawidłowy ruch lub nieoczekiwany źródłowy adres IP na serwerze.

Podczas wycofywania należy najpierw sprawdzić, czy każda zapisana reguła jest współdzielona z innymi publikacjami. Wyłącza się tylko nowe reguły należące do tej zmiany, w tym osobno wygenerowane reguły pętli zwrotnej i refleksyjne reguły NAT. Zmienione istniejące reguły należy przywrócić do udokumentowanego stanu i poprzedniej pozycji zamiast bezwarunkowo wyłączać współdzieloną regułę zapory. Następnie sprawdza się potrzebne ścieżki zewnętrzne, wewnętrzne i inicjowane przez serwer za pomocą nowych sesji; wyłączenie reguł nie gwarantuje natychmiastowego zakończenia istniejących połączeń. Jeżeli stara publikacja została zastąpiona, powinno być jasne, czy można ponownie aktywować starą regułę, czy też należy najpierw zresetować przekierowanie portów dostawcy, DNS lub monitorowanie.

W przypadku usług krytycznych nie należy zmieniać kilku rzeczy jednocześnie. Jeśli DNS, router dostawcy, reguła NAT, reguła zapory sieciowej i konfiguracja serwera zostaną dostosowane w tym samym czasie, trudno będzie później przypisać błąd. Lepszy jest krótki proces z jasnymi krokami: przygotuj, aktywuj, przetestuj zewnętrznie, sprawdź logi, sprawdź serwery, udokumentuj wyniki.

Ogranicz dostęp tak ściśle, jak to możliwe

Nie każda opublikowana usługa musi być dostępna z całego Internetu. Jeśli to możliwe, dostęp powinien być ograniczony.

Przydatne ograniczenia:

• Zezwalaj tylko na pojedyncze źródłowe adresy IP.
• Zezwalaj na znane hosty FQDN tylko wtedy, gdy lokalizacja zdalna używa dynamicznych adresów IP.
• Zezwalaj tylko na niektóre kraje.
• Jawnie blokuj określone kraje.
• Zezwalaj na dostęp tylko przez VPN.
• Użyj rozwiązania ZTNA zamiast bezpośredniego publikowania.

W przypadku usług administracyjnych, takich jak SSH, RDP lub wewnętrzne portale administracyjne, DNAT zwykle nie jest najlepszym rozwiązaniem. Jeśli dostęp nie musi być publiczny, VPN lub ZTNA jest prawie zawsze lepszym wyborem.

Popraw bezpieczeństwo

W przypadku opublikowanych usług powinieneś sprawdzić:

• Czy serwer ma aktualne poprawki?
• Czy dostępna jest opcja WAF lub odwrotnego proxy?
• Czy IPS jest aktywne w regule zapory?
• Czy otwarte są tylko niezbędne porty?
• Czy dostęp do usługi jest rejestrowany w logach?
• Czy zastosowano ograniczenia Geo-IP, Threat Feeds lub źródłowych adresów IP?
• Czy MFA jest możliwe, jeśli jest to portal?

W przypadku aplikacji internetowych opcja Ochrona serwera WWW / WAF może również mieć sens zamiast czystego DNAT.

Boty i źródła zagrożeń

Porty publiczne, takie jak HTTP, HTTPS, SSH lub RDP są stale w centrum uwagi botów. Gdy tylko port stanie się dostępny w Internecie, często szybko zauważysz próby połączenia, skany, próby logowania lub ruch wykorzystujący luki w Log Viewer.

Nie oznacza to automatycznie, że serwer został naruszony. Pokazuje jednak, że usługa jest częścią publicznej powierzchni ataku. Dlatego zalecamy dodatkowe zabezpieczenie opublikowanych usług za pomocą IPS, rejestrowania, wąskich źródeł i źródeł zagrożeń stron trzecich.

Kanały zagrożeń stale dostarczają zaporze aktualne wskaźniki naruszenia, na przykład złośliwe adresy IP lub domeny. Dzięki temu zapora może blokować znanych napastników, botnety lub skanery, zanim dotrą one do opublikowanej usługi.

Więcej informacji: Sophos Firewall Kanały o zagrożeniach

Test

Po zapisaniu reguły DNAT:

• Test z sieci zewnętrznej, innej niż ta sama LAN
• Sprawdź tylko oczekiwany port publiczny, nie skanuj szeroko pod kątem obcych adresów
• Sprawdź Log Viewer pod kątem Firewall Rule ID, NAT Rule ID, źródła, oryginalnego miejsca docelowego, przetłumaczonego miejsca docelowego oraz statusu dozwolonego lub odrzuconego
• Porównaj Packet Capture ze źródłem zewnętrznym, miejscem docelowym publicznym i miejscem docelowym wewnętrznym
• Sprawdź dzienniki serwera
• Kontroluj widoczny źródłowy adres IP w systemie docelowym

Jeśli test ma zostać przeprowadzony z wewnętrznego LAN na publiczny adres IP, konieczne może być dodatkowo Hairpin NAT lub wewnętrzne rozwiązanie DNS.

Matryca testowa dla publikacji DNAT

Test pojedynczego portu rzadko wystarcza dla produkcyjnej publikacji DNAT. Lepsza jest mała matryca testowa oddzielająca dozwolone i niepożądane ścieżki. Pokazuje ona nie tylko, czy usługa jest dostępna, lecz także czy ograniczenia, logowanie i ścieżka powrotna działają poprawnie.

Przydatne źródła testów:

• Dozwolone zewnętrzne źródło: Sprawdź połączenie z telefonu komórkowego, lokalizacji zewnętrznej lub sieci partnerskiej pod kątem publicznego adresu IP i portu zewnętrznego. Oczekiwane Firewall Rule ID i NAT Rule ID muszą pojawić się w Log Viewer.
• Niedozwolone źródło zewnętrzne: Jeśli publikacja jest ograniczona do określonych źródeł, test z niedozwolonego źródła powinien celowo zakończyć się niepowodzeniem. W przeciwnym razie ograniczenie źródła jest zbyt szerokie.
• Klient wewnętrzny z wewnętrzną nazwą DNS: Sprawdź, czy dla użytkowników wewnętrznych nazwa jest rozwiązywana bezpośrednio na wewnętrzny adres IP serwera. Jest to często czystsze niż pętla zwrotna NAT.
• Klient wewnętrzny z publicznym FQDN: Testuj tylko wtedy, gdy ten dostęp jest naprawdę potrzebny. Jeśli się nie powiedzie, najpierw sprawdź podział DNS i nie dodawaj automatycznie pętli zwrotnej NAT.
• Sam serwer docelowy: Sprawdź dziennik serwera, lokalną zaporę ogniową, powiązaną usługę, certyfikat i widoczny źródłowy adres IP. W ten sposób możesz stwierdzić, czy serwer widzi prawdziwy zewnętrzny adres IP, czy adres SNAT.
• Monitorowanie lub zewnętrzne Health Check: Sprawdź, czy test wykorzystuje ten sam adres URL, port i logikę źródłową, co rzeczywisty monitoring.

Po każdym teście należy ocenić tylko jeden wynik: jeśli ruch dociera do Sophos Firewall, stosowana jest oczekiwana reguła NAT, stosowana jest oczekiwana reguła zapory sieciowej, pakiet dociera do serwera i zwracana jest odpowiedź. Jeśli jednocześnie zostanie zmienionych kilka rzeczy, w przeciwnym razie trudno będzie zidentyfikować następny błąd.

Czysty test DNAT porównuje trzy punkty widzenia:

• Klient zewnętrzny: Połączenie z publicznym adresem IP i portem zewnętrznym działa lub jest celowo zablokowane.
• Sophos Firewall: Log Viewer pokazuje oczekiwane Firewall Rule ID i NAT Rule ID.
• Serwer wewnętrzny: Usługa widzi oczekiwany źródłowy adres IP, odpowiada za pośrednictwem właściwej bramy i rejestruje dostęp.

Jeśli zostanie zaznaczony tylko jeden z tych widoków, typowe błędy pozostaną niewykryte. Na przykład pomyślny test portu zewnętrznego nie pozwala jeszcze stwierdzić, czy logowanie, IPS, ograniczenia źródła lub właściciele serwerów są prawidłowo udokumentowani.

Rozwiązywanie problemów i operacje

Po uruchomieniu powinieneś nie tylko sprawdzić, czy usługa jest dostępna. Ważne są Log Viewer, NAT Rule ID, Firewall Rule ID, logi serwera i regularne przeglądy starych publikacji usług.

Rozwiązywanie problemów

Typowe błędy:

• Brak reguły zapory sieciowej
• Wybrano nieprawidłowy adres IP WAN
• Na routerze dostawcy brakuje przekierowania portów
• Grupa zabezpieczeń Azure Network blokuje port
• Usługa nie działa wewnętrznie
• Brama serwera nie wskazuje Sophos Firewall
• Reguła NAT znajduje się pod inną regułą, która zaczyna obowiązywać wcześniej
• Reguła zapory sieciowej używa niewłaściwej sieci docelowej w DNAT
• Port jest już używany przez inną usługę
• Brak pętli zwrotnej, gdy klienci wewnętrzni korzystają z publicznego FQDN
• Brak Health Check lub jest on nieprawidłowy podczas korzystania z równoważenia obciążenia
• Test jest przeprowadzany z sieci wewnętrznej, a nie zewnętrznej
• Serwer docelowy odpowiada przez inną bramę
• Profil zabezpieczeń blokuje ruch, ale nie jest wyszukiwany w prawidłowym dzienniku

Log Viewer jest najważniejszym punktem wyjścia dla problemów DNAT. Można tam zobaczyć, czy ruch przychodzi, która reguła zapory sieciowej i która reguła NAT ma zastosowanie oraz czy ruch jest dozwolony, czy odrzucany. Jeśli dopasowanie nie spełnia oczekiwań, pomaga artykuł Reguła Sophos Firewall nie działa: sprawdź przyczyny.

Aby uzyskać głębsze informacje o rozwiązywaniu problemów, nie powinieneś tylko patrzeć na Sophos Firewall. Jeśli Log Viewer zezwala na ruch, a Packet Capture pokazuje, że pakiety nadal płyną do serwera, przyczyna często leży w systemie docelowym: lokalna zapora ogniowa, nieprawidłowa brama domyślna, brak powiązania z usługą, problem z certyfikatem, aplikacja nasłuchująca na innym porcie lub odwrotne proxy nadrzędne nie odpowiada zgodnie z oczekiwaniami.

Szybka klasyfikacja pomaga uniknąć szukania w niewłaściwym miejscu:

• W Log Viewer nie pojawia się żadne trafienie: Ruch nie dociera do zapory ogniowej lub adresowany jest niewłaściwy adres IP WAN. Sprawdź router dostawcy, grupę zabezpieczeń w chmurze, publiczny adres IP i Packet Capture dla WAN.
• Firewall Rule ID pasuje, ale brakuje NAT Rule ID: Reguła NAT nie pasuje lub jest za niska. Sprawdź Original destination, Original service, interfejs przychodzący i sekwencję NAT.
• NAT Rule ID pasuje, usługa nie odpowiada: Serwer docelowy lub ścieżka zwrotna jest nieprawidłowa. Sprawdź zaporę serwera, bramę domyślną, routing i Packet Capture w kierunku serwera.
• Działa zewnętrznie, ale nie wewnętrznie poprzez FQDN: Brakuje podziału DNS lub pętli zwrotnej. Sprawdź wewnętrzne rozwiązywanie nazw DNS i tylko świadomie dodawaj pętlę zwrotną.
• Po zmianie kreatora tylko część zachowuje się niepoprawnie: Wyprowadzona pętla zwrotna lub reguła zwrotna już nie pasują. Sprawdź indywidualnie wygenerowane NAT i reguły zapory sieciowej.

SMTP przez DNAT po aktualizacji do SFOS 22

Jeśli po aktualizacji do SFOS 22 przychodzące wiadomości e-mail są sporadycznie dostarczane z opóźnieniem albo nie są dostarczane wcale, możliwą przyczyną jest NC-184583. Sophos wskazuje SFOS 22.0 GA Respin Build 411 wprost jako wersję dotkniętą problemem, ale opisuje go szerzej w odniesieniu do aktualizacji do v22.x. MR1 i MR2 nie zostały osobno wymienione ani jako wersje dotknięte problemem, ani jako wersje zawierające poprawkę. Jako jedyną wersję z poprawką podano SFOS 23.0 EAP0 Build 275 — jest to wersja EAP, której nie można traktować jako ogólnej rekomendacji dla systemu produkcyjnego. Nie ma publicznie udokumentowanego workaroundu; Sophos odsyła do pomocy technicznej.

Niezależnie od tego informacje o wydaniu SFOS 22.0 MR3 Build 576 z 16 października 2026 r. wymieniają poprawiony błąd NC-180464: po aktualizacji ruch SMTP przez DNAT był błędnie odrzucany. Ten drugi identyfikator błędu nie dowodzi, że w MR3 naprawiono również NC-184583. Przy pasujących objawach należy omówić z Sophos Support oba identyfikatory, zainstalowany build i dotychczasowe obserwacje, zanim uzna się, że poprawka rozwiązuje problem we własnym systemie.

W tym przypadku test portu TCP 25 nie wystarcza. Należy wysłać kilka kontrolowanych rzeczywistych wiadomości i zanotować czas UTC, nadawcę, odbiorcę oraz Message-ID. Następnie porównuje się kolejkę nadawcy lub bounce z kolejką i Transport Log wewnętrznego serwera pocztowego. Pakiet materiałów diagnostycznych dla pomocy technicznej powinien zawierać build firmware, timestamp, Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log oraz logi serwera pocztowego. Ścieżki logów i sposób pobrania Consolidated Troubleshooting Report opisano w artykule Sprawdzanie usług i logów Sophos Firewall przez CLI. Przy zgłoszeniu do pomocy technicznej trzeba wyraźnie wskazać NC-184583.

Known Issue dotyczy bezpośredniej ścieżki DNAT do wewnętrznego serwera pocztowego. W Sophos Firewall MTA Mode zapora sama odbiera wiadomość, a następnie ją przekazuje. Sophos nie potwierdza jednak ani tego, że problem na pewno nie dotyczy MTA Mode, ani tego, że przejście na ten tryb stanowi oficjalny workaround.

Jeżeli ta sama bezpośrednia ścieżka DNAT ma być skanowana przezroczyście, artykuł Konfiguracja Mail Protection w Legacy mode pokazuje wspólną weryfikację DNAT, SNAT, reguł SMTP i skanowania proxy. Jest to zwykły projekt, a nie workaround dla NC-184583.

Kiedy Black Hole DNAT jest dodatkowo przydatny

Jeśli usługa celowo musi pozostać publicznie dostępna, ale niektóre źródła powinny zostać przechwycone przed faktyczną publikacją, przydatna może być reguła czarnej dziury DNAT powyżej produktywnej reguły DNAT. Działa to na przykład w przypadku list znanych złych adresów IP, trwale niechcianych krajów lub powtarzających się źródeł skanerów.

Ta technika nie zastępuje prawidłowo zabezpieczonej publikacji. Produkcyjna reguła DNAT nadal musi być ściśle ograniczona, logowanie aktywne, a opublikowany serwer aktualny. Black Hole DNAT dodaje warstwę blokowania przed publikacją, ale nie jest właściwą architekturą bezpieczeństwa.

Czarna dziura DNAT jest szczególnie przydatna w następujących przypadkach:

• Powtarzające się źródła skanerów trafiające do tej samej opublikowanej usługi: Źródła można przechwycić przed produkcyjną regułą DNAT.
• Poszczególne kraje nie powinny mieć dostępu do przekierowania portów: Regułę blokowania można umieścić nad faktyczną regułą DNAT.
• Utrzymywana grupa złych adresów IP już istnieje: Grupy można użyć jako Original source reguły czarnej dziury.
• Usługa musi pozostać publiczna, ale powinno docierać do niej mniej ruchu botów: Reguła produkcyjna zostaje zachowana, a niechciane źródła są wcześniej przechwytywane.

Black Hole DNAT nie nadaje się do lokalnych usług zapory ogniowej, takich jak WebAdmin, User Portal, VPN Portal lub SSH dla samej zapory. Odpowiadają za to reguły wyjątków Device Access i Local Service ACL. W przypadku serwerów WWW publikowanych przez WAF powinieneś najpierw sprawdzić regułę WAF, ustawienia blokowania krajów i uwierzytelniania oraz logi WAF.

Kolejność jest ważna: reguła czarnej dziury DNAT musi znajdować się powyżej produktywnej reguły DNAT. Następnie powinieneś sprawdzić Log Viewer, czy zablokowane źródła rzeczywiście spełniają regułę czarnej dziury i dozwolone źródła w dalszym ciągu korzystają z produktywnej reguły NAT i reguły zapory ogniowej. Dokładną procedurę można znaleźć w Sophos Firewall: Blokuj kraje i złośliwe adresy IP.

Kontrola działania

Reguły DNAT należy regularnie sprawdzać. Stare publikacje stanowią typowe zagrożenie, ponieważ usługi często pozostają dostępne po przeniesieniu, zastąpieniu lub zakończeniu używania aplikacji.

W przypadku produktywnych reguł DNAT należy udokumentować co najmniej następujące elementy:

• Cel publikacji: Dokumentacja musi wyjaśniać, dlaczego usługa jest dostępna publicznie.
• Odpowiedzialna osoba lub zespół: Bez właściciela stare publikacje rzadko są usuwane.
• Publiczny adres IP i port zewnętrzny: Ułatwia audyt, monitorowanie i skanowanie zewnętrzne.
• Wewnętrzny serwer docelowy i port docelowy: Ważne w przypadku migracji serwerów, równoważenia obciążenia i zmian certyfikatów.
• Oczekiwane źródła: Pomaga określić, czy Any jest naprawdę konieczne.
• Środki ochrony: IPS, WAF alternatywa, MFA, źródła zagrożeń, rejestrowanie i status poprawek powinny być identyfikowalne.
• Data wygaśnięcia lub przeglądu: Publikacje tymczasowe wymagają jasno określonego końca.

Znacząca recenzja nie polega tylko na przyjrzeniu się regule. Powinieneś sprawdzić zewnętrznie, czy otwarte są tylko oczekiwane porty, sprawdzić w Log Viewer, które źródła faktycznie uzyskują dostęp i sprawdzić na serwerze docelowym, czy aplikacja jest nadal utrzymywana. Jeśli usługa jest potrzebna tylko wewnętrznie lub dla kilku partnerów, należy ponownie ocenić VPN, ZTNA, ograniczenie źródłowego adresu IP lub regułę WAF.

Usuwając stare reguły DNAT, nie należy po prostu usuwać reguły NAT. Często dołączone są do niego reguły zapory sieciowej, obiekty hosta, obiekty usług, reguły sprzężenia zwrotnego, reguły refleksyjne, wpisy DNS, kontrole monitorowania lub przekierowanie portów dostawcy. Lepszy jest krótki proces likwidacji:

1. Sprawdź ostatnie dostępy w Log Viewer.
2. Poproś osobę odpowiedzialną lub dział o potwierdzenie, że usługa nie jest już potrzebna.
3. Zidentyfikuj według ID odpowiednie reguły DNAT, osobno wygenerowane reguły loopback (pętli zwrotnej) i reflexive (refleksyjne reguły NAT) oraz reguły zapory, a następnie sprawdź innych użytkowników i zależności. Najpierw wyłącz tylko reguły używane wyłącznie przez wycofywaną publikację, wyraźnie uwzględniając osobno wygenerowane reguły, które nie są już potrzebne. Nie zakładaj, że wyłączenie reguły DNAT wyłącza wszystkie reguły pochodne; osobno wyłącz niepotrzebne reguły pochodne używane wyłącznie przez tę publikację. Nie wyłączaj w całości współdzielonego zezwolenia zapory: po sprawdzeniu zależności zachowaj je albo ostrożnie usuń tylko kryteria wycofywanej publikacji.
4. Użyj nowych sesji zewnętrznych, aby sprawdzić, czy wycofany port nie jest już dostępny. Sprawdź również planowany stan potrzebnych ścieżek wewnętrznych i inicjowanych przez serwer za pomocą nowych sesji, w tym współdzielone publikacje, które muszą pozostać dostępne. Istniejące sesje nie dowodzą cofnięcia zezwolenia.
5. Sprawdź monitoring i logi serwera pod kątem błędów oraz śledź skutki przez okres obserwacji.
6. Dopiero potem usuń obiekty, wpisy DNS i reguły dostawcy, których brak wykorzystania został wykazany.

Jeśli publikacja jest nadal potrzebna, przegląd powinien zakończyć się konkretnym wynikiem: pozostawić ją bez zmian, zawęzić, przenieść do WAF, zastąpić dostępem przez VPN/ZTNA albo ponownie ocenić w określonym terminie.

Często zadawane pytania