Kontrollera utgående tjänster och portar för Sophos Firewall
Sophos Firewall skapar själv anslutningar till Sophos och vissa externa plattformstjänster. De används för att hämta firmware och patterns, synkronisera licenser, ansluta RED-enheter, skicka rapporter till Sophos Central eller öppna Support Access. Om en annan router, proxy eller ett egressfilter finns framför brandväggen kan enskilda funktioner sluta fungera trots att vanlig klienttrafik fortfarande fungerar.
Den viktigaste avgränsningen är att detta är systemtrafik som genereras av brandväggen själv. En extra bred LAN-to-WAN-regel på Sophos Firewall åtgärdar inte ett upstreamfilter. Det krävs en riktad utgående regel i det upstreamsystem som faktiskt blockerar anslutningen.
⚠️ Målnamnen är en föränderlig tillverkarlista. Följande översikt motsvarar den offentliga SFOS 22-dokumentationen den 21 augusti 2026. Kontrollera den aktuella Sophos-sidan Default services igen innan en produktions-allowlist skapas. Fasta IP-adresser från en enda DNS-uppslagning är ingen permanent ersättning för dokumenterade FQDN och wildcards.
Snabb kontroll när en Sophos-tjänst inte fungerar
- Dokumentera berörd funktion, feltidpunkt och aktuell SFOS-build.
- Kontrollera att brandväggen kan slå upp det dokumenterade målnamnet via DNS och att systemtid och NTP-synkronisering är korrekta.
- Sök på upstreamroutern eller egressfiltret efter en blockering som gäller brandväggens WAN-adress, mål-FQDN och nödvändig port.
- Tillåt endast den funktionsgrupp som saknas, inte generellt
*.sophos.com,Anyoch alla portar. - Starta exakt ett nytt test och jämför Packet Capture, upstreamloggen och motsvarande SFOS-servicelogg efter tidpunkt.
En lyckad DNS-upplösning visar bara att målnamnet kan lösas upp. En lyckad TCP-handshake visar ännu inte att licensiering, uppdatering, upload eller RED-provisionering fungerar hela vägen. Testa den faktiska funktionen igen efter ändringen av nätverksregeln.
Mål och portar som SFOS 22 behöver
Tabellen sammanfattar de viktigaste grupperna. För regionala Sophos Central-tjänster tillåts endast den region som faktiskt används. En organisation i Frankfurt-regionen behöver till exempel inte automatiskt alla S3-mål i Oregon, Mumbai, Sydney och Tokyo.
| Funktion | Dokumenterade mål | Portar | Typiskt symptom |
|---|---|---|---|
| Webbkategorisering och IP-reputation | 4.sophosxl.net | TCP 443 | Kategorier eller reputation bedöms inte med aktuella data. |
| Firmware-, pattern- och klientuppdateringar | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware eller patterns fastnar vid kontroll eller hämtning. |
| Extra antivirusskanner för små appliances | oem.avdl.ctmail.com | TCP 80 | Extra antivirusuppdateringar misslyckas. |
| Licensiering | *.soa.sophos.com | TCP 443 | Aktivering eller licenssynkronisering misslyckas. |
| RED-provisionering | *.astaro.com | TCP 3400, UDP 3410 | RED-enheten registreras inte eller skapar ingen tunnel. |
| Security Heartbeat och Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, regionala *.upe.p.hmr.sophos.com-värdar som Sophos dokumenterar samt *.sophos.com för Central Firewall Management | TCP 80, 443; Central Firewall Management använder dessutom TCP 22 | Registrering, Heartbeat, Synchronized Application Control eller Central-hantering förblir offline. |
| Central Firewall Reporting | regional värd tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Loggar och rapporter visas inte i Central. |
| Central Firewall Backup | regional värd <region>-firewall-backup.s3.<region>.amazonaws.com; för UAE dokumenterar Sophos *.s3.me-central-1.amazonaws.com | TCP 443 | Central-backup eller restore når inte lagringen. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Filer skickas inte till sandbox eller resultat saknas. |
| Support Access | *.apu.sophos.com | TCP 22 | Den utgående supporttunneln kan inte skapas. |
| NTP | pool.ntp.org | UDP 123 | Tiden driver; certifikat, MFA, Kerberos eller loggar verkar inkonsekventa. |
| SAR, telemetri och DDNS-kontroll | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; DDNS-kontroll använder TCP 80 | Security Audit Report, telemetri eller detektering av publik IP fungerar inte. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | ZTNA-datavägen eller anslutningen till Sophos Central misslyckas. |
Sophos anger dessutom enskilda konkreta Heartbeat- och Central-värdar. Dessa värden kan ändras genom region, plattformsdrift eller tillverkarändringar. Tabellen omvandlas därför inte till en statisk IP-lista.
Bygg egress-allowlist säkert
Skapa regeln på den enhet som faktiskt filtrerar utgående systemtrafik. Det kan vara en upstreambrandvägg, en operatörsrouter eller en cloud network firewall. Använd där endast Sophos Firewalls publika eller översatta adress som källa. Använd nödvändiga FQDN som mål och endast dokumenterade TCP- eller UDP-portar som tjänster.
Hantera wildcards och dynamiska IP-adresser korrekt
Många Sophos-tjänster använder CDN, cloudplattformar eller regionalt distribuerade värdar. IP-adresserna bakom ett FQDN kan ändras. En enda nslookup, följd av fasta IP-poster och en oförändrad allowlist under flera år, är därför inte tillförlitlig.
Om upstreamfiltret stöder FQDN- eller URL-baserade regler underhålls de namn som Sophos dokumenterar där. Om enheten bara kan filtrera IP-adresser krävs en dokumenterad process för regelbunden upplösning och uppdatering. Att brett tillåta alla AWS- eller Sophos-nät är ingen likvärdig ersättning och ökar den tillåtna angreppsytan i onödan.
Var särskilt försiktig med *.sophos.com: Sophos anger uttryckligen denna breda wildcard för Central Firewall Management. Utöka den inte automatiskt till andra funktioner eller fler portar. RED, uppdateringar, sandbox, licensiering och Support Access har snävare målmönster.
Skapa ingen inkommande WAN-regel
De här anslutningarna börjar på brandväggen och går utåt. Skapa ingen inkommande DNAT- eller WAN-to-Local-regel för dem. Lägg inte heller till ett brett undantag från TLS Inspection, IPS eller Web Filtering på misstanke. Kontrollera först DNS, route, upstreamblockering och den konkreta tjänsten.
Support Access är särskilt lätt att missförstå: brandväggen ansluter utgående via TCP 22 till *.apu.sophos.com. Det säkra arbetsflödet för att aktivera och tidsbegränsa åtkomsten finns i Konfigurera Sophos Firewall Support Access.
Avgränsa fel systematiskt
Kontrollera DNS, route och port separat
I Device Console kan ett dokumenterat målnamn först kontrolleras skrivskyddat:
dnslookup host xg-up2date-firmwares.sophosupd.com
En snäv Packet Capture visar sedan om brandväggen startar en anslutning till den upplösta adressen, vilket WAN-gränssnitt den använder och om svar kommer tillbaka. Begränsa capture till konkret mål-IP och port. Sök parallellt i upstreamsystemet efter samma tidsfönster, källa och destination.
Tolka resultatet lager för lager:
- Inget DNS-svar: kontrollera DNS-server, route till resolvern och systemtid.
- SYN lämnar brandväggen men inget svar återkommer: kontrollera upstreamregel, operatörsväg, NAT och returväg.
- TCP eller UDP fungerar men funktionen är fortfarande felaktig: kontrollera motsvarande servicelogg och produktstatus; nätverksanslutning ensam är inget fullständigt funktionsbevis.
- Endast en HA-nod visar felet: kontrollera loggar och capture på den nod som behandlade anslutningen vid feltidpunkten.
Använd rätt SFOS-servicelogg
För uppdateringar är u2d.log och up2date_av.log bra utgångspunkter; för licensiering licensing.log, för RED red.log, för sandbox sandboxd.log och för Sophos Central bland annat centralmanagement.log, sophos-central.log och filerna fwcm-*.log. För NTP passar ntpclient.log. Fullständig mappning och säker export finns i Hitta och tolka Sophos Firewall-serviceloggar.
I HA ligger serviceloggar på den nod som behandlade anslutningen. Ett lyckat test på nuvarande Primary bevisar inte i efterhand att den andra noden hade samma anslutning vid feltidpunkten. Dokumentera därför tid, nod, målnamn, upplöst IP och port tillsammans.
Validera och förvalta ändringen
Efter en ny egressregel ska inte bara porttestet upprepas. Den faktiska funktionen måste visa ett synligt lyckat resultat: ett pattern får ny status, licensen synkroniseras, RED ansluter, Central tar emot uppgiften, en rapport visas eller Support Access visar en aktiv session.
Låt logging vara aktiverad på upstreamregeln och granska den efter några dagar. Ta bort oanvända regioner, gamla målnamn och tillfälligt breda testregler. Jämför den aktuella Default services-listan igen före firmwareuppgraderingar eller när nya Sophos-funktioner aktiveras, så att beroendet inte upptäcks först under servicefönstret.
Framgångskriterium: DNS-upplösning, etablering av utgående anslutning, passande upstream-allowlist och funktionstest lyckas tillsammans. Om ett lager saknas är problemet ännu inte korrekt löst.