Aller au contenu
Avanet

Publier un serveur en DNAT sur Sophos Firewall

Sophos Firewall

Avec DNAT, on publie un serveur interne via une adresse IP publique ou un port public. La Sophos Firewall transfère alors le trafic entrant vers le serveur cible interne. Les exemples typiques sont les serveurs web, reverse proxies, passerelles VPN ou autres services dans une DMZ.

Ce guide montre les points à vérifier avant et après une règle DNAT, ainsi que les mesures pour sécuriser l’ouverture le plus strictement possible.

Prérequis

  • Adresse IP publique ou interface WAN
  • Serveur interne avec adresse IP fixe
  • Service et port connus, par exemple TCP 443
  • Règle firewall adaptée
  • Optionnel : IPS, Webserver Protection ou Reverse Proxy selon le service

⚠️ DNAT publie un service interne vers l’extérieur. Chaque service publié augmente la surface d’attaque. Publie uniquement ce qui est réellement nécessaire et limite source, port et cible aussi strictement que possible.

Clarifier avant de commencer

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

  • Quelle IP publique ou interface WAN est utilisée ?
  • Quel port externe doit être accessible ?
  • Vers quelle IP interne le trafic est-il transféré ?
  • Le port reste-t-il identique ou est-il traduit ?
  • L’accès doit-il être autorisé depuis partout ou seulement depuis certains réseaux source ?
  • Faut-il tenir compte de Source NAT ou Reflexive NAT ?
  • Faut-il une Loopback rule pour les clients internes qui utilisent le FQDN public ?
  • Publie-t-on un seul serveur interne ou plusieurs serveurs avec Load Balancing ?
  • Existe-t-il déjà une règle utilisant le même port ?
  • La Sophos Firewall est-elle directement connectée à Internet ou derrière un routeur du fournisseur ?
  • Faut-il ouvrir des règles supplémentaires dans une Cloud Security Group ?

Ces informations évitent des conflits ultérieurs avec des règles NAT ou firewall existantes.

Si la firewall est derrière un routeur

DNAT fonctionne aussi lorsque la Sophos Firewall ne possède pas directement l’adresse IP publique, mais se trouve derrière un routeur NAT du fournisseur.

Dans ce cas, il faut deux redirections :

  1. Sur le routeur du fournisseur, le port public est redirigé vers l’IP WAN de la Sophos Firewall.
  2. Sur la Sophos Firewall, le port est redirigé par DNAT vers le serveur interne.

Beaucoup de routeurs fournisseurs proposent des redirections de ports classiques ou une fonction comme Exposed Host ou DMZ Host. Avec une fonction Exposed Host, de très nombreux ports entrants, voire tous, sont souvent transférés vers la firewall. Cela peut être pratique, mais doit être sécurisé consciemment, car le contrôle réel repose alors entièrement sur la Sophos Firewall.

S’il n’y a pas d’IP publique fixe, on peut utiliser DynDNS. La Sophos Firewall peut configurer Dynamic DNS afin qu’un nom DNS pointe toujours vers l’IP publique actuelle. Point important malgré tout : la redirection de ports sur le routeur du fournisseur doit pointer vers la Sophos Firewall.

Dans les environnements cloud, le principe est identique. Dans Azure, la règle DNAT sur la Sophos Firewall ne suffit pas. Les Inbound rules correspondantes doivent aussi être ouvertes dans la Network Security Group, sinon le trafic n’atteint même pas la firewall.

Créer la règle DNAT

Exemple DNAT typique :

  • Original source: Any ou réseaux source définis
  • Original destination: IP WAN ou interface WAN
  • Original service: HTTPS
  • Translated destination: serveur interne
  • Translated service: inchangé ou port cible interne

Procédure :

  1. Ouvrir Rules and policies.
  2. Aller dans la section NAT rules.
  3. Créer une nouvelle règle NAT.
  4. Définir Original Source, Destination et Service.
  5. Définir Translated Destination sur le serveur interne.
  6. Définir éventuellement Translated Service.
  7. Enregistrer et activer la règle.

Si seules quelques adresses IP source externes doivent accéder au service, Original Source ne doit pas être Any, mais limité à ces sources.

Sophos Firewall - règle DNAT avec IP publique, port externe et serveur cible interne
Sophos Firewall - Rules and policies > NAT rules > DNAT

Bien comprendre Original et Translated

Dans les règles NAT, la distinction entre Original et Translated est importante.

  • Original source / destination / service décrit le trafic tel qu’il arrive sur la Sophos Firewall.
  • Translated source / destination / service décrit le trafic tel qu’il quitte la Sophos Firewall après traduction.

Pour une règle DNAT entrante, cela signifie :

  • Original destination est l’IP publique ou l’adresse WAN de la firewall.
  • Original service est le port externe contacté par le client.
  • Translated destination (DNAT) est le serveur interne.
  • Translated service (PAT) est le port interne sur le serveur cible si le port doit être traduit.
  • Translated source (SNAT) reste généralement sur Original pour les règles DNAT classiques.

Sophos décrit les champs dans le guide officiel Add a NAT rule.

Port Forwarding et PAT

Le Port Forwarding est techniquement une traduction de service. Sur Sophos Firewall, on utilise pour cela Translated service (PAT).

Exemple :

  • Externe : TCP 20120
  • Interne : TCP 22

Le client externe se connecte au port 20120, mais la Sophos Firewall redirige en interne vers le port SSH 22. Cela peut être utile, mais ne remplace pas une restriction d’accès. Un port externe modifié réduit peut-être un peu le bruit de fond, mais ne rend pas un service sûr.

Important : le protocole doit rester identique. 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é, il faut aussi vérifier les conflits avec WebAdmin ou User Portal de la Sophos Firewall. Par défaut, la console admin utilise HTTPS port 4444, le User Portal HTTPS port 443. En cas de recouvrement, les ports propres à la firewall ou les services publiés doivent être séparés proprement.

Loopback, Reflexive et Linked NAT Rules

Sophos connaît plusieurs options NAT faciles à confondre :

  • Loopback rule : utile lorsque des clients internes doivent atteindre un serveur interne via l’IP publique ou le nom DNS public.
  • Reflexive rule : crée une règle SNAT miroir pour une règle DNAT, afin que le trafic retour ou certaines directions opposées soient traduits correctement.
  • Linked NAT rule : créée depuis une règle firewall, c’est une règle SNAT liée. Ce n’est pas la même chose qu’une règle DNAT entrante pour un serveur publié.

Pour les publications de serveurs classiques, une règle DNAT autonome plus une règle firewall adaptée est généralement la solution la plus claire. Les Linked NAT Rules peuvent être utiles lorsqu’une règle firewall nécessite directement une traduction SNAT spécifique. Pour les environnements généraux, Sophos recommande toutefois de garder les règles NAT aussi indépendantes et simples que possible, plutôt que de créer inutilement de nombreuses règles NAT liées par règle firewall.

Load Balancing et Health Check

Si plusieurs serveurs internes sont publiés derrière une IP publique, DNAT peut aussi être utilisé pour du Load Balancing ou du failover.

Méthodes possibles, par exemple :

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

Si la firewall doit détecter si un serveur cible est disponible, un Health check doit être configuré. Sans Health Check, la firewall peut envoyer du trafic vers un serveur non joignable.

Vérifier la règle firewall

Une règle NAT seule n’autorise pas automatiquement le trafic. Il faut aussi une règle firewall adaptée.

La règle firewall doit définir :

  • Source zone: généralement WAN
  • Source network: aussi restreint que possible
  • Destination zone: zone du serveur interne, par exemple DMZ
  • Destination network: serveur interne
  • Services: uniquement les ports nécessaires
  • Security-Profile: selon le service, IPS, Malware Scan ou Web Policy
  • Logging: activé

Sans règle firewall correspondante, le trafic est rejeté malgré DNAT.

Sophos Firewall - règle firewall correspondant à la règle DNAT avec réseaux source restreints
Sophos Firewall - règle firewall correspondant à la règle DNAT

L’ordre compte aussi pour les règles NAT. Sophos vérifie les règles NAT de haut en bas et utilise la première règle qui correspond. Une règle NAT trop générale placée au-dessus peut donc empêcher la règle DNAT spécifique de s’appliquer.

Restreindre l’accès autant que possible

Tous les services publiés n’ont pas besoin d’être accessibles depuis tout Internet. Si possible, il faut limiter l’accès.

Restrictions utiles :

  • Autoriser seulement certaines adresses IP source.
  • Autoriser seulement des FQDN-Hosts connus si la partie distante utilise des IP dynamiques.
  • Autoriser seulement certains pays.
  • Bloquer explicitement certains pays.
  • Autoriser l’accès uniquement via VPN.
  • Utiliser une solution ZTNA au lieu d’une publication directe.

Pour les services administratifs comme SSH, RDP ou des portails admin internes, DNAT n’est généralement pas la meilleure solution. Si l’accès ne doit pas être public, VPN ou ZTNA est presque toujours le meilleur choix.

Informations complémentaires :

Améliorer la sécurité

Pour les services publiés, il faut vérifier :

  • Le serveur est-il à jour ?
  • Existe-t-il une option WAF ou Reverse Proxy ?
  • IPS est-il actif sur la règle firewall ?
  • Seuls les ports nécessaires sont-ils ouverts ?
  • Le service est-il logué ?
  • Existe-t-il des restrictions Geo-IP, Threat Feed ou IP source ?
  • MFA est-elle possible s’il s’agit d’un portail ?

Pour les applications web, Web Server Protection peut être plus approprié qu’un simple DNAT.

Bots et Threat Feeds

Les ports publics comme HTTP, HTTPS, SSH ou RDP sont constamment ciblés par les bots. Dès qu’un port est accessible sur Internet, on voit souvent très vite des tentatives de connexion, des scans, des tentatives de login ou du trafic d’exploit dans le Log Viewer.

Cela ne signifie pas automatiquement que le serveur est compromis. Cela montre toutefois que le service fait partie de la surface d’attaque publique. Nous recommandons donc de protéger les services publiés avec IPS, logging, sources strictes et Third-Party Threat Feeds.

Les Threat Feeds fournissent en continu à la firewall des Indicators of Compromise actuels, par exemple des adresses IP ou domaines malveillants. La firewall peut ainsi bloquer des attaquants, botnets ou scanners connus avant qu’ils n’atteignent le service publié.

Voir aussi : Sophos Firewall Threat Feeds

Test

Après la création de la règle DNAT :

  • Tester depuis un réseau externe, pas depuis le même LAN
  • Vérifier un portscan sur l’IP publique
  • Contrôler le Log Viewer pour les événements NAT et firewall
  • Contrôler les logs du serveur
  • Vérifier si le client voit l’IP source attendue

Si le test depuis le LAN interne vers l’IP publique est nécessaire, Hairpin NAT ou une solution DNS interne peut aussi être nécessaire.

Troubleshooting

Erreurs fréquentes :

  • Règle firewall manquante
  • mauvaise IP WAN sélectionnée
  • redirection de port manquante sur le routeur du fournisseur
  • Azure Network Security Group bloque le port
  • service interne non démarré
  • passerelle du serveur ne pointe pas vers la Sophos Firewall
  • règle NAT placée sous une autre règle qui correspond avant elle
  • port déjà utilisé par un autre service
  • Loopback manquant lorsque les clients internes utilisent le FQDN public
  • Health Check manquant ou incorrect si Load Balancing est utilisé
  • test effectué depuis le réseau interne et non depuis l’extérieur

Le Log Viewer est le point de départ le plus important pour les problèmes DNAT. On y voit si le trafic arrive, quelle règle correspond et s’il est autorisé ou rejeté.

Recommandation

Les règles DNAT doivent être vérifiées régulièrement. Les anciennes ouvertures sont un risque de sécurité typique. Une bonne documentation contient l’objectif, le serveur cible, les ports externes, la personne responsable, la date d’expiration et la dernière vérification.