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.

L’article explique quels points vous devez vérifier avant et après une règle DNAT et comment sécuriser au mieux la libération.

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 édite 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 configurer le système de contrôle, vous devez 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, RDP ou portail d’administration interne: Si possible, VPN, ZTNA ou IP source fixe au lieu de 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.

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 :

• ****Assistant d’accès au serveur (DNAT): boîtier standard rapide pour une seule version. crée automatiquement plusieurs règles et les place en haut de la base de règles.
• Règle DNAT manuelle: environnements plus complexes avec alias IP, PAT, équilibrage de charge, sources spéciales ou conception de règles délibérées. Chaque champ doit être défini et testé vous-même.

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.

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 typique de DNAT :

• Source originale : Any ou réseaux sources définis
• Destination d’origine : interface WAN-IP ou WAN
• Service d’origine : HTTPS
• Destination traduite : serveur interne
• Service traduit : port de destination inchangé ou interne

Procédure :

1. Ouvrez Règles et politiques.
2. Accédez à la zone Règles NAT.
3. Sélectionnez Ajouter une règle NAT > Nouvelle règle NAT.
4. Définissez la source, la destination et le service d’origine.
5. Définissez Destination traduite sur le serveur interne.
6. Définissez éventuellement le service traduit.
7. Vérifiez consciemment l’interface entrante et sortante.
8. Enregistrez et activez 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 partages de production, un objet hôte pour l’adresse IP publique est généralement plus propre 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 l’original et traduire correctement

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 version DNAT normale, Source traduite (SNAT) doit généralement rester sur Original. Ensuite, le serveur interne voit la véritable adresse IP source externe. Ceci est important pour les journaux du serveur, les limites de débit, les mécanismes de protection de type Fail2Ban, les journaux d’applications, l’évaluation WAF ou proxy inverse et l’analyse ultérieure des incidents.

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.

Mission type :

• 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.

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.

Équilibrage de charge et bilan de santé

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 :

• Tournoi à la ronde
• Premier vivant
• Aléatoire
• IP collante
• En tête-à-tête

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.

Couverture 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 version DNAT doit être traitée comme un petit changement de production. Dès que la règle est active, le service est accessible depuis Internet. Par conséquent, avant la mise en service, il convient de préciser quelle règle sera activée, comment l’accès sera testé et comment revenir en 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, vous ne devez pas seulement vérifier si le service est accessible. Les visionneuses de journaux, l’ID de règle NAT, l’ID de règle de pare-feu, les journaux du serveur et les révisions régulières des anciennes versions sont 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 bilan de santé 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.

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 libération propre. La règle DNAT productive doit toujours être stricte, la journalisation doit être active et le serveur publié doit être tenu à jour. Black Hole DNAT est une couche de bloc supplémentaire avant une version, et non l’architecture de sécurité réelle.

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 de la DNAT doivent être révisées régulièrement. Les anciennes versions représentent un risque de sécurité typique, car les services publiés restent souvent accessibles même si l’application a été déplacée, remplacée depuis longtemps ou n’est nécessaire que temporairement.

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

• Objectif de la diffusion: Plus tard, il faudra comprendre pourquoi le service est accessible au public
• Personne ou équipe responsable: Sans propriétaire, les anciennes actions 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 libérations temporaires nécessitent une fin claire

Une révision significative ne consiste pas seulement à examiner la règle. Vous devez vérifier en externe si seuls les ports attendus sont ouverts, vérifier dans la visionneuse de journaux à quelles sources accèdent réellement et vérifier sur le serveur cible si l’application est toujours en cours de maintenance. Si le service n’est nécessaire qu’en interne ou pour quelques partenaires, un VPN, un ZTNA, une restriction 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 l’autorisation est toujours requise, l’examen doit se terminer par une conclusion concrète : laissez-le tel quel, restreignez-le plus étroitement, passez à WAF, déplacez-le derrière VPN/ZTNA ou réexaminez-le avec une date d’expiration.

FAQ