Publication d'un serveur via DNAT sur Sophos Firewall

Avec DNAT, vous publiez un serveur interne via une adresse IP ou un port public. Le Sophos Firewall transfère ensuite le trafic entrant vers le serveur de destination interne. Des exemples typiques sont les serveurs Web, les proxys inverses, les passerelles VPN ou d’autres services dans une DMZ.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

L’article explique les points à vérifier avant et après la création d’une règle DNAT et comment sécuriser la publication avec le périmètre le plus restreint possible.

Planifier avant de publier

Avant la publication de DNAT, il convient de déterminer clairement si le service doit réellement être accessible au public et quelle variante technique est la mieux adaptée. Une bonne planification évite les ports ouverts, les règles NAT en double et les chemins de retour difficiles à tracer.

Exigences

• Adresse IP publique ou interface WAN
• Serveur interne avec adresse IP fixe
• Service et port connus, par exemple TCP 443
• Règle de pare-feu appropriée
• En option : IPS, Web Server Protection ou Reverse Proxy selon le service

⚠️ DNAT publie un service interne vers l’extérieur. Chaque service publié augmente la surface d’attaque. Seul ce qui est réellement nécessaire doit être publié. La source, le port et la destination doivent être aussi étroits que possible.

Clarifier à l’avance

Avant de créer la règle, il faut répondre à ces questions:

• Quelle interface publique IP ou WAN est utilisée ?
• Quel port externe doit être accessible ?
• Vers quelle adresse IP interne est redirigé ?
• Le port reste-t-il le même ou est-il traduit ?
• L’accès doit-il être autorisé de partout ou seulement à partir de certains réseaux sources ?
• Faut-il prendre en compte le Source NAT ou le Reflexive NAT ?
• Est-il nécessaire d’avoir une règle de bouclage pour les clients internes utilisant le nom de domaine complet public ?
• Un seul serveur interne sera-t-il publié ou plusieurs serveurs avec équilibrage de charge ?
• Existe-t-il déjà une règle qui utilise le même port ?
• Le pare-feu Sophos est-il situé directement sur Internet ou derrière le routeur d’un fournisseur ?
• Des règles supplémentaires doivent-elles être ouvertes dans un groupe de sécurité Cloud ?

Ces informations évitent les conflits ultérieurs avec les règles NAT ou de pare-feu existantes.

Si les termes Original source, Original destination, Translated destination, Translated service, Loopback ou Reflexive Rule ne sont toujours pas clairs, vous devez d’abord lire Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT. Cette page se concentre sur la publication spécifique d’un service interne.

DNAT, WAF, VPN ou ZTNA ?

Tous les services accessibles au public ne devraient pas être automatiquement publiés via DNAT. DNAT est techniquement simple, mais aussi très direct : le pare-feu redirige un port vers une destination interne. La pertinence de cette approche dépend du service, des sources et du besoin de protection.

• Service non HTTP avec des sources clairement définies: DNAT avec restriction stricte des sources, journalisation et IPS.
• Application publique HTTP ou HTTPS: vérifiez d’abord Sophos Firewall WAF.
• Accès administrateur tel que SSH ou RDP: Pour quelques cibles fixes, utiliser Clientless SSL VPN ; sinon, préférer VPN, ZTNA ou une IP source fixe à un DNAT ouvert.
• Accès uniquement pour quelques partenaires ou sites: Préférer une connexion IP source, VPN ou site à site.
• L’application doit être accessible en interne et en externe sous le même nom: Vérifiez le DNS divisé ou la règle de bouclage délibérément planifiée.

Pour les applications Web classiques, WAF constitue souvent un meilleur point de départ car les noms d’hôtes, les certificats, les chemins, les profils de protection Web et éventuellement l’authentification peuvent être pris en compte. DNAT ne doit être utilisé pour un accès administratif que dans des cas exceptionnels. Si un service interne n’a pas vraiment besoin d’être public, un VPN ou une architecture ZTNA sont généralement une solution plus propre. Les bases de ZTNA existantes sont disponibles dans Comment configurer Sophos ZTNA et Créer une passerelle Sophos ZTNA.

Si le pare-feu est derrière un routeur

DNAT fonctionne également si le pare-feu Sophos ne dispose pas directement de l’adresse IP publique, mais se trouve derrière un routeur NAT du fournisseur.

Dans ce cas deux redirections sont nécessaires :

1. Sur le routeur du fournisseur, le port public est redirigé vers l’adresse IP WAN du Sophos Firewall.
2. Sur le pare-feu Sophos, le port est transmis au serveur interne via DNAT.

De nombreux routeurs fournisseurs proposent une redirection de port classique ou une fonction telle que Exposed Host ou DMZ Host. Avec une fonction d’hôte exposée, la plupart ou la totalité des ports entrants sont souvent transmis au pare-feu. Cela peut être pratique, mais doit être soigneusement sécurisé car le contrôle réel repose alors entièrement sur le pare-feu Sophos.

S’il n’y a pas d’adresse IP publique fixe, vous pouvez utiliser DynDNS. Sophos Firewall peut configurer le DNS dynamique afin qu’un nom DNS pointe toujours vers l’adresse IP publique actuelle. C’est toujours important : la redirection de port sur le routeur du fournisseur doit pointer vers le pare-feu Sophos.

Avec une adresse IPv4 publique supplémentaire sur un segment WAN directement connecté, la résolution ARP en amont peut encore manquer. La procédure séparée pour configurer Proxy ARP sur Sophos Firewall ne convient que si une capture prouve la requête et l’absence de réponse du pare-feu ; le DNAT ne nécessite pas systématiquement cette étape manuelle.

Le même principe s’applique dans les environnements cloud. Avec Azure, la règle DNAT sur le pare-feu Sophos ne suffit pas à elle seule. De plus, les règles entrantes appropriées doivent être ouvertes dans le groupe de sécurité réseau, sinon le trafic n’atteindra pas du tout le pare-feu.

Configurer DNAT et la règle de pare-feu

Une publication de serveur se compose toujours de deux parties : la règle NAT traduit la destination ou le port, la règle de pare-feu autorise et contrôle le trafic.

Server Access Assistant ou règle DNAT manuelle ?

Sophos Firewall propose deux manières de publier des serveurs :

• Server access assistant (DNAT): convient comme cas standard rapide pour une publication unique. L’assistant crée automatiquement plusieurs règles et les place en haut de la base de règles.
• Règle DNAT manuelle: convient aux environnements plus complexes avec Alias IP, PAT, Load Balancing, sources spécifiques ou design de règles volontaire. Chaque champ doit être défini et testé manuellement.

L’assistant peut être utile car il crée non seulement une règle DNAT entrante, mais, en fonction de la sélection, il crée également une règle de bouclage, une règle SNAT réflexive et la règle de pare-feu appropriée. Cela fait gagner du temps, mais ne remplace pas la vérification des règles créées.

Utiliser le Server Access Assistant

L’assistant est le chemin le plus rapide vers une première publication. Il est particulièrement utile lorsqu’un seul serveur interne doit être joignable via une adresse WAN et un service clair.

Procédure:

1. Ouvrir Rules and policies > NAT rules.
2. Sélectionner IPv4 ou IPv6.
3. Sélectionner Add NAT rule > Server access assistant (DNAT). Il est aussi possible de lancer l’assistant sous Rules and policies > Firewall rules > Add firewall rule.
4. Sous Internal server IP address, sélectionner le serveur interne ou saisir une adresse IP.
5. Sous WAN IP address, sélectionner l’interface WAN ou l’adresse IP publique.
6. Sous Services, sélectionner le service interne, par exemple HTTPS.
7. Sous External source networks and devices, définir les sources autorisées. Pour les services publics, Any n’est adapté que si le service doit vraiment être accessible depuis tout Internet.
8. Vérifier les règles et enregistrer avec Save and finish.

L’assistant active directement les règles créées et les place en haut des tables NAT et firewall. C’est précisément pour cela qu’une revue est nécessaire après l’enregistrement. Une règle créée automatiquement peut fonctionner techniquement tout en étant trop large, placée trop haut ou mal nommée pour l’exploitation.

Pour qu’une règle Loopback soit créée automatiquement, une interface firewall doit être sélectionnée comme destination WAN. Si une IP publique est saisie à la place, l’assistant ne crée pas automatiquement la même logique Loopback. Dans beaucoup d’environnements, Split DNS reste de toute façon plus lisible que Loopback NAT.

Après avoir utilisé l’assistant, vous devez toujours vérifier :

• Les règles NAT et pare-feu sont-elles correctement positionnées ?
• La source est-elle vraiment aussi étroite que prévu ou est-elle toujours à Any ?
• Une règle de bouclage a-t-elle été créée même si Split DNS serait une solution plus propre ?
• Une règle réflexive a-t-elle été créée qui n’est pas nécessaire pour le trafic sortant du serveur ?
• La règle de pare-feu correspond-elle à la zone cible après NAT et à l’objet cible public avant NAT ?

Pour les environnements productifs, une règle DNAT nommée manuellement et délibérément placée est souvent plus facile à comprendre. L’assistant est utile pour un démarrage rapide, mais les règles créées appartiennent à la même revue que les règles créées manuellement.

Créer une règle DNAT

Un exemple DNAT manuel typique publie TCP 443 depuis l’extérieur vers un serveur web interne en DMZ. La règle ne traduit que l’adresse cible et, si nécessaire, le port cible. Elle ne remplace pas une règle de firewall.

Procédure :

1. Ouvrir Rules and policies > NAT rules.
2. Sélectionner IPv4 ou IPv6.
3. Sélectionner Add NAT rule > New NAT rule.
4. Définir un Rule name parlant, par exemple DNAT_WEB_DMZ_HTTPS.
5. Choisir Rule position de sorte que les règles DNAT spécifiques soient placées avant les règles générales.
6. Définir Original source sur les sources externes autorisées. N’utiliser Any que pour des services volontairement publics.
7. Définir Original destination sur l’objet WAN host, l’IP publique ou l’interface WAN adaptée.
8. Définir Original service sur le service joignable depuis l’extérieur, par exemple HTTPS.
9. Définir Translated destination (DNAT) sur le serveur interne ou le groupe de serveurs.
10. Laisser Translated service (PAT) sur Original ou définir le port cible interne si un Port Forwarding est nécessaire.
11. Définir consciemment Inbound interface. Pour un accès Internet, il s’agit généralement de l’interface WAN; dans des cas particuliers, Any peut être nécessaire.
12. Pour DNAT vers des serveurs internes, laisser normalement Outbound interface sur Any afin que le routage et la zone cible restent propres.
13. N’activer Loopback, reflexive rule, Load balancing et Health check que s’ils sont fonctionnellement nécessaires.
14. Enregistrer et activer la règle.

Si seules quelques adresses IP sources externes doivent être accessibles, la source d’origine ne doit pas être Any, mais doit être limitée à ces sources.

Pour les publications en production, un objet hôte pour l’adresse IP publique est généralement plus clair que la sélection directe d’une interface WAN. L’objet reste traçable si les interfaces, les adresses alias ou les détails du fournisseur changent ultérieurement.

Comprendre correctement Original et Translated

En ce qui concerne les règles NAT, la distinction entre Original et Traduit est importante.

• Source/destination/service d’origine décrit le trafic tel qu’il arrive au Sophos Firewall.
• Source/destination/service traduit décrit le trafic tel qu’il quitte le pare-feu Sophos après la traduction.

Pour une règle DNAT entrante, cela signifie :

• La destination d’origine est l’adresse IP ou WAN publique du pare-feu.
• Le service d’origine est le port externe auquel le client s’adresse.
• La destination traduite (DNAT) est le serveur interne.
• Service traduit (PAT) est le port interne du serveur cible si le port doit être traduit.
• La source traduite (SNAT) reste généralement à Original avec les règles DNAT normales.

Redirection de port et PAT

La redirection de port est techniquement une traduction de service. Sur le pare-feu Sophos, le service traduit (PAT) est utilisé à cet effet.

Exemple :

• Externe : TCP 20120
• Interne : TCP 22

Le client externe se connecte sur le port 20120, mais le pare-feu Sophos transmet en interne sur le port SSH 22. Cela peut être utile, mais cela ne remplace pas les restrictions d’accès. Changer le port externe peut réduire certains bruits de fond, mais cela ne garantit pas la sécurité du service.

Important : Le protocole doit rester le même. TCP peut être traduit vers un autre port TCP, UDP vers un autre port UDP. TCP vers UDP n’est pas une traduction de port valide.

Si HTTPS est publié, vous devez également vérifier s’il existe des conflits avec WebAdmin ou le portail utilisateur de Sophos Firewall. Par défaut, la console d’administration utilise le port HTTPS 4444, le portail utilisateur utilise le port HTTPS 443. En cas de chevauchements, les ports propres du pare-feu ou les services publiés doivent être clairement séparés.

Planifiez consciemment l’adresse IP source et le chemin de retour

Pour une publication DNAT normale, Source traduite (SNAT) doit généralement rester sur Original. Le serveur interne voit alors la véritable adresse IP source externe. Cette information est importante pour les journaux du serveur, les limites de débit, les mécanismes de protection de type Fail2Ban, les journaux d’application, l’analyse WAF ou reverse proxy et les investigations ultérieures.

SNAT vers le pare-feu ou une adresse interne peut toujours être nécessaire si le chemin de retour ne passe pas autrement par le pare-feu Sophos. Cela est possible, par exemple, si le serveur publié utilise une passerelle par défaut différente, se trouve dans un segment de routage étranger ou présente une situation de routage asymétrique.

La décision doit être prise consciemment :

• La source reste Original: Le serveur voit une véritable adresse IP externe. Le chemin de retour doit passer proprement à travers le pare-feu.
• La source est traduite via SNAT: L’itinéraire de retour est plus facile à contrôler. Le serveur ne voit que le pare-feu ou l’adresse IP SNAT, l’adresse IP réelle du client est perdue dans le journal du serveur.

Si un service fonctionne uniquement avec SNAT, vous ne devez pas vous y tenir et laisser le sujet de côté. Il est préférable de vérifier d’abord si la passerelle, la route, le VLAN, le pare-feu du serveur ou la conception du routage peuvent être corrigés. SNAT peut être une solution de contournement légitime, mais elle rend les analyses ultérieures plus difficiles.

Lors des tests, vous devez toujours vérifier quelle adresse IP source le serveur voit réellement. Si seule l’adresse IP du pare-feu apparaît à la place de l’adresse IP du client externe, il doit être clairement documenté si cela est intentionnel.

Vérifier la règle de pare-feu

Une règle NAT à elle seule n’autorise pas automatiquement le trafic. De plus, une règle de pare-feu appropriée est requise.

Avec DNAT, la vue dans la règle de pare-feu est inhabituelle car le pare-feu doit connaître simultanément l’accès d’origine de l’extérieur et la cible interne traduite.

La règle générale la plus importante :

⚠️ Avec DNAT, la règle de pare-feu utilise la zone cible après NAT, mais le réseau cible avant NAT.

L’ordre de traitement est important : pour le trafic entrant, Sophos Firewall recherche d’abord la règle DNAT correspondante et détermine ainsi la destination traduite. La règle de pare-feu est ensuite évaluée. Pour Destination zone, le pare-feu utilise la zone dans laquelle se trouve la destination traduite. Pour Destination networks, l’objet de destination d’origine de la règle DNAT reste toutefois pertinent.

Configuration typique :

• Zone source: Généralement WAN lorsque l’accès provient d’Internet.
• Réseaux et appareils sources: Aussi limité que possible, par exemple des adresses IP individuelles, des réseaux, des pays ou des groupes.
• Zones de destination: Zone du serveur interne par DNAT, par exemple DMZ ou SERVER.
• Réseaux de destinations: Adresse de destination publique ou objet hôte WAN de Original destination.
• Prestations: Service externe de Original service, c’est-à-dire le port auquel les clients accèdent de l’extérieur.
• Profils de sécurité: En fonction du service, IPS, analyse des logiciels malveillants, politique Web ou autre contrôle approprié
• Journalisation: Activer pour les services publiés

Sans règle de pare-feu adaptée, le trafic est rejeté malgré le DNAT.

Ce point est une source d’erreur courante : si vous entrez le serveur interne comme réseau de destination, même si la règle attend l’objet WAN public, la règle ne correspond pas. La logique exacte est expliquée plus en détail dans l’article Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

L’ordre s’applique également aux règles NAT. Sophos vérifie les règles NAT de haut en bas et utilise la première règle correspondante. Une règle NAT ci-dessus trop générale peut donc empêcher la règle DNAT spécifique de prendre effet.

Les connexions déjà établies conservent leur traduction NAT même si la règle NAT est modifiée par la suite. Après une modification, les tests doivent donc utiliser de nouvelles sessions ou mettre fin proprement aux anciennes connexions, faute de quoi ils risquent encore de refléter l’état précédent.

Options NAT avancées

Ces options ne deviennent pertinentes que lorsque les clients internes utilisent des noms publics, que les chemins de retour doivent être spécifiquement traduits ou que plusieurs serveurs cibles sont impliqués.

Règles NAT de bouclage, réflexives et liées

Sophos Firewall propose plusieurs options NAT qui se confondent facilement :

• Règle de bouclage : utile lorsque les clients internes doivent atteindre un serveur interne via l’adresse IP publique ou le nom DNS public.
• Règle réflexive : crée une règle SNAT miroir vers une règle DNAT afin que le trafic de retour ou certaines directions opposées soient traduits de manière appropriée.
• Règle NAT liée : créée à partir d’une règle de pare-feu et est une règle SNAT liée. Une règle NAT liée n’est pas la même chose qu’une règle DNAT entrante pour un serveur publié.

Pour les publications de serveur classiques, une règle DNAT indépendante ainsi qu’une règle de pare-feu appropriée sont généralement les plus claires. Les règles NAT liées peuvent être utiles si une règle de pare-feu nécessite directement une traduction SNAT spéciale. Cependant, dans les environnements généraux, les règles NAT autonomes et clairement nommées ont tendance à rester plus faciles à comprendre et à maintenir.

Important : Les règles de bouclage et de réflexion sont dérivées de la règle DNAT d’origine. Si la règle DNAT d’origine est modifiée ultérieurement, il convient de vérifier les règles dérivées séparément. Sinon, il peut arriver que l’accès externe ait été correctement ajusté, mais que l’accès de bouclage interne ou le trafic sortant du serveur continue de s’exécuter selon l’ancienne logique.

Ce n’est pas un détail cosmétique. Sophos crée les règles Loopback et reflexive avec une référence au nom et à l’ID de la règle DNAT d’origine, mais les modifications ultérieures de cette règle d’origine ne mettent pas automatiquement à jour les règles dérivées. Après des changements d’IP publique, de serveur cible, de service ou de sources, il faut donc vérifier explicitement les règles associées.

Équilibrage de charge et Health Check

Lorsque plusieurs serveurs internes sont publiés derrière une adresse IP publique, DNAT peut également être utilisé pour l’équilibrage de charge ou le basculement.

Les méthodes possibles sont par exemple :

• Round robin
• First alive
• Random
• Sticky IP
• One-to-one

Si vous souhaitez que le pare-feu détecte si un serveur cible est disponible, un Health check doit être configuré. Sans vérification de l’état, le pare-feu peut également transférer le trafic vers un serveur inaccessible.

Sécurisation et mise en service

Un service publié fait immédiatement partie de la surface d’attaque publique. C’est pourquoi la fermeture de l’accès, la journalisation, les profils de sécurité et une restauration claire font partie de la mise en service.

Planifier la mise en service et la restauration

Une publication DNAT doit être traitée comme un petit changement de production. Dès que la règle est active, le service peut devenir accessible depuis Internet. Avant la mise en service, il faut donc documenter la règle à activer, la méthode de test et la procédure de retour arrière en cas de problème.

Vérifiez avant la mise en ligne :

• Sauvegardez la configuration actuelle du pare-feu ou au moins documentez les règles NAT et de pare-feu concernées.
• Vérifiez les règles NAT existantes pour la même adresse IP publique, le même port externe et la même interface WAN.
• Faites correspondre les règles du routeur du fournisseur, du groupe de sécurité cloud ou du pare-feu en amont avec la configuration Sophos.
• Tenez compte du DNS TTL lorsqu’un nom d’hôte redirige vers l’adresse publiée.
• Préparez une source de test en dehors de votre propre réseau local, par exemple un téléphone mobile, un emplacement externe ou un test de port en ligne contrôlé.
• Définissez les emplacements de journaux attendus : visionneuse de journaux, ID de règle NAT, ID de règle de pare-feu, capture de paquets et journal du serveur.
• Définissez des critères de restauration, par exemple un mauvais service accessible, un serveur qui ne répond pas, une erreur de certificat, un profil de sécurité qui bloque le trafic légitime ou une adresse IP source inattendue sur le serveur.

Une simple restauration implique généralement la désactivation de la nouvelle règle DNAT et de la règle de pare-feu correspondante. Si une ancienne publication a été remplacée, il doit être clair si l’ancienne règle peut être réactivée ou si la redirection de port du fournisseur, le DNS ou la surveillance doivent d’abord être réinitialisés.

Pour les services critiques, il ne faut pas modifier plusieurs choses en même temps. Si le DNS, le routeur fournisseur, la règle NAT, la règle de pare-feu et la configuration du serveur sont ajustés en même temps, une erreur sera difficile à attribuer ultérieurement. Un processus court avec des étapes claires est préférable : préparer, activer, tester en externe, vérifier les journaux, vérifier les serveurs, documenter les résultats.

Restreindre l’accès aussi étroitement que possible

Tous les services publiés ne doivent pas nécessairement être accessibles depuis l’ensemble d’Internet. Si possible, l’accès doit être limité.

Restrictions utiles :

• Autoriser uniquement les adresses IP à source unique.
• Autorisez uniquement les hôtes FQDN connus lorsque l’autre côté utilise des adresses IP dynamiques.
• Autoriser uniquement certains pays.
• Bloquer explicitement certains pays.
• Autoriser l’accès uniquement via VPN.
• Utilisez une solution ZTNA au lieu de la publication directe.

DNAT n’est généralement pas la meilleure solution pour les services administratifs tels que SSH, RDP ou les portails d’administration internes. Si l’accès n’a pas besoin d’être public, VPN ou ZTNA est presque toujours un meilleur choix.

Améliorer la sécurité

Pour les services publiés, vous devez vérifier :

• Le serveur est-il actuellement patché ?
• Existe-t-il une option WAF ou proxy inverse ?
• IPS est-il actif sur la règle du pare-feu ?
• Seuls les ports nécessaires sont-ils ouverts ?
• Le service est-il connecté ?
• Existe-t-il des restrictions en matière de géo-IP, de flux de menaces ou d’IP source ?
• L’AMF est-elle possible s’il s’agit d’un portail ?

Pour les applications Web, Web Server Protection / WAF peut également être utile à la place du DNAT pur.

Bots et flux de menaces

Les ports publics tels que HTTP, HTTPS, SSH ou RDP sont constamment au centre des préoccupations des robots. Dès qu’un port est accessible sur Internet, vous pouvez souvent voir rapidement les tentatives de connexion, les analyses, les tentatives de connexion ou l’exploitation du trafic dans la visionneuse de journaux.

Cela ne signifie pas automatiquement que le serveur est compromis. Mais cela montre que le service fait partie de la surface d’attaque du public. Nous recommandons donc de sécuriser davantage les services publiés avec IPS, la journalisation, les sources restreintes et les flux de menaces tiers.

Les flux de menaces fournissent en permanence au pare-feu des indicateurs actuels de compromission, par exemple des adresses IP ou des domaines malveillants. Cela permet au pare-feu de bloquer les attaquants, botnets ou scanners connus avant qu’ils n’atteignent le service publié.

En savoir plus : Flux de menaces du pare-feu Sophos

Tester

Après avoir enregistré la règle DNAT :

• Test depuis un réseau externe, pas depuis le même LAN
• Vérifiez uniquement le port public attendu, n’analysez pas largement les adresses étrangères
• Vérifiez la visionneuse de journaux pour l’ID de règle de pare-feu et l’ID de règle NAT.
• Comparez la capture de paquets avec la source externe, la destination publique et la destination interne
• Vérifier les journaux du serveur
• Contrôler l’IP source visible sur le système cible

Si le test doit être effectué du LAN interne vers l’IP publique, un NAT en épingle ou une solution DNS interne peut également être nécessaire.

Matrice de test pour les publications DNAT

Un seul test de port suffit rarement pour une publication DNAT en production. Une petite matrice de test est préférable, car elle sépare les chemins autorisés et non souhaités. On voit ainsi non seulement si le service est joignable, mais aussi si les restrictions, la journalisation et le chemin de retour fonctionnent correctement.

Sources de test utiles :

• Source externe autorisée : tester la connexion depuis un réseau mobile, un site externe ou un réseau partenaire vers l’IP publique et le port externe. Les ID attendus de la règle firewall et de la règle NAT doivent apparaître dans Log Viewer.
• Source externe non autorisée : si la publication est limitée à certaines sources, un test depuis une source non autorisée doit échouer volontairement. Sinon, la restriction de source est trop large.
• Client interne avec le nom DNS interne : vérifier que les utilisateurs internes résolvent directement vers l’IP interne du serveur. C’est souvent plus propre que le loopback NAT.
• Client interne avec le FQDN public : ne tester ce cas que si cet accès est réellement nécessaire. S’il échoue, vérifier d’abord le split DNS et ne pas ajouter automatiquement de loopback NAT.
• Serveur cible lui-même : vérifier le journal du serveur, le firewall local, le service écouté, le certificat et l’IP source visible. On voit ainsi si le serveur reçoit l’IP externe réelle ou une adresse SNAT.
• Monitoring ou health check externe : vérifier que le test utilise la même URL, le même port et la même logique de source que la supervision réelle.

Après chaque test, n’évaluer qu’un seul constat : le trafic arrive-t-il sur Sophos Firewall, la règle NAT attendue correspond-elle, la règle firewall attendue correspond-elle, le paquet atteint-il le serveur et une réponse revient-elle ? Si plusieurs choses sont modifiées simultanément, l’erreur suivante devient beaucoup plus difficile à attribuer.

Un test DNAT propre compare trois points de vue :

• Client Externe: La connexion à l’IP publique et au port externe fonctionne ou est délibérément bloquée.
• Pare-feu Sophos: La visionneuse de journaux affiche l’ID de règle de pare-feu et l’ID de règle NAT attendus.
• Serveur interne: Le service voit l’adresse IP source attendue, répond via la passerelle appropriée et enregistre l’accès.

Si une seule de ces perspectives est examinée, les erreurs typiques ne sont pas détectées. Par exemple, un test de port externe réussi ne dit pas encore si la journalisation, l’IPS, les restrictions de source ou les propriétaires de serveur sont correctement documentés.

Dépannage et opérations

Après la mise en service, il ne suffit pas de vérifier si le service est accessible. Log Viewer, NAT Rule ID, Firewall Rule ID, les journaux du serveur et les contrôles réguliers des anciennes publications sont également importants.

Dépannage

Erreurs courantes :

• Règle de pare-feu manquante
• mauvaise adresse IP WAN sélectionnée
• La redirection de port sur le routeur du fournisseur est manquante
• Azure Network Security Group bloque le port
• Le service ne fonctionne pas en interne
• La passerelle du serveur ne pointe pas vers le Sophos Firewall
• La règle NAT est sous une autre qui prend effet préalablement
• La règle de pare-feu utilise le mauvais réseau de destination dans DNAT
• Le port est déjà utilisé par un autre service
• Bouclage manquant lorsque les clients internes utilisent un FQDN public
• Le Health Check est manquant ou incorrect lors de l’utilisation de l’équilibrage de charge
• Les tests s’effectuent depuis le réseau interne et non en externe
• Le serveur cible répond via une passerelle différente
• Un profil de sécurité bloque le trafic, mais n’est pas recherché dans le bon journal

Le Log Viewer est le point de départ le plus important pour les problèmes DNAT. Vous pouvez y voir si le trafic arrive, quelle règle de pare-feu et quelle règle NAT s’appliquent et si le trafic est autorisé ou rejeté. Si le résultat ne correspond pas à ce qui était attendu, La règle du pare-feu Sophos ne s’applique pas : vérifier les causes vous aidera.

Pour un dépannage plus approfondi, vous ne devriez pas simplement examiner le pare-feu Sophos. Si la visionneuse de journaux autorise le trafic et que la capture de paquets montre que les paquets continuent vers le serveur, la cause vient souvent du système cible : pare-feu local, passerelle par défaut incorrecte, service non lié, problème de certificat, application écoutant sur un port différent ou proxy inverse en amont ne répondant pas comme prévu.

Une classification rapide évite de chercher au mauvais endroit :

• Aucun résultat n’apparaît dans Log Viewer : Le trafic n’atteint pas le pare-feu ou la mauvaise IP WAN est utilisée. Vérifier le routeur du fournisseur, le Cloud Security Group, l’IP publique et Packet Capture sur WAN.
• L’ID de règle de pare-feu correspond, mais l’ID de règle NAT manque : La règle NAT ne correspond pas ou se trouve trop bas dans l’ordre. Vérifier Original destination, Original service, l’interface entrante et l’ordre NAT.
• L’ID de règle NAT correspond, mais le service ne répond pas : Le serveur cible ou le chemin retour n’est pas correct. Vérifier le pare-feu du serveur, la passerelle par défaut, le routage et Packet Capture vers le serveur.
• Cela fonctionne depuis l’extérieur, mais pas en interne via le FQDN : Split DNS ou le loopback manque. Vérifier la résolution DNS interne et n’ajouter un loopback que volontairement.
• Après une modification de l’assistant, seule une partie se comporte mal : Une règle loopback ou reflexive dérivée ne correspond plus. Vérifier individuellement les règles NAT et pare-feu générées.

SMTP via DNAT après une mise à niveau vers SFOS 22

Si, après une mise à niveau vers SFOS 22, les e-mails entrants sont sporadiquement livrés en retard ou ne sont pas livrés du tout, NC-184583 peut en être la cause. Sophos indique explicitement que SFOS 22.0 GA Respin Build 411 est concerné, mais décrit plus généralement le problème pour les mises à niveau vers v22.x. MR1 et MR2 ne figurent pas séparément parmi les versions affectées ou corrigées. La seule version indiquée comme corrigée est SFOS 23.0 EAP0 Build 253 – une version EAP qu’il ne faut pas déployer systématiquement sur un système de production. Aucun workaround public n’est documenté ; Sophos renvoie au support.

Un test du port TCP 25 ne suffit pas pour ce type d’incident. Il faut envoyer plusieurs messages réels de manière contrôlée et consigner l’heure UTC, l’expéditeur, le destinataire ainsi que l’identifiant Message-ID. Comparer ensuite la file d’attente ou le bounce côté expéditeur avec la file d’attente et le log de transport du serveur de messagerie interne. Pour le support, le dossier de preuves doit comprendre le build du firmware, les horodatages, les Rule IDs, fwlog.log, firewall_rule.log, nat_rule.log ainsi que les logs du serveur de messagerie. Les chemins des logs et le Consolidated Troubleshooting Report sont décrits dans Vérifier les services et les logs Sophos Firewall via CLI. Lors de l’ouverture d’un dossier auprès du support, NC-184583 doit être mentionné explicitement.

Le Known Issue décrit le chemin DNAT direct vers le serveur de messagerie interne. Avec Sophos Firewall MTA Mode, le pare-feu accepte lui-même le message, puis le transfère. Sophos ne confirme toutefois ni que MTA Mode est assurément exclu, ni que le passage à ce mode constituerait le workaround officiel.

Quand Black Hole DNAT aide aussi

Si un service doit délibérément rester accessible au public, mais que certaines sources doivent être interceptées avant la publication proprement dite, une règle DNAT de trou noir au-dessus de la règle DNAT productive peut avoir du sens. Cela fonctionne, par exemple, pour les mauvaises listes d’adresses IP connues, les pays définitivement indésirables ou les sources de scanner récurrentes.

Cette technique ne remplace pas une publication correctement sécurisée. La règle DNAT de production doit rester strictement limitée, la journalisation doit être active et le serveur publié doit être maintenu à jour. Black Hole DNAT ajoute une couche de blocage en amont de la publication, mais ne constitue pas l’architecture de sécurité elle-même.

Black Hole DNAT est particulièrement utile dans les cas suivants :

• Les sources récurrentes du scanner touchent le même service publié: Les sources ne peuvent aboutir à rien avant la règle productive de la DNAT.

• Les pays individuels ne devraient pas avoir accès à la redirection de port: La règle de blocage peut être placée au-dessus de la règle DNAT réelle.

• Un groupe IP incorrect maintenu existe déjà: Le groupe peut être utilisé comme Original source de la règle du trou noir.

• Un service doit rester public, mais doit générer moins de trafic de robots: La règle productive est conservée, les sources indésirables sont préalablement interceptées

Black Hole DNAT ne convient pas aux services de pare-feu locaux tels que WebAdmin, portail utilisateur, portail VPN ou SSH vers le pare-feu lui-même. L’accès aux appareils et les règles d’exception ACL du service local en sont responsables. Pour les serveurs Web via WAF, vous devez d’abord vérifier la règle WAF, les pays bloqués, l’authentification et les journaux WAF.

L’ordre est important : la règle DNAT du trou noir doit être supérieure à la règle DNAT productive. Vous devez ensuite vérifier dans la visionneuse de journaux si les sources bloquées respectent réellement la règle du trou noir et si les sources autorisées continuent d’utiliser la règle NAT et pare-feu productive. La procédure exacte peut être trouvée dans Sophos Firewall : Bloquer les pays et les adresses IP malveillantes.

Contrôle opérationnel

Les règles DNAT doivent être révisées régulièrement. Les anciennes publications représentent un risque de sécurité fréquent, car les services restent souvent accessibles même après le déplacement, le remplacement ou la fin d’utilisation de l’application.

Pour des règles DNAT productives, les éléments suivants doivent au moins être documentés :

• Objectif de la publication: La documentation doit expliquer pourquoi le service est accessible au public.
• Personne ou équipe responsable: Sans propriétaire, les anciennes publications sont rarement supprimées.
• IP publique et port externe: Facilite les tests, la surveillance et les analyses externes
• Serveur cible interne et port cible: Important pour les migrations de serveurs, l’équilibrage de charge et les modifications de certificats
• Sources attendues: Aide à déterminer si Any est vraiment nécessaire
• Mesures de protection: IPS, alternative WAF, MFA, flux de menaces, journalisation et statut des correctifs doivent être traçables
• Date d’expiration ou date de révision: Les publications temporaires nécessitent une date de fin claire.

Une revue utile ne consiste pas seulement à examiner la règle. Il faut vérifier depuis l’extérieur que seuls les ports attendus sont ouverts, contrôler dans Log Viewer quelles sources accèdent réellement au service et confirmer sur le serveur cible que l’application est toujours maintenue. Si le service n’est nécessaire qu’en interne ou pour quelques partenaires, VPN, ZTNA, une restriction d’IP source ou une règle WAF doivent être réévalués.

Lorsque vous supprimez d’anciennes règles DNAT, vous ne devez pas simplement supprimer la règle NAT. Des règles de pare-feu, des objets hôtes, des objets de service, des règles de bouclage, des règles réflexives, des entrées DNS, des contrôles de surveillance ou des redirections de port de fournisseur y sont souvent attachés. Un processus de déclassement court est préférable :

1. Vérifiez les derniers accès dans la visionneuse de journaux.
2. Demandez à la personne ou au service responsable de confirmer que le service n’est plus requis.
3. Désactivez d’abord la règle NAT et la règle de pare-feu appropriée.
4. Testez en externe si le port est fermé.
5. Vérifiez les journaux de surveillance et du serveur pour détecter les erreurs.
6. Ensuite seulement, nettoyez les objets, les entrées DNS et les règles du fournisseur qui ne sont plus nécessaires.

Si la publication reste nécessaire, la revue doit aboutir à un résultat concret : la conserver en l’état, la restreindre davantage, la migrer vers WAF, la placer derrière VPN/ZTNA ou la réexaminer avant une date d’expiration définie.

FAQ