Établir le plan de règles du serveur

Une règle de pare-feu se prépare à partir des accès dont le serveur a réellement besoin, pas d’une liste de ports copiée sans vérification. Dans cette leçon, vous construisez un plan lisible avant toute modification : vous reliez chaque besoin à un flux, à une règle envisagée et à un critère de validation.

1. Recenser les flux nécessaires

Commencez par reprendre l’inventaire des services exposés et l’accès d’administration établis dans les leçons précédentes. Pour le serveur fil rouge, les besoins courants sont une connexion SSH d’administration et les accès web HTTP et HTTPS, si ces deux services sont effectivement proposés. Un port n’est pas nécessaire simplement parce qu’un service pourrait l’utiliser : confirmez qu’il écoute et qu’il correspond à un usage attendu.

Décrivez chaque flux avec une origine, une destination, un protocole et une justification. Pour une première politique de serveur web, le trafic entrant destiné au serveur est limité aux ports d’administration et aux ports web requis ; le trafic sortant peut rester autorisé selon la politique prévue dans les leçons précédentes. Le trafic transféré n’est pas un besoin de ce scénario tant que le serveur ne route pas de paquets pour d’autres machines.

Cette matrice est un plan, pas une preuve que le service est correctement configuré. Notez les valeurs constatées sur le serveur, en particulier si SSH utilise un port non standard ou si le site n’expose qu’HTTPS. Gardez aussi une trace des ports écartés et de la raison : cela évite de transformer un port inconnu en autorisation permanente par habitude.

2. Relier le besoin à la règle prévue

Pour chaque ligne retenue, écrivez une intention distincte : par exemple, « autoriser l’administration SSH sur le port confirmé », puis « autoriser le trafic HTTP vers le serveur ». Cette séparation rend les règles plus faciles à relire et à retirer si le besoin disparaît. Pour UFW, la forme générale d’une autorisation TCP par port est ufw allow PORT/tcp ; remplacez PORT par la valeur vérifiée au lieu de copier une valeur d’exemple sans contrôle.

Dans le plan, associez ces intentions à une politique entrante restrictive et à la politique sortante retenue, puis inscrivez explicitement les autorisations requises. La règle SSH doit correspondre au port réellement utilisé. Vérifiez-la et relisez-la avant d’envisager l’activation d’une politique restrictive ; ne comptez pas sur une autorisation implicite ou sur un ancien port supposé.

3. Définir comment valider le plan

Un plan exploitable précise ce que vous contrôlerez, sans confondre préparation et mise en service. Avant l’application, vérifiez que chaque port autorisé correspond à un service inventorié, que chaque règle porte une intention identifiable et qu’aucune autorisation superflue n’apparaît. Relisez également les règles UFW préparées et confrontez-les à la matrice : chaque accès attendu doit avoir une règle correspondante, et chaque règle doit avoir un besoin documenté.

Après application, les critères porteront sur les résultats observables : les accès prévus doivent fonctionner, les services qui ne figurent pas dans le plan ne doivent pas être accessibles depuis le réseau, et la règle SSH doit correspondre à l’accès d’administration utilisé. Ces contrôles ne se déduisent pas de la seule présence d’une règle dans la configuration. La prochaine leçon détaillera la séquence d’application, les tests depuis une autre machine et la vérification de la session SSH.

À retenir

• Partez des services inventoriés et justifiez chaque flux autorisé.
• Consignez le sens, le protocole et le port confirmé dans une matrice.
• Associez une règle distincte à chaque intention ; n’ouvrez pas de port sans besoin établi.
• Vérifiez la règle correspondant au port SSH réel avant toute activation restrictive.
• Définissez les critères de contrôle avant l’application ; ne modifiez pas encore le pare-feu dans cette étape.