UFW allow port - Sécurisez l'ouverture de vos ports

Ouvrir un service au public sans élargir la surface d’attaque demande plus qu’une commande rapide. Avec UFW, je cherche toujours à définir le bon port, le bon protocole et la bonne portée avant de laisser passer le trafic entrant; c’est exactement l’idée derrière ufw allow port. Dans ce guide, je montre comment écrire la règle correcte, quand utiliser un nom de service, comment limiter l’accès à une IP ou à un sous-réseau, et comment vérifier que tout fonctionne sans exposer inutilement le serveur.

Ce que fait vraiment une règle UFW sur un port

Je distingue toujours trois choses: le port, le protocole et le service. Le port est juste un numéro, le protocole précise comment le trafic circule, et le service est le programme qui écoute réellement sur la machine. Ouvrir une règle dans UFW ne démarre rien: si ton application n’écoute pas sur ce port, ou si elle est bindée sur 127.0.0.1 au lieu de 0.0.0.0, le pare-feu n’y changera rien.

Dans la syntaxe simple, UFW considère par défaut le trafic entrant. C’est pratique pour un serveur web, une API ou un proxy inverse, parce que je n’ai pas besoin d’écrire in à chaque fois. La nuance importante, c’est que ufw allow 53 n’a pas la même portée que ufw allow 53/tcp: sans protocole, UFW autorise TCP et UDP sur ce port. Pour DNS, c’est souvent voulu; pour un service web, je préfère être explicite.

• Port : le point d’entrée réseau.
• Protocole : TCP, UDP ou autre famille de trafic.
• Service : le démon ou l’application qui répond.
• Règle : le filtre qui décide si le trafic passe ou non.

Une fois ce cadre posé, la vraie question devient: quelle syntaxe écrire pour obtenir exactement le comportement attendu?

Les commandes qui couvrent la plupart des cas

Pour la majorité des serveurs, je reviens à quelques formes simples. Elles sont plus lisibles, plus faciles à auditer et moins sujettes aux erreurs qu’une règle trop générale. Voici celles que j’utilise le plus souvent.

Deux détails méritent de rester en mémoire. D’abord, la forme courte sans protocole est parfois plus large qu’on ne l’imagine. Ensuite, la commande reste valide avant même d’activer UFW, ce qui permet de préparer l’ouverture d’un port critique avant le basculement. Je m’en sers souvent pour SSH sur un serveur administré à distance, parce qu’une erreur de timing peut couper l’accès en plein milieu d’une session.

Pour vérifier sans appliquer, j’utilise aussi sudo ufw --dry-run allow 8080/tcp. C’est une habitude simple, mais elle évite pas mal de mauvaises surprises. Une fois la syntaxe maîtrisée, le vrai sujet devient la réduction du périmètre d’exposition.

Limiter l’accès au lieu d’exposer tout Internet

Quand je peux restreindre, je restreins. Ouvrir un port à any est pratique, mais ce n’est presque jamais le meilleur choix pour un service sensible. Pour une base de données, un backoffice, une console d’administration ou un endpoint interne, je préfère limiter la règle à une IP, à un sous-réseau ou, si besoin, à une interface précise.

Cette approche a un coût: elle suppose de connaître les IP de confiance, ou de passer par un VPN, un bastion ou une passerelle stable. Mais en pratique, c’est presque toujours un meilleur compromis que d’ouvrir un port au monde entier pour “aller plus vite”. Dans un environnement DevOps, je préfère une règle un peu plus spécifique qu’un correctif de sécurité plus tard.

Le même raisonnement vaut pour les profils d’application. Si le logiciel fournit déjà une définition UFW propre, je l’utilise plutôt que de réécrire la règle à la main, parce qu’on garde mieux la cohérence entre l’application et son pare-feu.

Vérifier que la règle fonctionne vraiment

Ouvrir un port ne suffit pas. Je vérifie toujours trois points: la règle existe, le service écoute, et le test vient d’une machine extérieure au serveur. Le réflexe minimal, c’est sudo ufw status numbered pour voir la règle telle qu’UFW l’a enregistrée, puis sudo ufw status verbose pour relire l’état global et les politiques par défaut.

• sudo ufw status numbered : utile pour retrouver une règle précise et la supprimer ensuite.
• sudo ufw status verbose : montre l’état général du pare-feu.
• ss -lntup : confirme qu’un service TCP écoute réellement.
• ss -lunp : utile pour les services UDP.
• curl -I http://serveur:8080 ou nc -vz serveur 8080 : test simple depuis une autre machine.

Si je veux retirer une règle, j’ai deux options: soit la supprimer par son numéro avec sudo ufw delete 3, soit reprendre la règle d’origine avec sudo ufw delete allow 8080/tcp. Je préfère la seconde quand je veux être explicite, et la première quand plusieurs règles se ressemblent. Dans tous les cas, je fais attention aux doublons IPv4/IPv6, parce qu’une suppression par numéro ne retire pas toujours tout ce qu’on imagine.

Pour une ouverture temporaire ou un diagnostic, j’ajoute parfois le mot-clé log sur la règle afin d’observer les connexions qui la touchent. C’est simple, mais très utile quand un client dit “le port est ouvert” alors que le service refuse encore les connexions. Une fois la règle validée, il reste surtout à éviter les erreurs de configuration les plus courantes.

Les erreurs que je corrige le plus souvent en audit

La plupart des incidents que je vois avec UFW ne viennent pas de la syntaxe elle-même, mais d’un décalage entre la règle et la réalité du service. Le firewall est souvent innocent; c’est l’architecture autour qui n’a pas été relue assez tôt.

• Mauvais protocole : TCP a été ouvert alors que l’application a besoin d’UDP, ou l’inverse.
• Port ouvert, service absent : la règle est correcte, mais aucun processus n’écoute sur ce port.
• Application bindée en local : le service répond seulement sur 127.0.0.1, donc il reste invisible de l’extérieur.
• Port applicatif exposé directement : on ouvre 3000, 8080 ou 5000 au lieu de passer par le proxy inverse qui termine le trafic en 443.
• SSH oublié avant activation : le serveur devient injoignable au moment où UFW s’active.
• Règle trop large : on autorise any par confort alors qu’un sous-réseau ou une IP fixe suffisaient.
• Suppression partielle : on retire une règle numérotée mais on oublie l’autre famille d’adresses ou une règle équivalente.

Je rencontre aussi un piège plus subtil dans les stacks modernes: le trafic ne suit pas toujours le chemin que l’on imagine. Entre Docker, un proxy inverse, un load balancer ou des règles NAT, la couche de filtrage réelle n’est pas toujours celle qu’on vient modifier. Quand je travaille sur un serveur de production, je vérifie donc le flux complet, pas seulement la commande UFW. C’est ce contrôle bout en bout qui évite les faux diagnostics.

À ce stade, la bonne pratique n’est plus “ouvrir un port”, mais “ouvrir la bonne porte, au bon endroit, pour la bonne durée”. C’est cette discipline qui fait la différence entre un serveur simplement fonctionnel et un serveur réellement maîtrisé.

Le réflexe que je garde avant de passer en production

Avant de valider une ouverture définitive, je passe toujours par la même séquence: je confirme que le service écoute, je limite la portée au minimum utile, je prévisualise la règle avec --dry-run, puis je teste depuis une machine extérieure. Si le service est exposé au public, je préfère encore qu’il passe derrière un proxy inverse ou un équilibreur, avec un seul port d’entrée clair à documenter et à surveiller.

Je note aussi mes règles avec un commentaire explicite dès que le contexte devient un peu plus long que prévu. Un comment bien choisi coûte presque rien et fait gagner du temps au prochain audit, surtout quand plusieurs équipes touchent au même serveur. C’est le genre de détail qui ne change pas la sécurité à lui seul, mais qui améliore nettement la maintenabilité.

En production, ma règle est simple: ouvrir le moins possible, tester le plus tôt possible, et garder chaque exception visible. C’est la méthode la plus fiable que j’aie trouvée pour gérer UFW sans transformer un simple port en dette opérationnelle.