Vérifier les services et ports sortants de Sophos Firewall

Sophos Firewall établit lui-même des connexions vers Sophos et certains services de plateforme externes. Il les utilise pour télécharger firmware et patterns, synchroniser les licences, connecter les appareils RED, envoyer des rapports à Sophos Fusion (anciennement Sophos Central) ou ouvrir Support Access. Si un autre routeur, proxy ou filtre egress se trouve en amont, certaines fonctions peuvent échouer alors que le trafic client normal continue de fonctionner.

La distinction essentielle est qu’il s’agit de trafic système généré par le pare-feu lui-même. Une règle LAN-to-WAN large ajoutée sur Sophos Firewall ne corrige pas un filtre en amont. Il faut une autorisation sortante ciblée sur le système upstream qui bloque réellement la connexion.

⚠️ Référence de travail contrôlée par Avanet : L’aperçu ci-dessous est le snapshot interne daté du 4 septembre 2026 pour SFOS 22. Il sert de base à la planification et à la recette ; les noms de destination peuvent ensuite changer. Des IP fixes issues d’une seule résolution DNS ne remplacent pas les FQDN et wildcards. Le responsable du pare-feu suit la réconciliation décrite plus bas avant de modifier le snapshot.

Contrôle rapide lorsqu’un service Sophos ne fonctionne pas

1. Noter la fonction concernée, l’heure de l’erreur et le build SFOS actuel.
2. Vérifier que le pare-feu résout le nom de destination du snapshot par DNS et que l’heure système et la synchronisation NTP sont correctes.
3. Sur le routeur ou filtre egress en amont, rechercher un blocage visant l’adresse WAN du pare-feu, le FQDN de destination et le port requis.
4. Autoriser uniquement le groupe fonctionnel manquant, et non *.sophos.com, Any et tous les ports de manière générale.
5. Déclencher exactement un nouveau test et comparer Packet Capture, le journal upstream et le journal de service SFOS correspondant selon l’heure.

Une résolution DNS réussie prouve uniquement que le nom peut être résolu. Un handshake TCP réussi ne prouve pas encore que licence, mise à jour, upload ou provisionnement RED fonctionnent de bout en bout. Après la modification réseau, tester à nouveau la fonction réelle.

Destinations et ports requis par SFOS 22

Le tableau est le snapshot approuvé pour la planification initiale. Ne sélectionner que les groupes fonctionnels actifs sur le pare-feu concerné ou prévus pour un déploiement planifié. Pour les services régionaux de Sophos Fusion, n’autoriser que la région réellement utilisée. Une organisation dans la région de Francfort n’a par exemple pas automatiquement besoin des destinations S3 d’Oregon, Mumbai, Sydney et Tokyo.

utm.cloud.sophos.com/api/utm est une URL avec un chemin, et non un FQDN. Si le produit upstream n’accepte qu’un FQDN comme destination, saisir uniquement l’hôte utm.cloud.sophos.com ; /api/utm n’a pas sa place dans un objet FQDN. Le snapshot contient des hôtes upe.p.hmr.sophos.com précis pour Heartbeat et Sophos Fusion, et non une autorisation portant sur tout le domaine wildcard. Ces noms peuvent changer avec l’exploitation de la plateforme et ne sont mis à jour que par la réconciliation contrôlée. De même, pool.ntp.org ne s’applique que si la destination NTP par défaut est utilisée ; si un autre serveur NTP est configuré, autoriser plutôt cette destination.

Choisir les destinations régionales des rapports et sauvegardes

Commencer par confirmer la région réellement utilisée par chaque service dans l’environnement Sophos Fusion. L’emplacement de l’entreprise ne suffit pas à la déterminer. Si la correspondance est incertaine, identifier la destination d’un envoi de rapports ou d’une sauvegarde avec Packet Capture et le journal upstream, puis la clarifier avant toute autorisation. Cette liste est un catalogue, et non une allowlist globale : ne retenir que les destinations nécessaires à la région et à la fonction utilisées. CFR envoie les rapports et journaux ; la sauvegarde permet d’enregistrer et de restaurer la configuration du pare-feu.

• États-Unis (Oregon) — us-west-2
  • CFR : tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Sauvegarde : us-west-2-firewall-backup.s3.us-west-2.amazonaws.com
• Europe (Francfort) — eu-central-1
  • CFR : tf-presigned-url-eu-central-1-prod-firewall-bucket.s3.eu-central-1.amazonaws.com
  • Sauvegarde : eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europe (Irlande) — eu-west-1
  • CFR : tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Sauvegarde : eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• Est des États-Unis (Ohio) — us-east-2
  • CFR : tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Sauvegarde : us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Asie-Pacifique (Mumbai) — ap-south-1
  • CFR : tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Sauvegarde : ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Asie-Pacifique (Tokyo) — ap-northeast-1
  • CFR : tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Sauvegarde : ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Canada (Centre) — ca-central-1
  • CFR : tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Sauvegarde : ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Asie-Pacifique (Sydney) — ap-southeast-2
  • CFR : tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Sauvegarde : ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Émirats arabes unis (Dubaï) — me-central-1
  • CFR : tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Sauvegarde : *.s3.me-central-1.amazonaws.com — l’exception documentée, et non une base pour inventer un hôte de sauvegarde unique.

Pour les huit premières régions, TCP 443 est le port de ces groupes de services. Limite de la source pour Dubaï : Les deux tableaux de services figés comportent neuf lignes régionales, mais les cellules communes de port et de finalité ne couvrent que huit lignes (rowspan=8) ; celles de Dubaï sont vides. L’aperçu ci-dessus associe TCP 443 au groupe de services, et non à une valeur de port explicitement renseignée pour UAE. Les destinations de Dubaï sont documentées, mais leur port régional reste ambigu dans ces tableaux. Le clarifier par la réconciliation contrôlée avant d’autoriser l’accès à UAE ; aucune valeur manquante n’est complétée ici et aucun comportement du produit n’est présenté comme testé.

Construire l’allowlist egress en toute sécurité

Créer la règle sur l’appareil qui filtre réellement le trafic système sortant. Il peut s’agir d’un pare-feu en amont, d’un routeur opérateur ou d’un pare-feu réseau cloud. Utiliser uniquement comme source l’adresse WAN de Sophos Firewall telle que l’appareil de filtrage la voit, avant ou après une éventuelle traduction. Les destinations sont les FQDN nécessaires et les services uniquement les ports TCP ou UDP documentés.

Traiter correctement wildcards et adresses IP dynamiques

De nombreux services Sophos utilisent des CDN, plateformes cloud ou hôtes distribués régionalement. Les adresses IP derrière un FQDN peuvent changer. Un unique nslookup, suivi d’IP fixes et d’une allowlist inchangée pendant des années, n’est donc pas fiable.

Si le filtre upstream prend en charge des règles FQDN ou URL, y maintenir les noms du snapshot approuvé. Si l’appareil ne filtre que des IP, mettre en place un processus documenté de résolution et de mise à jour régulière. Autoriser largement tous les réseaux AWS ou Sophos n’est pas un substitut équivalent et augmente inutilement la surface autorisée.

Traiter *.sophos.com avec une attention particulière : dans le snapshot, ce wildcard large appartient uniquement à Central Firewall Management. Ne pas l’étendre à d’autres fonctions ou ports. RED, mises à jour, sandbox, licences et Support Access disposent de modèles de destination plus étroits.

Ne pas créer de règle WAN entrante

Ces connexions partent du pare-feu vers l’extérieur. Ne pas créer de règle DNAT ou WAN-to-Local entrante. De même, ne pas ajouter par supposition une exemption large de TLS Inspection, IPS ou Web Filtering. Vérifier d’abord DNS, route, blocage upstream et service précis.

Support Access est particulièrement facile à mal interpréter : le pare-feu se connecte en sortie via TCP 22 à *.apu.sophos.com. La procédure sûre d’activation et de limitation temporelle figure dans Configurer Sophos Firewall Support Access.

Isoler les erreurs méthodiquement

Vérifier séparément DNS, route et port

Sous Diagnostics > Tools > Name lookup, commencer par résoudre un nom de destination du snapshot sans modifier la configuration. Lookup using all configured servers permet de voir si les résolveurs configurés répondent différemment ou prennent un temps anormal. Il est également possible d’utiliser la requête Device Console habituelle :

dnslookup host xg-up2date-firmwares.sophosupd.com

Sous Diagnostics > Packet capture, un capture ciblé montre ensuite si le pare-feu démarre une connexion vers l’adresse résolue, quelle interface WAN il utilise et si des réponses reviennent. Limiter le Display filter à l’IP de destination et au port précis. Le statut Generated identifie les paquets créés par le pare-feu lui-même. Rechercher parallèlement dans le système upstream la même fenêtre temporelle, source et destination. Arrêter le capture après le test : son buffer est limité et ne remplace pas une journalisation permanente.

Interpréter le résultat par couche :

• Aucune réponse DNS : vérifier serveur DNS, route vers le résolveur et heure système.
• Le SYN quitte le pare-feu, mais aucune réponse ne revient : vérifier règle upstream, chemin opérateur, NAT et retour.
• TCP ou UDP fonctionne, mais la fonction échoue toujours : vérifier le journal de service correspondant et l’état du produit ; la connectivité seule n’est pas une preuve fonctionnelle complète.
• Un seul nœud HA montre l’erreur : vérifier journaux et capture sur le nœud ayant traité la connexion au moment de l’erreur.

Utiliser le journal de service SFOS adapté

Pour les mises à jour, u2d.log et up2date_av.log sont de bons points de départ ; pour les licences, licensing.log ; pour RED, red.log ; pour la sandbox, sandboxd.log ; et pour Sophos Fusion, entre autres, centralmanagement.log, sophos-central.log et les fichiers fwcm-*.log. Pour NTP, utiliser ntpclient.log. La correspondance complète et l’export sûr figurent dans Trouver et interpréter les journaux de service Sophos Firewall.

En HA, les journaux de service se trouvent sur le nœud ayant traité la connexion. Un test réussi sur le Primary actuel ne prouve pas rétrospectivement que l’autre nœud disposait de la même connexion lors de l’erreur. Consigner ensemble heure, nœud, nom de destination, IP résolue et port.

Valider et exploiter la modification

Après l’ajout d’une règle egress, ne pas seulement répéter le test du port. La fonction réelle doit afficher un succès visible : un pattern change d’état, la licence se synchronise, RED se connecte, Sophos Fusion reçoit la tâche, un rapport apparaît ou Support Access affiche une session active.

Conserver la journalisation de la règle upstream et la contrôler après quelques jours. Supprimer les régions inutilisées et les règles de test temporairement larges.

Le responsable du pare-feu révise le snapshot au moins chaque trimestre, ainsi qu’avant une mise à niveau firmware, lors de l’activation d’une nouvelle fonction Sophos, après un changement de région, après un avis pertinent du fabricant et pendant un incident de connectivité non résolu. À cette étape concrète de réconciliation, il ouvre la page évolutive Default services et consigne date, build SFOS, réviseur et diff avec le snapshot interne.

Chaque entrée ajoutée, modifiée ou supprimée est associée à une fonction active, une région et un port. Appliquer les ajouts groupe par groupe dans une fenêtre de maintenance, puis les valider avec DNS, Packet Capture, journal upstream et test fonctionnel. Ne pas supprimer une destination du seul fait du diff : vérifier d’abord son utilisation dans le journal de règle, puis désactiver l’ancien objet et l’observer pendant une période définie. Si la validation échoue, annuler la modification et conserver l’ancien snapshot approuvé. Seul un test réussi produit un nouveau snapshot daté.

Revenir en arrière en cas d’effet inattendu

Exporter ou sauvegarder autrement la base de règles upstream existante avant la modification. Si des connexions inattendues ou d’autres effets apparaissent ensuite, désactiver uniquement la nouvelle règle ou rétablir son dernier périmètre documenté de destinations et de ports. Tester alors de nouveau la fonction initialement concernée et un accès Internet normal indépendant. Cela permet d’isoler le rôle de l’allowlist sans modifier simultanément d’autres règles.

Critère de réussite : résolution DNS, établissement de la connexion sortante, allowlist upstream correspondante et test fonctionnel réussissent ensemble. Si une couche manque, le problème n’est pas encore proprement résolu.

Questions fréquentes