Nouvelle règle UFW, ancienne connexion : l’état établi l’emporte

Ajouter une règle de refus et voir un téléchargement ouvert continuer n’est pas un bug d’UFW. La règle que vous avez ajoutée se trouve après des règles qui ont déjà accepté le flux, et une connexion établie plus tôt continue de leur correspondre. Corriger cela suppose de l’insérer au bon endroit et de comprendre ce que promettent les règles précédentes. La version étroite de ce changement suit.

C’est l’ordre qui décide, pas l’existence de la règle

UFW est une interface qui écrit les règles netfilter par étapes : une section de cadre exécutée avant les règles utilisateur, puis les règles utilisateur elles-mêmes, puis une section exécutée après elles. Les règles préalables standard acceptent le trafic des connexions établies et associées, et ces règles sont évaluées avant tout ce que vous ajoutez avec un allow ou un deny ordinaire. La référence des commandes UFW documente la syntaxe d’insertion et la vue numérotée de l’état dont dépend ce changement.

Cet ordre explique la surprise. Votre nouvelle règle est réelle et se trouve dans la bonne table, mais elle n’est pas la première décision que rencontre le paquet. Une connexion déjà suivie comme établie ne l’atteint jamais.

Utilisez des règles route pour cette tâche, car le paquet est transféré à travers la passerelle plutôt qu’adressé à ses propres services. Une règle d’entrée filtrerait le mauvais trafic et semblerait ne rien faire.

Insérez au-dessus de l’autorisation large

Prévisualisez l’insertion avant de l’appliquer, et confirmez que la règle n’existe pas déjà ailleurs dans la liste. Dupliquer une politique identique rend le retrait ultérieur ambigu, et la personne qui supprime la mauvaise copie ne s’en apercevra pas avant des semaines.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Si l’aperçu montre exactement une règle à la position attendue, appliquez la même commande sans l’option dry-run. La position 1 la place au-dessus des autorisations utilisateur plus larges, pas au-dessus des règles de cadre examinées plus haut. Confirmez que le nom de l’interface correspond à l’appareil tunnel de cette passerelle, car une règle limitée à une interface qui n’existe plus restera dans la liste en paraissant correcte tout en ne correspondant à rien. Renommez la référence de l’appareil avant d’appliquer, pas après l’échec du test.

Aucun port de destination n’apparaît dans cette règle : elle refuse donc tous les ports TCP de cette adresse, pas seulement HTTPS. Si l’intention est un seul service, nommez le port ; une règle plus large que la politique est un futur incident qui attend son premier lecteur.

Ne limitez la source à une seule adresse que si cette adresse est liée à l’identité prévue. Un pool VPN à attribution dynamique peut remettre la même adresse à un autre client demain, et le refus suivrait l’adresse plutôt que la personne.

Les flux établis survivent à la nouvelle règle

Le suivi des connexions est la raison pour laquelle la session existante continue. Une fois un flux enregistré comme établi, les règles préalables acceptent ses paquets avant même que votre refus soit consulté, et le transfert se termine comme si rien n’avait changé. Tester avec un navigateur qui réutilise une connexion ouverte ne vous apprend donc rien sur la nouvelle politique. Un refus peut sembler inutile quelques minutes après le déploiement et parfaitement efficace pour l’utilisateur suivant qui se connecte.

Si l’exigence inclut de couper le trafic en cours, ce changement de règle utilisateur ne peut pas y répondre. Révoquer l’état suivi est une action distincte avec son propre rayon d’action, et elle relève du propriétaire du pare-feu et non de celui qui a ajouté la règle. Vider toutes les connexions d’une passerelle pour faire disparaître une session est le genre de correctif qui provoque un second incident.

N’oubliez pas les limites non plus. Cette règle ne dit rien d’ICMP, d’UDP ni d’IPv6, donc un ping réussi ne prouve pas que le refus a échoué. Une adresse IPv4 n’est pas non plus un site web : un nom peut se résoudre en plusieurs adresses, et seule celle que vous avez nommée est couverte.

Testez avec un flux neuf

Lisez les règles utilisateur numérotées et la vue brute effective, puis ouvrez une nouvelle connexion depuis le client choisi :

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

La vue brute compte parce que status omet les règles de cadre écrites à la main, ce qui peut faire paraître l’ordre différent de ce que le noyau applique. Comparez les deux avant de conclure qu’une règle est au mauvais endroit.

Vérifiez ensuite les deux contrôles qui prouvent que la règle est ciblée et non large : une destination autorisée depuis le même client fonctionne toujours, et un second client atteint encore la destination refusée si sa politique le permet. Un refus qui casse les deux tests est un changement de politique, pas une mesure ciblée.

Une fois le test terminé, ne retirez que la règle que vous avez ajoutée, en la réécrivant exactement. Si la politique est permanente, remettez-la au propriétaire du pare-feu avec l’identité du client, le propriétaire de la destination et une date de revue, afin qu’une adresse de tunnel réattribuée ne laisse pas derrière elle un refus obsolète.