Tester des changements de pare-feu sans se verrouiller dehors

La règle passe, le terminal que vous avez déjà continue de répondre, et la connexion suivante est refusée. Cet écart est toute la difficulté de tester un changement de pare-feu par la connexion que vous êtes en train de changer. Le suivi de connexion décide une fois puis cesse de regarder, donc un flux établi est la seule sonde qui ne peut pas voir la nouvelle politique. Ce qui suit compare les trois voies de retour, puis fixe l'ordre dans lequel modifier et vérifier les règles.

Pourquoi la session survivante est la preuve la plus faible

Un pare-feu à états évalue le premier paquet d'un flux et conserve ce verdict tant que l'entrée vit. Les règles ajoutées ensuite s'appliquent aux flux qui commencent plus tard, et c'est pourquoi la fenêtre dans laquelle vous tapez reste utilisable alors que tous les autres sont refusés. Ce que vous en apprenez décrit la politique en vigueur il y a quelques minutes. Même une capture prise sur ce flux montre une décision que la machine a déjà prise.

Traitez la session qui fonctionne comme une trappe de secours et non comme une mesure. Chaque vérification qui vaut la peine doit ouvrir un nouveau flux depuis une source que la nouvelle règle évaluera, et la première vérification devrait être celle dont l'échec ferait le plus mal. Quand cette session est votre seule voie d'entrée, le changement n'est pas prêt à être fait.

Trois voies de retour, classées selon ce dont chacune dépend

Classez les options selon leur dépendance à l'appareil testé, car c'est ce classement que vous saisissez quand la règle se révèle fausse. Une console qui ne traverse jamais le pare-feu est indépendante, un retour arrière répété l'est presque, et la session déjà ouverte ne l'est pas.

Avant le changement, connectez-vous par la console et prouvez qu'elle fonctionne, car une voie hors bande que vous n'avez jamais utilisée est un schéma et non un secours. Un retour arrière ne mérite sa place qu'après une répétition sur cette plate-forme, avec ce jeu de règles, en suivant la procédure approuvée plutôt qu'en improvisant sur une machine en production. Écrivez les étapes et faites-les relire par quelqu'un d'autre. Si la séquence a besoin de votre mémoire pour aboutir, ce n'est pas un plan.

Un changement, puis une connexion qui doit être évaluée

Sauvegardez le jeu de règles actif et le fichier qui le possède, puis faites une seule modification étroite. Un changement par test garde le résultat attribuable ; deux à la fois vous laissent une machine qui fonctionne et aucune idée de la modification qui a fait le travail. Là où la plate-forme peut analyser une configuration sans la charger, faites-le d'abord, afin qu'une faute de frappe échoue alors que rien n'est en jeu.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Démarrez ensuite une nouvelle session depuis une source que la règle modifiée fera correspondre, pendant que la console est encore connectée. Répétez-la une fois si elle réussit, car la première tentative peut tomber sur une entrée que la table détenait déjà. Si elle échoue, vous avez encore une voie d'entrée et une décision à annuler, ce qui est le pire résultat bon marché disponible.

Les compteurs, l'état et le fichier répondent à des questions différentes

Chacune des trois observations peut sembler convaincante seule et vous induire en erreur sur les deux autres. Les compteurs montrent si le flux que vous venez de créer a atteint la règle que vous avez modifiée. La table d'état montre quels flux la machine croit déjà établis, et c'est ainsi qu'une règle cassée peut encore paraître saine. Le fichier sauvegardé montre ce que l'appareil fera après le prochain rechargement, et ce n'est peut-être pas ce que fait maintenant le jeu de règles en cours.

ss -tn state established

Lisez les compteurs comme un delta et non comme un total, car le seul nombre qui compte est celui que votre flux de test a déplacé. Une règle dont le compteur n'augmente jamais ne correspond pas, aussi correcte paraisse-t-elle sur le papier. Confirmez aussi le cas de rejet : une politique qui n'a jamais rien refusé n'a jamais prouvé qu'elle refuse ce que vous vouliez bloquer. Parcourez une interface dans chaque famille que le déploiement transporte réellement, car une règle v4 ne dit rien d'un flux v6.

Restaurez depuis le jeu de règles sauvegardé, puis mettez le fichier en accord

Quand le changement échoue, chargez le jeu de règles sauvegardé au lieu d'ajouter des règles permissives jusqu'à ce que les connexions fonctionnent de nouveau. Chaque autorisation supplémentaire apaise le symptôme et laisse un trou qui survit à l'incident et au souvenir qu'on en garde. Restaurez, reconnectez, puis gardez la comparaison ratée à côté du relevé de ce que vous avez tenté.

Après un changement réussi, faites en sorte que le fichier sur disque décrive le jeu de règles en cours, et confirmez qu'un rechargement le reproduit. Un jeu de règles actif qui a dérivé de son propre fichier de configuration est un piège posé pour le prochain redémarrage.