Uitgaande services en poorten van Sophos Firewall controleren

Sophos Firewall maakt zelf verbinding met Sophos en enkele externe platformservices. Daarmee downloadt de firewall firmware en patterns, synchroniseert hij licenties, verbindt hij RED-apparaten, stuurt hij rapporten naar Sophos Fusion (voorheen Sophos Central) of opent hij Support Access. Als vóór de firewall nog een router, proxy of egressfilter staat, kunnen afzonderlijke functies uitvallen terwijl normaal clientverkeer blijft werken.

De belangrijkste afbakening is dat dit door de firewall zelf gegenereerd systeemverkeer is. Een extra brede LAN-to-WAN-regel op Sophos Firewall verhelpt geen upstreamfilter. Er is een gerichte uitgaande regel nodig op het upstreamsysteem dat de verbinding werkelijk blokkeert.

⚠️ Door Avanet beheerde werkbasis: Het onderstaande overzicht is de interne snapshot van 4 september 2026 voor SFOS 22. Dit is de basis voor planning en acceptatie; doelnamen kunnen later veranderen. Vaste IP-adressen uit één DNS-lookup vervangen FQDN’s en wildcards niet. De verantwoordelijke firewallbeheerder volgt vóór een wijziging van de snapshot het reconciliatieproces verderop.

Snel controleren wanneer een Sophos-service niet werkt

1. Leg de betrokken functie, het fouttijdstip en de actuele SFOS-build vast.
2. Controleer of de firewall de doelnaam uit de snapshot via DNS oplost en of systeemtijd en NTP-synchronisatie correct zijn.
3. Zoek op de upstreamrouter of het egressfilter naar een blokkade van het WAN-adres van de firewall, de doel-FQDN en de vereiste poort.
4. Sta alleen de ontbrekende functiegroep toe, niet algemeen *.sophos.com, Any en alle poorten.
5. Start precies één nieuwe test en vergelijk Packet Capture, het upstreamlog en het passende SFOS-servicelog op tijdstip.

Een geslaagde DNS-resolutie bewijst alleen dat een doelnaam kan worden opgelost. Een geslaagde TCP-handshake bewijst nog niet dat licenties, updates, uploads of RED-provisioning volledig werken. Test na de netwerkwijziging opnieuw de werkelijke functie.

Doelen en poorten die SFOS 22 nodig heeft

De tabel is de goedgekeurde snapshot voor de eerste planning. Selecteer alleen functiegroepen die op de betreffende firewall actief zijn of voor een geplande uitrol nodig zijn. Sta bij regionale Sophos Fusion-services alleen de werkelijk gebruikte regio toe. Een organisatie in de regio Frankfurt heeft bijvoorbeeld niet automatisch S3-doelen in Oregon, Mumbai, Sydney en Tokio nodig.

utm.cloud.sophos.com/api/utm is een URL met een pad, geen FQDN. Als het upstreamproduct alleen een FQDN als doel accepteert, voer dan uitsluitend de host utm.cloud.sophos.com in; /api/utm hoort niet in een FQDN-object. De snapshot bevat specifieke upe.p.hmr.sophos.com-hosts voor Heartbeat en Sophos Fusion, niet een regel voor het volledige wildcarddomein. Deze namen kunnen door platformwijzigingen veranderen en worden alleen via gecontroleerde reconciliatie bijgewerkt. Ook geldt pool.ntp.org alleen wanneer de standaard-NTP-bestemming wordt gebruikt; als een andere NTP-server is ingesteld, moet die bestemming worden toegestaan.

Regionale doelen voor rapporten en back-ups kiezen

Controleer eerst welke regio de betreffende service werkelijk gebruikt in de eigen Sophos Fusion-omgeving. De vestigingsplaats van de organisatie bepaalt dit niet op zichzelf. Is de koppeling onduidelijk, identificeer dan het doel van een rapportupload of back-up met Packet Capture en het upstreamlog en verduidelijk dit vóór de vrijgave. Deze lijst is een catalogus, geen gezamenlijke allowlist: neem alleen de benodigde doelen voor de gebruikte regio en functie over. CFR verstuurt rapporten en logs; back-up dient voor het opslaan en herstellen van de firewallconfiguratie.

• Verenigde Staten (Oregon) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Back-up: 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
  • Back-up: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europa (Ierland) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Back-up: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• Oosten van de VS (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Back-up: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Azië-Pacific (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Back-up: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Azië-Pacific (Tokio) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Back-up: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Canada (Centraal) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Back-up: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Azië-Pacific (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Back-up: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Verenigde Arabische Emiraten (Dubai) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Back-up: *.s3.me-central-1.amazonaws.com — de gedocumenteerde uitzondering, geen basis om één back-uphost te verzinnen.

Voor de eerste acht regio’s is TCP 443 de poort voor deze servicegroepen. Bronbeperking voor Dubai: Beide bevroren servicetabellen bevatten negen regioregels, maar de gedeelde cellen voor poort en doel beslaan slechts acht regels (rowspan=8); de Dubai-cellen zijn leeg. Het overzicht hierboven kent TCP 443 toe op servicegroepniveau, niet als expliciet ingevulde UAE-poortwaarde. De doelen voor Dubai zijn gedocumenteerd, maar de regionale poort blijft in deze tabellen onduidelijk. Verduidelijk dit via de gecontroleerde reconciliatie voordat UAE-toegang wordt toegestaan; hier wordt geen ontbrekende celwaarde ingevuld en geen getest productgedrag geclaimd.

De egress-allowlist veilig opbouwen

Maak de regel op het apparaat dat het uitgaande systeemverkeer werkelijk filtert. Dat kan een upstreamfirewall, providerrouter of cloudnetwerkfirewall zijn. Gebruik alleen het WAN-adres van Sophos Firewall als bron, precies zoals het filterapparaat dit vóór of na een eventuele vertaling ziet. Gebruik de benodigde FQDN’s als doelen en uitsluitend de gedocumenteerde TCP- of UDP-poorten als services.

Wildcards en dynamische IP-adressen correct behandelen

Veel Sophos-services gebruiken CDN’s, cloudplatforms of regionaal verdeelde hosts. De IP-adressen achter een FQDN kunnen wijzigen. Eén nslookup, gevolgd door vaste IP-vermeldingen en een jarenlang ongewijzigde allowlist, is daarom niet betrouwbaar.

Als het upstreamfilter FQDN- of URL-gebaseerde regels ondersteunt, onderhoud dan daar de namen uit de goedgekeurde snapshot. Als het apparaat alleen IP-adressen kan filteren, is een gedocumenteerd proces voor regelmatige resolutie en updates nodig. Alle AWS- of Sophos-netwerken breed toestaan is geen gelijkwaardige vervanging en vergroot het toegestane aanvalsoppervlak onnodig.

Wees bijzonder voorzichtig met *.sophos.com: in de snapshot hoort deze brede wildcard alleen bij Central Firewall Management. Breid hem niet uit naar andere functies of extra poorten. RED, updates, sandbox, licenties en Support Access hebben beperktere doelpatronen.

Geen inkomende WAN-regel maken

Deze verbindingen beginnen op de firewall en gaan naar buiten. Maak hiervoor geen inkomende DNAT- of WAN-to-Local-regel. Voeg ook niet op vermoeden een brede uitzondering voor TLS Inspection, IPS of Web Filtering toe. Controleer eerst DNS, route, upstreamblokkade en de concrete service.

Support Access wordt gemakkelijk verkeerd begrepen: de firewall verbindt uitgaand via TCP 22 met *.apu.sophos.com. De veilige werkwijze om dit in te schakelen en in tijd te beperken staat in Sophos Firewall Support Access configureren.

Fouten systematisch afbakenen

DNS, route en poort afzonderlijk controleren

Onder Diagnostics > Tools > Name lookup kan eerst een doelnaam uit de snapshot worden opgelost zonder de configuratie te wijzigen. Lookup using all configured servers laat zien of de ingestelde resolvers verschillend antwoorden of opvallend lang nodig hebben. Als alternatief kan de bekende Device Console-query worden gebruikt:

dnslookup host xg-up2date-firmwares.sophosupd.com

Onder Diagnostics > Packet capture toont een beperkte capture daarna of de firewall een verbinding naar het opgeloste adres start, welke WAN-interface hij gebruikt en of antwoorden terugkomen. Beperk het Display filter tot het concrete doel-IP en de poort. De status Generated identificeert pakketten die door de firewall zelf zijn gemaakt. Zoek parallel in het upstreamsysteem naar hetzelfde tijdvenster, dezelfde bron en bestemming. Schakel de capture na de test uit; de buffer is beperkt en vervangt geen permanente logging.

Interpreteer het resultaat per laag:

• Geen DNS-antwoord: controleer DNS-server, route naar de resolver en systeemtijd.
• SYN verlaat de firewall, maar er komt geen antwoord terug: controleer upstreamregel, providerpad, NAT en retourpad.
• TCP of UDP werkt, maar de functie blijft defect: controleer het passende servicelog en de productstatus; alleen netwerkconnectiviteit is geen volledig functiebewijs.
• Slechts één HA-node toont de fout: controleer logs en capture op de node die de verbinding tijdens de fout verwerkte.

Het passende SFOS-servicelog gebruiken

Voor updates zijn u2d.log en up2date_av.log goede beginpunten; voor licenties licensing.log, voor RED red.log, voor sandbox sandboxd.log en voor Sophos Fusion onder andere centralmanagement.log, sophos-central.log en de fwcm-*.log-bestanden. Voor NTP past ntpclient.log. De volledige toewijzing en veilige export staan in Sophos Firewall-servicelogs vinden en interpreteren.

Bij HA staan servicelogs op de node die de verbinding heeft verwerkt. Een geslaagde test op de huidige Primary bewijst achteraf niet dat de andere node tijdens de fout dezelfde verbinding had. Leg daarom tijd, node, doelnaam, opgelost IP en poort samen vast.

De wijziging valideren en beheren

Herhaal na een nieuwe egressregel niet alleen de poorttest. De werkelijke functie moet zichtbaar slagen: een pattern toont een nieuwe status, de licentie synchroniseert, RED verbindt, Sophos Fusion ontvangt de taak, een rapport verschijnt of Support Access toont een actieve sessie.

Laat logging op de upstreamregel actief en controleer deze na enkele dagen. Verwijder ongebruikte regio’s en tijdelijk brede testregels.

De firewallbeheerder beoordeelt de snapshot minstens elk kwartaal en vóór firmware-upgrades, bij activering van een nieuwe Sophos-functie, na een regiowijziging, na een relevante fabrikantmelding en tijdens onopgeloste verbindingsincidenten. In die concrete reconciliatiestap opent de beheerder de veranderlijke pagina Default services en registreert datum, SFOS-build, reviewer en diff met de interne snapshot.

Koppel elke toegevoegde, gewijzigde of verwijderde vermelding aan een actieve functie, regio en poort. Pas toevoegingen per functiegroep toe in een onderhoudsvenster en valideer ze met DNS, Packet Capture, upstreamlog en functietest. Verwijder een doel niet alleen omdat het uit de diff verdwijnt: controleer eerst het gebruik in het regellog, schakel daarna het oude object uit en bewaak het gedurende een vastgelegde observatieperiode. Als validatie mislukt, draai de wijziging terug en behoud de vorige snapshot als goedgekeurde versie. Alleen een geslaagde test levert een nieuwe gedateerde snapshot op.

Onverwachte bijwerkingen terugdraaien

Exporteer of bewaar de bestaande upstreamregelset voordat u de wijziging uitvoert. Als er daarna onverwachte verbindingen of andere bijwerkingen optreden, schakel dan alleen de nieuwe regel uit of herstel het laatst gedocumenteerde bereik van doelen en poorten. Test vervolgens zowel de oorspronkelijk getroffen functie als een onafhankelijke normale internetverbinding opnieuw. Zo kan worden vastgesteld of de allowlist de bijwerking veroorzaakte zonder tegelijk andere regels te wijzigen.

Succescriterium: DNS-resolutie, uitgaande verbindingsopbouw, de passende upstream-allowlist en de functietest slagen samen. Ontbreekt een laag, dan is het probleem nog niet correct opgelost.

Veelgestelde vragen