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 Fusion (tidigare 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.

⚠️ Kontrollerad arbetsbas från Avanet: Följande översikt är den interna snapshoten från den 4 september 2026 för SFOS 22. Den är utgångspunkt för planering och godkännande; målnamn kan ändras senare. Fasta IP-adresser från en enda DNS-uppslagning ersätter inte FQDN och wildcards. Ansvarig brandvägsägare följer avstämningen nedan innan snapshoten ändras.

Snabb kontroll när en Sophos-tjänst inte fungerar

1. Dokumentera berörd funktion, feltidpunkt och aktuell SFOS-build.
2. Kontrollera att brandväggen kan slå upp målnamnet från snapshoten via DNS och att systemtid och NTP-synkronisering är korrekta.
3. Sök på upstreamroutern eller egressfiltret efter en blockering som gäller brandväggens WAN-adress, mål-FQDN och nödvändig port.
4. Tillåt endast den funktionsgrupp som saknas, inte generellt *.sophos.com, Any och alla portar.
5. 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 är den godkända snapshoten för den inledande planeringen. Välj bara funktionsgrupper som är aktiva på den aktuella brandväggen eller planerade för driftsättning. För regionala Sophos Fusion-tjänster tillåts endast den region som faktiskt används. En organisation i Frankfurt-regionen behöver till exempel inte automatiskt S3-mål i Oregon, Mumbai, Sydney och Tokyo.

utm.cloud.sophos.com/api/utm är en URL med en sökväg, inte ett FQDN. Om upstreamprodukten endast accepterar ett FQDN som mål anges därför bara värdnamnet utm.cloud.sophos.com; /api/utm hör inte hemma i ett FQDN-objekt. Snapshoten innehåller specifika upe.p.hmr.sophos.com-värdar för Heartbeat och Sophos Fusion, inte en regel för hela wildcarddomänen. Dessa namn kan ändras när plattformen drivs och uppdateras endast genom den kontrollerade avstämningen. På samma sätt gäller pool.ntp.org endast när standardmålet för NTP används; om en annan NTP-server har konfigurerats ska den destinationen tillåtas i stället.

Välj regionala mål för rapporter och backup

Kontrollera först vilken region respektive tjänst faktiskt använder i den egna Sophos Fusion-miljön. Organisationens fysiska plats avgör inte detta på egen hand. Om kopplingen är oklar, identifiera målet för en rapportuppladdning eller backup med Packet Capture och upstreamloggen och klargör det före tillåtelsen. Listan är en katalog, inte en gemensam allowlist: välj endast de mål som behövs för den region och funktion som används. CFR skickar rapporter och loggar; backup används för att spara och återställa brandväggens konfiguration.

• USA (Oregon) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Backup: 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
  • Backup: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europa (Irland) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Backup: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• Östra USA (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Backup: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Asien och Stillahavsområdet (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Backup: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Asien och Stillahavsområdet (Tokyo) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Backup: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Kanada (Central) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Backup: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Asien och Stillahavsområdet (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Backup: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Förenade Arabemiraten (Dubai) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Backup: *.s3.me-central-1.amazonaws.com — det dokumenterade undantaget, inte en grund för att hitta på en enskild backupvärd.

För de första åtta regionerna är TCP 443 porten för dessa tjänstegrupper. Källbegränsning för Dubai: Båda frysta tjänstetabellerna innehåller nio regionrader, men de gemensamma cellerna för port och syfte omfattar bara åtta rader (rowspan=8); Dubai-cellerna är tomma. Översikten ovan anger TCP 443 på tjänstegruppsnivå, inte som ett uttryckligen ifyllt portvärde för UAE. Målen för Dubai är dokumenterade, men den regionala porten är fortfarande oklar i dessa tabeller. Klargör den genom den kontrollerade avstämningen innan UAE-åtkomst tillåts; här fylls inget saknat cellvärde i och inget produktbeteende påstås vara testat.

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 endast Sophos Firewalls WAN-adress som källa, exakt så som filtreringsenheten ser den före eller efter en eventuell adressöversättning. 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 namnen från den godkända snapshoten 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: i snapshoten hör denna breda wildcard endast till Central Firewall Management. Utöka den inte 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

Under Diagnostics > Tools > Name lookup kan ett målnamn från snapshoten först lösas upp utan att konfigurationen ändras. Lookup using all configured servers visar om de konfigurerade resolvrarna ger olika svar eller tar ovanligt lång tid. Alternativt kan den välkända Device Console-frågan användas:

dnslookup host xg-up2date-firmwares.sophosupd.com

Under Diagnostics > Packet capture visar en snäv capture 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 Display filter till konkret mål-IP och port. Statusen Generated identifierar paket som brandväggen själv har skapat. Sök parallellt i upstreamsystemet efter samma tidsfönster, källa och destination. Stäng av capture efter testet; bufferten är begränsad och ersätter inte permanent loggning.

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 Fusion 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, Sophos Fusion 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 och tillfälligt breda testregler.

Brandvägsägaren granskar snapshoten minst kvartalsvis samt före firmwareuppgraderingar, när en ny Sophos-funktion aktiveras, efter regionsbyte, efter ett relevant tillverkarmeddelande och under olösta anslutningsincidenter. I det konkreta avstämningssteget öppnas den föränderliga sidan Default services, och granskningsdatum, SFOS-build, granskare och diff mot den interna snapshoten dokumenteras.

Varje tillagd, ändrad eller borttagen post kopplas till en aktiv funktion, region och port. Tillägg införs en funktionsgrupp i taget under ett servicefönster och valideras med DNS, Packet Capture, upstreamlogg och funktionstest. Ett mål tas inte bort enbart för att det saknas i diffen: kontrollera först användningen i regelloggen, inaktivera sedan det gamla objektet och övervaka under en bestämd observationsperiod. Om valideringen misslyckas återställs ändringen och föregående snapshot förblir godkänd. Först ett lyckat test skapar en ny daterad snapshot.

Återställ oväntade bieffekter

Exportera eller spara den befintliga upstreamregelbasen på annat sätt före ändringen. Om oväntade anslutningar eller andra bieffekter uppstår efteråt ska endast den nya regeln inaktiveras eller dess senast dokumenterade omfattning av mål och portar återställas. Testa sedan både den ursprungligen berörda funktionen och en oberoende normal internetanslutning igen. Då går det att avgöra om allowlist-regeln orsakade bieffekten utan att samtidigt ändra andra regler.

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.

Vanliga frågor