Choisir une politique par défaut
Objectif : Définir les décisions par défaut pour le trafic entrant, sortant et transféré.
Un serveur web reçoit des demandes de clients, répond à ces demandes et peut aussi communiquer avec d’autres systèmes. Si vous ne définissez pas ce qui doit arriver aux flux qui ne correspondent à aucune règle, votre configuration laisse une décision importante implicite. Vous allez choisir une politique par défaut pour chaque direction du trafic, sans encore modifier le pare-feu.
La décision appliquée en l’absence de règle correspondante
Une politique par défaut indique le traitement réservé au trafic qui arrive à la fin de l’évaluation sans avoir rencontré de règle qui le prend en charge. Elle s’applique séparément aux chaînes concernées : le trafic destiné au serveur relève de INPUT, le trafic produit par le serveur de OUTPUT, et le trafic transféré vers une autre destination de FORWARD. Pour le rôle de ces chaînes dans le trajet d’un paquet, reportez-vous à la leçon « Repérer les chaînes d’iptables ».
La politique n’est pas une règle détaillée : elle ne décrit pas un port ou un service en particulier. Une règle, elle, définit un cas précis et la décision associée ; la politique par défaut tranche les cas qui ne sont pas couverts. Vous pouvez donc autoriser explicitement les accès nécessaires, tout en choisissant ce qui arrive aux autres flux.
Choisir une politique adaptée au serveur web
Pour un serveur web exposé, le principe du refus par défaut consiste à bloquer par défaut les flux entrants qui ne sont pas autorisés explicitement. Vous réduisez ainsi le risque qu’un service oublié ou ajouté plus tard soit accessible sans décision de votre part. Ce principe ne signifie pas qu’il faut bloquer indistinctement toutes les directions : choisissez chaque politique selon les besoins réels du serveur.
| Chaîne | Décision à définir | Question à vous poser |
|---|---|---|
| INPUT | Refuser par défaut les entrées non autorisées | Quels services doivent être joignables depuis le réseau ? |
| OUTPUT | Choisir selon les besoins de communication du serveur | Quelles communications sortantes sont nécessaires à l’application et à l’administration ? |
| FORWARD | Refuser par défaut si le serveur ne route pas de trafic | Le serveur doit-il transmettre des paquets vers une autre machine ? |
Dans le projet fil rouge, l’application web doit recevoir les connexions utiles et le serveur doit pouvoir répondre. Le serveur n’est pas présenté comme un routeur : si votre inventaire ne révèle aucun besoin de transfert, une politique restrictive pour FORWARD évite de transmettre des flux sans intention définie. Pour OUTPUT, ne choisissez pas automatiquement un blocage global : vérifiez les besoins de l’application, des mises à jour et des outils d’administration.
Formuler votre choix avant de l’appliquer
À ce stade, consignez les décisions au lieu de les appliquer. Pour le serveur du projet, votre plan peut retenir le refus par défaut des entrées non autorisées et des transferts, sous réserve que le serveur n’ait pas besoin de router du trafic. Pour les sorties, notez les communications nécessaires et les éventuelles contraintes de votre environnement avant de décider.
Votre inventaire des ports utiles, établi dans la leçon précédente, sert à identifier les services entrants à autoriser ensuite. Il ne suffit pas à lui seul pour définir une politique de sorties ou de transfert : examinez aussi la fonction réelle du serveur. Les décisions proposées ici restent un plan ; aucune règle du pare-feu ni aucun fichier du projet n’est modifié.
À retenir
- La politique par défaut décide du sort des flux qui ne correspondent à aucune règle.
- Elle se choisit séparément pour INPUT, OUTPUT et FORWARD, selon le rôle et les besoins du serveur.
- Le refus par défaut limite les accès non explicitement autorisés, notamment pour le trafic entrant.
- Une politique restrictive ne s’applique pas avant la vérification de l’accès SSH et de la règle qui le préserve.
Dans la prochaine leçon, vous vérifierez l’accès SSH et préparerez sa protection avant toute activation restrictive.