Sprawdzanie usług i portów wychodzących Sophos Firewall

Sophos Firewall sam nawiązuje połączenia z Sophos i niektórymi zewnętrznymi usługami platformowymi. Służą one do pobierania firmware i patternów, synchronizacji licencji, łączenia urządzeń RED, wysyłania raportów do Sophos Fusion (dawniej Sophos Central) oraz otwierania Support Access. Jeśli przed firewallem znajduje się kolejny router, proxy lub filtr egress, poszczególne funkcje mogą przestać działać, mimo że zwykły ruch klientów nadal funkcjonuje.

Najważniejsze rozróżnienie: jest to ruch systemowy generowany przez sam firewall. Dodatkowa szeroka reguła LAN-to-WAN na Sophos Firewall nie naprawi filtra upstream. Potrzebna jest ukierunkowana reguła wychodząca w systemie upstream, który rzeczywiście blokuje połączenie.

⚠️ Kontrolowana baza robocza Avanet: Poniższe zestawienie jest wewnętrznym snapshotem z 4 września 2026 r. dla SFOS 22. Stanowi bazę do planowania i odbioru; nazwy docelowe mogą później ulec zmianie. Stałe adresy IP z pojedynczego zapytania DNS nie zastępują FQDN ani wildcardów. Odpowiedzialny administrator firewalla wykonuje opisaną niżej rekoncyliację przed zmianą snapshotu.

Szybka kontrola, gdy usługa Sophos nie działa

1. Zapisać dotkniętą funkcję, czas błędu i aktualną build SFOS.
2. Sprawdzić, czy firewall rozwiązuje przez DNS nazwę docelową ze snapshotu oraz czy czas systemowy i synchronizacja NTP są poprawne.
3. Na routerze lub filtrze egress upstream wyszukać blokadę dotyczącą adresu WAN firewalla, docelowego FQDN i wymaganego portu.
4. Zezwolić tylko na brakującą grupę funkcjonalną, a nie ogólnie na *.sophos.com, Any i wszystkie porty.
5. Uruchomić dokładnie jeden nowy test i porównać według czasu Packet Capture, log upstream oraz odpowiedni log usługi SFOS.

Pomyślna odpowiedź DNS potwierdza tylko możliwość rozwiązania nazwy. Pomyślny handshake TCP nie potwierdza jeszcze pełnego działania licencji, aktualizacji, uploadu ani provisioningu RED. Po zmianie reguły sieciowej trzeba ponownie przetestować właściwą funkcję.

Cele i porty wymagane przez SFOS 22

Tabela jest zatwierdzonym snapshotem do wstępnego planowania. Wybiera się tylko grupy funkcjonalne aktywne na danym firewallu lub przewidziane do zaplanowanego wdrożenia. W przypadku regionalnych usług Sophos Fusion zezwala się wyłącznie na faktycznie używany region. Organizacja w regionie Frankfurt nie potrzebuje na przykład automatycznie celów S3 w Oregonie, Mumbai, Sydney i Tokio.

utm.cloud.sophos.com/api/utm jest adresem URL ze ścieżką, a nie FQDN. Jeśli produkt upstream akceptuje jako cel wyłącznie FQDN, należy wpisać tylko host utm.cloud.sophos.com; /api/utm nie należy do obiektu FQDN. Snapshot zawiera konkretne hosty upe.p.hmr.sophos.com dla Heartbeat i Sophos Fusion, a nie zezwolenie na całą domenę wildcard. Nazwy te mogą się zmieniać wraz z działaniem platformy i są aktualizowane wyłącznie w kontrolowanej rekoncyliacji. Podobnie pool.ntp.org ma zastosowanie tylko wtedy, gdy używany jest domyślny cel NTP; jeśli skonfigurowano inny serwer NTP, należy zezwolić na jego adres docelowy.

Wybór regionalnych celów dla raportów i kopii zapasowych

Najpierw należy potwierdzić region faktycznie używany przez daną usługę we własnym środowisku Sophos Fusion. Sama lokalizacja organizacji go nie określa. Jeśli przypisanie jest niejasne, należy zidentyfikować cel wysyłania raportu lub kopii zapasowej za pomocą Packet Capture i logu upstream oraz wyjaśnić go przed zezwoleniem na dostęp. Poniższa lista jest katalogiem, a nie zbiorczą allowlistą: wybiera się tylko potrzebne cele używanego regionu i funkcji. CFR wysyła raporty i logi; kopia zapasowa służy do zapisywania i przywracania konfiguracji firewalla.

• Stany Zjednoczone (Oregon) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Kopia zapasowa: us-west-2-firewall-backup.s3.us-west-2.amazonaws.com
• Europa (Frankfurt) — eu-central-1
  • CFR: tf-presigned-url-eu-central-1-prod-firewall-bucket.s3.eu-central-1.amazonaws.com
  • Kopia zapasowa: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europa (Irlandia) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Kopia zapasowa: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• Wschód USA (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Kopia zapasowa: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Azja i Pacyfik (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Kopia zapasowa: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Azja i Pacyfik (Tokio) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Kopia zapasowa: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Kanada (Centralna) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Kopia zapasowa: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Azja i Pacyfik (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Kopia zapasowa: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Zjednoczone Emiraty Arabskie (Dubaj) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Kopia zapasowa: *.s3.me-central-1.amazonaws.com — udokumentowany wyjątek, a nie podstawa do wymyślenia pojedynczego hosta kopii zapasowych.

Dla pierwszych ośmiu regionów portem tych grup usług jest TCP 443. Ograniczenie źródła dla Dubaju: Obie zamrożone tabele usług zawierają dziewięć wierszy regionalnych, ale wspólne komórki portu i przeznaczenia obejmują tylko osiem (rowspan=8); komórki Dubaju są puste. Zestawienie powyżej przypisuje TCP 443 na poziomie grupy usług, a nie jako jawnie podaną wartość portu UAE. Cele dla Dubaju są udokumentowane, ale regionalny port pozostaje w tych tabelach niejednoznaczny. Należy go wyjaśnić w ramach kontrolowanej rekoncyliacji przed zezwoleniem na dostęp do UAE; tutaj nie uzupełnia się brakującej wartości ani nie twierdzi, że zachowanie produktu zostało przetestowane.

Bezpieczne tworzenie allowlisty egress

Regułę tworzy się na urządzeniu, które rzeczywiście filtruje wychodzący ruch systemowy. Może to być firewall upstream, router operatora albo firewall sieci cloud. Jako źródła używa się wyłącznie adresu WAN Sophos Firewall w postaci widzianej przez urządzenie filtrujące przed ewentualną translacją lub po niej. Celami są potrzebne FQDN, a usługami wyłącznie udokumentowane porty TCP lub UDP.

Prawidłowa obsługa wildcardów i dynamicznych adresów IP

Wiele usług Sophos korzysta z CDN, platform cloud lub hostów rozproszonych regionalnie. Adresy IP za FQDN mogą się zmieniać. Jednorazowy nslookup, po którym wpisuje się stałe IP i pozostawia allowlistę bez zmian przez lata, nie jest wiarygodny.

Jeśli filtr upstream obsługuje reguły FQDN lub URL, należy utrzymywać w nim nazwy z zatwierdzonego snapshotu. Jeśli urządzenie filtruje tylko adresy IP, potrzebny jest udokumentowany proces regularnego rozwiązywania nazw i aktualizacji. Szerokie zezwolenie na wszystkie sieci AWS lub Sophos nie jest równoważnym zamiennikiem i niepotrzebnie zwiększa dozwoloną powierzchnię ataku.

Szczególną ostrożność zachować przy *.sophos.com: w snapshotcie ten szeroki wildcard należy wyłącznie do Central Firewall Management. Nie należy rozszerzać go na inne funkcje lub porty. RED, aktualizacje, sandbox, licencje i Support Access mają węższe wzorce docelowe.

Nie tworzyć przychodzącej reguły WAN

Te połączenia rozpoczynają się na firewallu i wychodzą na zewnątrz. Nie tworzy się dla nich przychodzącej reguły DNAT ani WAN-to-Local. Nie należy też na wszelki wypadek dodawać szerokiego wyjątku od TLS Inspection, IPS lub Web Filtering. Najpierw sprawdza się DNS, trasę, blokadę upstream i konkretną usługę.

Support Access łatwo błędnie zinterpretować: firewall łączy się wychodząco przez TCP 22 z *.apu.sophos.com. Bezpieczny proces włączania i ograniczania czasu opisuje artykuł Konfiguracja Sophos Firewall Support Access.

Systematyczne zawężanie błędów

Oddzielna kontrola DNS, trasy i portu

W Diagnostics > Tools > Name lookup można najpierw rozwiązać nazwę docelową ze snapshotu bez zmiany konfiguracji. Lookup using all configured servers pokazuje, czy skonfigurowane resolvery odpowiadają inaczej lub wyjątkowo długo. Alternatywnie można użyć znanego zapytania Device Console:

dnslookup host xg-up2date-firmwares.sophosupd.com

Następnie Diagnostics > Packet capture pokazuje, czy firewall rozpoczyna połączenie z rozwiązanym adresem, którego interfejsu WAN używa i czy wracają odpowiedzi. Display filter ogranicza się do konkretnego docelowego IP i portu. Stan Generated oznacza pakiety utworzone przez sam firewall. Równolegle w systemie upstream wyszukuje się to samo okno czasowe, źródło i cel. Po teście capture należy wyłączyć; jego bufor jest ograniczony i nie zastępuje stałego logowania.

Wynik interpretuje się warstwami:

• Brak odpowiedzi DNS: sprawdzić serwer DNS, trasę do resolvera i czas systemowy.
• SYN opuszcza firewall, ale brak odpowiedzi: sprawdzić regułę upstream, ścieżkę operatora, NAT i drogę powrotną.
• TCP lub UDP działa, ale funkcja nadal nie: sprawdzić odpowiedni log usługi i stan produktu; sama łączność nie jest pełnym potwierdzeniem funkcji.
• Błąd występuje tylko na jednym węźle HA: sprawdzić logi i capture na węźle, który obsługiwał połączenie w czasie błędu.

Używanie właściwego logu usługi SFOS

Dla aktualizacji dobrym początkiem są u2d.log i up2date_av.log; dla licencji licensing.log, dla RED red.log, dla sandbox sandboxd.log, a dla Sophos Fusion między innymi centralmanagement.log, sophos-central.log i pliki fwcm-*.log. Dla NTP odpowiada ntpclient.log. Pełne przypisanie i bezpieczny eksport opisuje artykuł Znajdowanie i interpretowanie logów usług Sophos Firewall.

W HA logi usług znajdują się na węźle, który przetwarzał połączenie. Udany test na aktualnym Primary nie dowodzi wstecznie, że drugi węzeł miał takie samo połączenie podczas błędu. Dlatego razem zapisuje się czas, węzeł, nazwę docelową, rozwiązane IP i port.

Odbiór i eksploatacja zmiany

Po dodaniu reguły egress nie powtarza się tylko testu portu. Właściwa funkcja musi pokazać widoczny sukces: pattern zmienia stan, licencja się synchronizuje, RED łączy się, Sophos Fusion otrzymuje zadanie, pojawia się raport albo Support Access pokazuje aktywną sesję.

Logging reguły upstream należy pozostawić włączony i sprawdzić po kilku dniach. Usuwa się nieużywane regiony i tymczasowo szerokie reguły testowe.

Administrator odpowiedzialny za firewall przegląda snapshot co najmniej raz na kwartał, a także przed upgrade firmware, przy włączaniu nowej funkcji Sophos, po zmianie regionu, po istotnym komunikacie producenta i podczas nierozwiązanych incydentów łączności. W tym konkretnym kroku rekoncyliacji otwiera zmienną stronę Default services i zapisuje datę, build SFOS, osobę sprawdzającą oraz diff względem wewnętrznego snapshotu.

Każdy dodany, zmieniony lub usunięty wpis przypisuje się do aktywnej funkcji, regionu i portu. Dodatki wdraża się po jednej grupie funkcjonalnej w oknie serwisowym, a następnie weryfikuje przez DNS, Packet Capture, log upstream i test funkcji. Celu nie usuwa się wyłącznie dlatego, że zniknął w diffie: najpierw sprawdza się jego użycie w logu reguły, potem wyłącza stary obiekt i obserwuje go przez ustalony okres. Jeśli walidacja się nie powiedzie, zmiana jest wycofywana, a poprzedni snapshot pozostaje zatwierdzony. Dopiero udany test tworzy nowy datowany snapshot.

Wycofanie nieoczekiwanych skutków

Przed zmianą należy wyeksportować lub w inny sposób zapisać istniejący zestaw reguł upstream. Jeśli później pojawią się nieoczekiwane połączenia lub inne skutki, wyłącza się tylko nową regułę albo przywraca jej ostatni udokumentowany zakres celów i portów. Następnie ponownie testuje się zarówno pierwotnie dotkniętą funkcję, jak i niezależne zwykłe połączenie internetowe. Pozwala to ustalić, czy skutek wywołała allowlista, bez równoczesnej zmiany innych reguł.

Kryterium sukcesu: rozwiązanie DNS, zestawienie połączenia wychodzącego, odpowiednia allowlista upstream i test funkcjonalny są wspólnie udane. Jeśli brakuje jednej warstwy, problem nie został jeszcze poprawnie rozwiązany.

Często zadawane pytania