Appliquer et tester le filtrage

Un pare-feu peut bloquer l’accès distant au moment même où vous l’activez. Vous allez appliquer les règles utiles au serveur web dans un ordre contrôlé, puis vérifier depuis une autre machine que les accès prévus fonctionnent et que les autres ports ne sont pas exposés.

Confirmer les ports avant toute modification

Le plan de règles préparé à la leçon précédente reste à confirmer sur le serveur : le port SSH peut différer de 22, et l’application peut ne pas utiliser les ports web habituels. Vérifiez le port configuré pour SSH ainsi que les ports d’écoute des services avant de poursuivre. Depuis votre session SSH actuelle, notez le port réellement utilisé et gardez cette session ouverte pendant toute l’intervention.

sudo sshd -T | grep '^port '
sudo ss -lntup

La première commande affiche le ou les ports configurés pour le serveur SSH. La seconde répertorie les sockets en écoute et leurs processus ; vérifiez les ports web réellement utilisés avant de les autoriser.

Appliquer les règles dans l’ordre sûr

Les commandes suivantes illustrent un serveur utilisant SSH sur le port 22 et un site sur HTTP et HTTPS, respectivement sur les ports 80 et 443. Remplacez ces valeurs si votre inventaire confirme d’autres ports ; n’ajoutez pas une autorisation pour un service absent du plan. La règle SSH est posée avant les politiques restrictives et avant l’activation d’UFW.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw status verbose

UFW doit afficher les trois autorisations prévues et les politiques entrante « deny » et sortante « allow ». Si UFW était déjà actif, contrôlez l’état et les règles existantes avant d’ajouter quoi que ce soit afin d’éviter les doublons ou les accès non prévus.

Relisez le résultat et vérifiez en particulier que la règle SSH correspond au port de la session en cours. Si UFW est inactif, activez-le seulement après cette vérification ; s’il est déjà actif, ne le réinitialisez pas et examinez d’abord toute différence avec le plan validé. Gardez la session administrative ouverte, puis ouvrez une seconde connexion SSH pour confirmer que l’accès fonctionne encore.

sudo ufw enable
sudo ufw status verbose

Après activation, l’état doit être « active », avec les politiques attendues et les seules autorisations prévues. N’exécutez la commande d’activation qu’après avoir confirmé la règle SSH correspondant au port réellement utilisé.

Tester depuis une autre machine

Un contrôle exécuté depuis le serveur ne suffit pas à valider les accès entrants. Depuis une autre machine du réseau autorisé, essayez une nouvelle connexion SSH et les services web prévus. Remplacez l’adresse par l’adresse accessible du serveur ; les tests HTTP et HTTPS supposent que les services correspondants sont démarrés et configurés.

ssh -p 22 utilisateur@ADRESSE_DU_SERVEUR
curl -I --max-time 5 http://ADRESSE_DU_SERVEUR
curl -I --max-time 5 https://ADRESSE_DU_SERVEUR

La connexion SSH doit s’ouvrir et les requêtes web doivent obtenir une réponse HTTP du serveur. Une réponse d’erreur applicative, comme 404, confirme tout de même que la connexion atteint le service web ; elle ne valide pas le contenu du site.

Pour vérifier un port non autorisé, choisissez un port que votre inventaire confirme comme inutilisé et que votre plan ne prévoit pas d’ouvrir. Depuis la machine de test, sonde ce port avec un outil tel que nc ou nmap ; un échec de connexion est cohérent avec le filtrage, mais peut aussi venir de l’absence de service ou d’un autre équipement réseau. Interprétez donc le résultat avec l’état UFW et l’inventaire du serveur, sans ouvrir de règle temporaire pour le test.

À retenir

• Confirmez le port SSH et les ports web réellement utilisés avant de modifier UFW.
• Ajoutez et relisez la règle SSH avant toute activation restrictive ; gardez la session actuelle ouverte.
• Testez les accès autorisés depuis une autre machine et interprétez les échecs avec l’état des services.
• Vérifiez qu’aucun port non prévu n’est accessible et ne créez pas de règle temporaire.
• La prochaine leçon traite de la journalisation des rejets et du contrôle final des règles.