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 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.
⚠️ Les noms de destination constituent une liste évolutive du fabricant. L’aperçu suivant correspond à la documentation publique SFOS 22 du 21 août 2026. Avant de créer une allowlist de production, vérifier à nouveau la page Sophos actuelle Default services. Les adresses IP fixes issues d’une seule résolution DNS ne remplacent pas durablement les FQDN et wildcards documentés.
Contrôle rapide lorsqu’un service Sophos ne fonctionne pas
- Noter la fonction concernée, l’heure de l’erreur et le build SFOS actuel.
- Vérifier que le pare-feu résout le nom de destination documenté par DNS et que l’heure système et la synchronisation NTP sont correctes.
- 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.
- Autoriser uniquement le groupe fonctionnel manquant, et non
*.sophos.com,Anyet tous les ports de manière générale. - 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 résume les groupes principaux. Pour les services régionaux de Sophos Central, 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 de toutes les destinations S3 d’Oregon, Mumbai, Sydney et Tokyo.
| Fonction | Destinations documentées | Ports | Symptôme typique |
|---|---|---|---|
| Catégorisation Web et réputation IP | 4.sophosxl.net | TCP 443 | Les catégories ou la réputation ne sont pas évaluées avec des données actuelles. |
| Mises à jour firmware, patterns et clients | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware ou patterns restent bloqués pendant la recherche ou le téléchargement. |
| Scanner antivirus supplémentaire pour petites appliances | oem.avdl.ctmail.com | TCP 80 | Les mises à jour antivirus supplémentaires échouent. |
| Licences | *.soa.sophos.com | TCP 443 | L’activation ou la synchronisation de licence échoue. |
| Provisionnement RED | *.astaro.com | TCP 3400, UDP 3410 | L’appareil RED ne s’enregistre pas ou n’établit pas de tunnel. |
| Security Heartbeat et Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, les hôtes régionaux *.upe.p.hmr.sophos.com documentés par Sophos et *.sophos.com pour Central Firewall Management | TCP 80, 443 ; Central Firewall Management utilise aussi TCP 22 | Enregistrement, Heartbeat, Synchronized Application Control ou gestion Central reste hors ligne. |
| Central Firewall Reporting | hôte régional tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com | TCP 443 | Les journaux et rapports n’apparaissent pas dans Central. |
| Central Firewall Backup | hôte régional <region>-firewall-backup.s3.<region>.amazonaws.com ; pour UAE, Sophos documente *.s3.me-central-1.amazonaws.com | TCP 443 | La sauvegarde ou restauration Central n’atteint pas le stockage. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Les fichiers ne sont pas envoyés à la sandbox ou les résultats manquent. |
| Support Access | *.apu.sophos.com | TCP 22 | Le tunnel de support sortant ne peut pas être établi. |
| NTP | pool.ntp.org | UDP 123 | L’heure dérive ; certificats, MFA, Kerberos ou journaux paraissent incohérents. |
| SAR, télémétrie et contrôle DDNS | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443 ; le contrôle DDNS utilise TCP 80 | Security Audit Report, télémétrie ou détection de l’IP publique ne fonctionne pas. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | Le chemin de données ZTNA ou la connexion à Sophos Central échoue. |
Sophos indique également certains hôtes Heartbeat et Central précis. Ces valeurs peuvent changer selon la région, l’exploitation de la plateforme ou les modifications du fabricant. Le tableau n’est donc pas transformé en liste IP statique.
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. Sur ce système, utiliser uniquement l’adresse publique ou traduite de Sophos Firewall comme source. 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 documentés par Sophos. 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 : Sophos cite explicitement ce wildcard large pour Central Firewall Management. Ne pas l’étendre automatiquement à 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
Dans la Device Console, commencer par un contrôle en lecture seule d’un nom de destination documenté :
dnslookup host xg-up2date-firmwares.sophosupd.com
Un Packet 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 capture à l’IP de destination et au port précis. Rechercher parallèlement dans le système upstream la même fenêtre temporelle, source et destination.
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 Central, 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, Central 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 régions inutilisées, anciens noms de destination et règles de test temporairement larges. Avant les mises à niveau firmware ou l’activation de nouvelles fonctions Sophos, comparer à nouveau la liste Default services actuelle afin de ne pas découvrir la dépendance pendant la maintenance.
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.