Pourquoi une politique de pare-feu se dégrade toujours
Aucune base de règles ne reste propre. Chaque règle a été ajoutée pour une bonne raison, par quelqu'un qui avait un problème à résoudre le jour même. Ce qui manque presque toujours, c'est la suppression : le projet se termine, le serveur est décommissionné, le prestataire part, et la règle reste. Au bout de quelques années, la politique décrit l'histoire de l'organisation plutôt que son besoin actuel.
Voici les défauts que l'on retrouve dans la quasi-totalité des audits, et comment les détecter sans relire des milliers de lignes à la main.
Six défauts récurrents
1. Les règles masquées
Une règle placée plus haut dans la liste intercepte tout le trafic qu'une règle plus basse était censée traiter. La seconde ne s'appliquera jamais. C'est le défaut le plus trompeur : la règle existe, elle est documentée, elle rassure, et elle est morte. Détecter une règle masquée demande d'analyser l'ordre et le recouvrement des objets, pas de lire les lignes isolément.
2. Les doublons
La même autorisation exprimée deux fois, souvent avec des objets nommés différemment. Sans danger immédiat, mais chaque doublon double le travail lors d'une revue et crée un risque de modification partielle : on restreint l'une, on oublie l'autre, et le flux reste ouvert.
3. Les règles trop permissives
Le any/any est le cas le plus visible, mais rarement le plus fréquent. Les variantes plus discrètes font autant de dégâts : une destination « any » sur un port précis, un groupe d'objets qui a grossi jusqu'à couvrir un réseau entier, un « any » en service sur une paire source-destination légitime. Le volume de trafic réellement autorisé est très supérieur à ce que l'intention d'origine prévoyait.
4. Les règles inutilisées
Une règle qui n'a intercepté aucun paquet depuis des mois protège un flux qui n'existe plus, ou en autorise un que personne ne surveille. C'est le meilleur candidat à la suppression, mais la décision exige une donnée que la configuration seule ne contient pas : les compteurs d'utilisation.
5. Les services non sûrs
Telnet, FTP, SNMP v1 ou v2c, HTTP d'administration : des protocoles encore autorisés parce qu'un équipement ancien en avait besoin. La règle survit souvent à l'équipement qui la justifiait.
6. L'absence de journalisation
Une règle sans journalisation est invisible dans une investigation. On découvre son existence au moment où l'on cherche à expliquer un incident, c'est-à-dire trop tard.
Pourquoi la revue manuelle échoue
Ces défauts ne se voient pas en lisant les règles une par une, parce qu'ils sont tous relationnels : ils résultent de l'interaction entre plusieurs règles, de l'ordre d'évaluation et du contenu réel des groupes d'objets. Un humain qui relit la ligne 400 a oublié la ligne 12. C'est une tâche d'analyse, pas de lecture.
S'ajoute le problème multi-constructeurs : la même intention s'exprime différemment selon le pare-feu, ce qui rend la comparaison entre sites impossible sans normalisation préalable.
Que faire du résultat
Un audit qui produit huit cents remarques ne sera pas traité. Ce qui rend l'exercice utile, c'est la hiérarchisation : d'abord les règles permissives exposées depuis une zone non maîtrisée, ensuite les services non sûrs, puis les règles mortes dont la suppression ne présente aucun risque. Les doublons et la cosmétique viennent en dernier.
Le second réflexe utile est de mesurer l'évolution plutôt que l'état : une politique qui s'améliore de quelques points par trimestre vaut mieux qu'un audit parfait jamais appliqué. Notre page audit des règles de pare-feu décrit l'analyse automatisée de ces défauts, et le module pare-feu montre comment le risque est attribué règle par règle.
