Cours Ubuntu 26.04 / Restreindre les accès d’administration et de service avec UFW

Configurez UFW en autorisant d’abord la véritable source de votre accès d’administration, puis les seuls services nécessaires. Avant de l’activer, gardez une console de secours et une règle SSH adaptée ; vérifiez ensuite de nouvelles connexions depuis un client autorisé et un client non autorisé.

Relever les services et l’adresse source réellement vue par le serveur

Uncomplicated Firewall, ou UFW, fournit des commandes de gestion du pare-feu Linux. Un port ouvert dans sa politique ne crée pas un service : l’application doit aussi écouter sur la bonne adresse. Inversement, un service peut écouter alors que son accès est filtré.

sudo ss -lntup
sudo ss -tn
sudo ufw status verbose
sudo ufw status numbered
sudo ufw show added

Dans ss, relevez les ports d’écoute et l’adresse du pair de la connexion SSH établie. Un VPN ou une traduction NAT peut modifier la source vue par le serveur. Le laboratoire de configuration de l’adresse fixe utilise le serveur 192.168.56.20 et le client Linux 192.168.56.10 sur le réseau privé.

Si vous administrez directement depuis l’hôte, sa source peut être 192.168.56.1 dans ce plan ; vérifiez-la au lieu de reprendre .10. La destination .20 du serveur ne doit pas être confondue avec l’adresse source du client. Confirmez aussi le port effectif de votre serveur OpenSSH avant d’écrire une règle pour 22.

L’état inactive ne signifie pas qu’aucune règle n’est enregistrée. show added aide à relire les règles ajoutées, alors que status indique l’état du pare-feu et ses règles actives. Une règle déjà présente doit être conservée et identifiée comme telle ; n’en revendiquez pas la création pour la supprimer ensuite.

Définir la portée du laboratoire et conserver l’état initial

Le parcours suivant vise une VM dédiée, sans règles ni politique personnalisées préexistantes, avec accès console fonctionnel. Sur un serveur déjà administré, préservez son filtrage et soumettez seulement une modification adaptée à sa politique. N’exécutez pas le bloc des politiques par défaut pour remplacer une configuration que vous n’avez pas analysée.

Si UFW manque, préparez le paquet ufw par APT après lecture du plan d’installation. Notez l’état actif ou inactif, les politiques d’entrée, de sortie et de routage, ainsi que les règles et personnalisations. Sauvegardez ses fichiers avant la première modification :

(
set -eu
ufw_backup=$(sudo mktemp -d /root/ufw-backup.XXXXXX)
sudo cp -a /etc/ufw /etc/default/ufw "$ufw_backup/"
printf 'Sauvegarde : %s\n' "$ufw_backup"
)

Ne poursuivez pas si la copie échoue et notez le chemin affiché après réussite. Cette copie conserve la configuration UFW ; elle ne sauvegarde pas à elle seule toutes les règles d’autres outils, celles d’un fournisseur cloud ni l’état des connexions.

Connectez-vous à la console et gardez la session distante existante. Le guide Ubuntu du pare-feu présente les permissions par source et les simulations. Une erreur sur le client ou le port d’administration peut vous couper l’accès dès l’activation.

Autoriser SSH avant d’activer le filtrage du laboratoire

Les valeurs de ce bloc sont le client .10, le serveur .20 et SSH sur TCP 22. Adaptez-les aux relevés précédents. La destination explicite limite cette permission à l’adresse privée du serveur :

sudo ufw --dry-run allow from 192.168.56.10 to 192.168.56.20 port 22 proto tcp
sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 22 proto tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing

Relisez la simulation avant de créer la règle. --dry-run montre les changements proposés sans les appliquer ; ce n’est pas une preuve de connectivité. Sur cette VM neuve, la politique deny incoming refuse les nouvelles entrées qui ne sont pas autorisées par les règles applicables, tandis qu’allow outgoing conserve les sorties habituelles du laboratoire.

Une règle générale déjà présente peut encore autoriser d’autres sources. Les règles d’UFW et celles chargées par d’autres fichiers demandent donc une lecture d’ensemble ; ajouter une permission étroite ne révoque pas automatiquement un accès plus large existant. Le manuel UFW d’Ubuntu décrit la syntaxe, les rapports et l’ordre des règles.

Quand les règles d’administration et la console sont prêtes, activez le pare-feu :

sudo ufw enable
sudo ufw status verbose
sudo ufw status numbered

Lisez l’avertissement de coupure possible des connexions. L’activation concerne aussi le démarrage ultérieur de la machine. Depuis le client autorisé, ouvrez aussitôt une nouvelle connexion SSH ; gardez l’ancienne session jusqu’à réussite du test et de l’administration nécessaire.

Ajouter seulement un service réellement nécessaire

Si un service HTTP du laboratoire écoute déjà sur l’adresse visée et qu’un test depuis .10 est nécessaire, examinez puis ajoutez cette permission. Sans service HTTP prévu, sautez ce bloc :

sudo ufw --dry-run allow from 192.168.56.10 to 192.168.56.20 port 80 proto tcp
sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 80 proto tcp
sudo ufw status numbered

HTTP désigne ici le service web TCP sur 80 ; ce n’est pas une ouverture HTTPS sur 443 ni une autorisation pour tous les clients. Les profils d’application peuvent couvrir plusieurs ports : relisez leur contenu avant de remplacer une règle précise par un profil plus large.

Pour un service sur une autre adresse, un autre port ou UDP, établissez d’abord son besoin et sa configuration réelle. N’ouvrez pas une plage entière pour éviter de chercher quel processus doit répondre.

Comparer les nouvelles connexions autorisées et interdites

Sur le client .10, répétez la connexion SSH avec le partage de connexion désactivé comme dans la leçon OpenSSH. Si HTTP est le service prévu et que curl est installé sur le client, demandez une nouvelle réponse :

curl --connect-timeout 5 --max-time 10 -I http://192.168.56.20/

Une réponse HTTP, même une erreur applicative, établit qu’un serveur a répondu ; comparez son code à la réponse attendue pour vérifier le service. Le délai de connexion et le délai total évitent une attente indéfinie, mais un timeout ne prouve pas à lui seul qu’UFW bloque les paquets.

Depuis un autre client dont la source réelle n’est pas autorisée, refaites le test vers la même adresse et le même port, sans créer de nouvelle permission pour lui. Ce client doit lui-même disposer d’un chemin réseau valide ; sinon, vous mesureriez une absence de route plutôt qu’un refus du pare-feu.

Contrôlez en parallèle le service d’écoute et, si la journalisation est activée, les événements de filtrage. Distinguez connexion refusée par un port sans service, paquets filtrés et erreur d’authentification SSH. Une session établie peut survivre grâce au suivi d’état : elle ne démontre pas qu’une nouvelle connexion serait autorisée.

Vérifier IPv6 et les autres couches de filtrage

Lisez le paramètre IPV6 dans /etc/default/ufw et les points d’écoute IPv6 relevés par ss. Un résultat IPv4 ne valide pas le filtrage IPv6. Dans ce laboratoire, la permission écrite avec la source .10 et la destination .20 est une règle IPv4 ; si l’administration doit passer en IPv6, il faut définir et tester la politique IPv6 voulue.

Si la prise en charge IPv6 d’UFW est désactivée ou si des règles extérieures sont présentes, analysez l’exposition réelle avant de conclure. Ne désactivez pas IPv6 globalement pour faire coïncider les résultats. Une adresse d’écoute générique, un routage fournisseur ou un transfert NAT peut ouvrir un chemin différent de celui du réseau privé.

La sécurité d’un groupe cloud, le pare-feu de l’hôte et UFW dans la VM sont des couches distinctes. Chacune peut autoriser ou bloquer une connexion. Documentez où s’applique la restriction et testez depuis le point d’accès réellement utilisé.

Docker peut aussi créer des règles pour les ports de conteneurs publiés. Sa documentation sur les pare-feu et UFW explique pourquoi ce trafic peut suivre un parcours qui contourne les règles d’entrée UFW attendues. Vérifiez les adresses de publication et l’intégration du moteur ; ne désactivez pas ses règles sans politique de remplacement adaptée.

Annuler uniquement les changements de l’exercice

Si la règle HTTP a été créée pendant cet exercice et n’existait pas avant, retirez exactement cette permission lorsque le test est terminé :

sudo ufw delete allow from 192.168.56.10 to 192.168.56.20 port 80 proto tcp
sudo ufw status numbered

Relisez le résultat et refaites un test de nouvelle connexion. Ne supprimez pas une règle antérieure identique que l’outil a simplement conservée. Pour une suppression par numéro, rechargez la liste après chaque retrait : les positions changent.

Conservez l’accès SSH tant qu’il reste nécessaire. N’utilisez pas reset ou une désactivation globale pour retirer une seule règle. Pour rendre une VM dédiée à son état initial entièrement inactif, revenez à la console et comparez état, politiques et fichiers au relevé initial ; ce retour retire aussi la protection et doit être cohérent avec l’usage prévu de la VM.

Si un changement bloque l’administration, la console permet d’inspecter et de corriger la règle ciblée ou de rétablir la configuration connue. Après un redémarrage planifié, confirmez encore la politique active et les nouvelles connexions attendues. La sauvegarde des fichiers, l’état en mémoire et la réponse des clients constituent trois vérifications complémentaires.