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 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.
⚠️ Nazwy docelowe są zmienną listą producenta. Poniższe zestawienie odpowiada publicznej dokumentacji SFOS 22 z 21 sierpnia 2026 r. Przed utworzeniem produkcyjnej allowlisty należy ponownie sprawdzić aktualną stronę Sophos Default services. Stałe adresy IP z pojedynczego zapytania DNS nie są trwałym zamiennikiem udokumentowanych FQDN i wildcardów.
Szybka kontrola, gdy usługa Sophos nie działa
- Zapisać dotkniętą funkcję, czas błędu i aktualną build SFOS.
- Sprawdzić, czy firewall rozwiązuje udokumentowaną nazwę docelową przez DNS oraz czy czas systemowy i synchronizacja NTP są poprawne.
- Na routerze lub filtrze egress upstream wyszukać blokadę dotyczącą adresu WAN firewalla, docelowego FQDN i wymaganego portu.
- Zezwolić tylko na brakującą grupę funkcjonalną, a nie ogólnie na
*.sophos.com,Anyi wszystkie porty. - 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 podsumowuje najważniejsze grupy. W przypadku regionalnych usług Sophos Central zezwala się wyłącznie na faktycznie używany region. Organizacja w regionie Frankfurt nie potrzebuje na przykład automatycznie wszystkich celów S3 w Oregonie, Mumbai, Sydney i Tokio.
| Funkcja | Udokumentowane cele | Porty | Typowy objaw |
|---|---|---|---|
| Kategoryzacja Web i reputacja IP | 4.sophosxl.net | TCP 443 | Kategorie lub reputacja nie są oceniane na podstawie aktualnych danych. |
| Aktualizacje firmware, patternów i klientów | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware lub patterny zatrzymują się podczas kontroli albo pobierania. |
| Dodatkowy skaner antywirusowy dla małych appliance | oem.avdl.ctmail.com | TCP 80 | Dodatkowe aktualizacje antywirusowe nie działają. |
| Licencjonowanie | *.soa.sophos.com | TCP 443 | Aktywacja lub synchronizacja licencji nie działa. |
| Provisioning RED | *.astaro.com | TCP 3400, UDP 3410 | Urządzenie RED nie rejestruje się lub nie zestawia tunelu. |
| Security Heartbeat i Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, regionalne hosty *.upe.p.hmr.sophos.com udokumentowane przez Sophos oraz *.sophos.com dla Central Firewall Management | TCP 80, 443; Central Firewall Management używa dodatkowo TCP 22 | Rejestracja, Heartbeat, Synchronized Application Control lub zarządzanie Central pozostaje offline. |
| Central Firewall Reporting | regionalny host tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Logi i raporty nie pojawiają się w Central. |
| Central Firewall Backup | regionalny host <region>-firewall-backup.s3.<region>.amazonaws.com; dla UAE Sophos dokumentuje *.s3.me-central-1.amazonaws.com | TCP 443 | Backup lub restore Central nie dociera do magazynu. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Pliki nie są wysyłane do sandbox lub brakuje wyników. |
| Support Access | *.apu.sophos.com | TCP 22 | Nie można zestawić wychodzącego tunelu supportu. |
| NTP | pool.ntp.org | UDP 123 | Czas się rozjeżdża; certyfikaty, MFA, Kerberos lub logi wyglądają niespójnie. |
| SAR, telemetria i kontrola DDNS | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; kontrola DDNS używa TCP 80 | Security Audit Report, telemetria lub ustalanie publicznego IP nie działa. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | Ścieżka danych ZTNA lub połączenie z Sophos Central nie działa. |
Sophos wymienia również pojedyncze konkretne hosty Heartbeat i Central. Te wartości mogą się zmieniać wraz z regionem, działaniem platformy lub zmianami producenta. Dlatego tabela nie jest zamieniana na statyczną listę IP.
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. Na tym systemie jako źródło należy użyć tylko publicznego lub przetłumaczonego adresu Sophos Firewall. 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 dokumentowane przez Sophos. 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: Sophos wyraźnie podaje ten szeroki wildcard dla Central Firewall Management. Nie należy automatycznie 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 Device Console można najpierw wykonać tylko do odczytu kontrolę udokumentowanej nazwy docelowej:
dnslookup host xg-up2date-firmwares.sophosupd.com
Następnie wąski Packet Capture pokazuje, czy firewall rozpoczyna połączenie z rozwiązanym adresem, którego interfejsu WAN używa i czy wracają odpowiedzi. Capture ogranicza się do konkretnego docelowego IP i portu. Równolegle w systemie upstream wyszukuje się to samo okno czasowe, źródło i cel.
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 Central 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ę, Central 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, stare nazwy docelowe i tymczasowo szerokie reguły testowe. Przed upgrade firmware lub włączeniem nowych funkcji Sophos ponownie porównuje się aktualną listę Default services, aby brakująca zależność nie ujawniła się dopiero podczas okna serwisowego.
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.