Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Un site public a besoin d’une porte d’entrée vers son application ; sa base de données, son interface d’administration système et son hyperviseur n’ont généralement pas à être publiés. Prévoir une zone de serveurs exposés et des règles explicites vers les dépendances nécessaires.
Nom DNS → éventuel proxy externe → box → pare-feu → proxy inverse → application. Noter à chaque étape port, protocole, certificat et responsable. Une redirection peut exister dans la box même si elle a été supprimée du pare-feu, ou inversement. Examiner aussi UPnP s’il est activé et les accès IPv6 qui ne passent pas par le NAT IPv4.
Pour un site HTTP, un proxy inverse peut sélectionner le backend selon le nom demandé. Valider le nom d’hôte, limiter les chemins d’administration selon l’usage et configurer des délais adaptés. Pour un jeu ou de l’audio/vidéo, vérifier les protocoles réellement nécessaires ; une règle Web ne remplace pas un flux UDP prévu par l’application.
Si plusieurs proxys se succèdent, définir une chaîne de confiance limitée. Le serveur doit reconnaître les proxys autorisés et ignorer les en-têtes d’identité fournis par une source quelconque. Sinon, un système de bannissement peut bloquer le proxy au lieu de l’attaquant, ou accepter une adresse falsifiée.
Utiliser une connexion extérieure maîtrisée. Vérifier le nom, TLS, la page d’accueil et une opération fonctionnelle sans données sensibles. Vérifier qu’un port d’administration et un port de base restent inaccessibles. Un scan seul ne prouve pas l’absence de faille applicative ; compléter par mises à jour, comptes, permissions et sauvegardes.
Retour arrière : conserver les configurations précédentes et pouvoir désactiver la publication sans arrêter les services internes. Pour une application de gestion réservée à l’entreprise, préférer une publication privée par VPN et un portail client séparé si nécessaire.
Consigner les exceptions, leur justification et leur date de réexamen. Supprimer une règle sans vérifier son propriétaire peut couper un service ; conserver indéfiniment une règle devenue inutile maintient une exposition évitable.
Un site Web peut passer par un reverse proxy HTTP(S). Un serveur UDP de jeu ou de visioconférence peut nécessiter une publication directe de son port. Une interface de gestion ou une base de données doit rester privée dans le scénario courant d’une petite entreprise. Le DNS désigne le point d’entrée mais ne crée ni NAT ni autorisation.
| Champ | Valeur à déterminer | Contrôle |
|---|---|---|
| Interface | WAN d’arrivée | Correspond à la liaison réellement publiée |
| Address Family | Famille concernée | En IPv6, examiner le routage/filtrage plutôt que recopier le NAT IPv4 |
| Protocol | TCP ou UDP selon service | Ne pas élargir aux deux sans nécessité |
| Source | Sources limitées si elles sont connues | Si proxy amont exclusif, utiliser ses plages maintenues correctement |
| Destination | Adresse WAN ou IP virtuelle appropriée | Éviter any qui vise davantage que prévu |
| Destination port range | Port ou plage strictement nécessaire | Ne pas ouvrir une grande plage pour une application inconnue |
| Redirect target IP | Serveur interne exact | Réservation/adresse stable et bon VLAN |
| Redirect target port | Port réel du service | Peut différer du port externe |
| NAT reflection | Selon architecture, souvent split DNS préférable | Tester le chemin LAN séparément |
| Filter rule association | Règle associée cohérente | Vérifier la règle effectivement créée et ses sources |
| Description | Service, propriétaire, justification | Rend la suppression future sûre |
Après NAT entrant, la règle de filtrage associée concerne typiquement la destination traduite. Examiner la règle générée plutôt qu’en déduire ses adresses à partir du seul écran NAT. Sur une chaîne box → pfSense, les deux niveaux doivent être cohérents ; supprimer une publication implique de revoir les deux.
Le mode automatique couvre des scénarios standards. Le mode hybride ajoute des exceptions aux règles générées. Le mode manuel exige une liste complète maintenue ; basculer sans préparer peut couper Internet à certains réseaux. Renseigner interface de sortie, source, destination si limitée et adresse de traduction. Static port conserve le port source et ne doit être appliqué que si le protocole le nécessite ; ce n’est pas un accélérateur universel.
Le NAT 1:1 associe des adresses et demande une politique de filtrage explicite. Ce n’est pas un moyen de publier « seulement le site » : comprendre tous les flux qui peuvent atteindre cette adresse.
Sur HAProxy ou un équivalent, définir une entrée HTTPS avec son certificat, une condition sur le nom d’hôte et une action vers le backend exact. Prévoir un comportement sûr pour un nom inconnu. Le backend décrit adresse, port, protocole et test de santé ; une connexion TCP réussie ne prouve pas que la page métier répond.
Pour HTTPS jusqu’au backend, valider le certificat et le nom attendus. Une redirection HTTP vers HTTPS doit tenir compte des challenges de certificats et de l’application. Déclarer précisément les proxies de confiance pour les en-têtes de client ; sinon un visiteur peut falsifier l’adresse apparente dans certaines configurations.
Depuis un réseau mobile, tester le nom, le certificat et une opération publique. Depuis une zone non autorisée, confirmer le refus de l’administration et de la base. Tester aussi l’adresse d’origine si la protection suppose un passage exclusif par un proxy. Examiner les enregistrements AAAA, anciennes redirections et UPnP/PCP.
Une page de connexion exposée n’est pas « privée » parce qu’elle demande un mot de passe. Pour les applications de gestion, préférer une route VPN et un DNS privé ; un portail clients public doit avoir des droits, interfaces et données distincts. Lors du retrait d’un service, retirer publication, DNS inutile et règles associées après vérification des dépendances.