Une revue de pare-feu trouve une règle « source quelconque / destination quelconque / autoriser » près du haut de la politique. Quel est le problème et la correction ?

Trouver une règle any → any → autoriser près du haut d'une politique de pare-feu, c'est trouver un pare-feu qui, en pratique, ne filtre rien du tout. La correction consiste à la supprimer et à reconstruire autour du moindre privilège avec un ordonnancement correct.

Pourquoi une règle any/any en haut casse tout

Les pare-feu évaluent les règles de haut en bas, premier match gagnant. La première règle qui correspond à un paquet décide de son sort, et l'évaluation s'arrête là. Une règle correspondant à toute source vers toute destination correspond à chaque paquet — elle se déclenche donc avant que la moindre règle de refus ou d'autorisation restreinte placée en dessous n'ait sa chance. Ces règles inférieures deviennent masquées (shadowed) : présentes dans la configuration, mais mortes. Le résultat est un « permettre tout » implicite, qui défait toute la raison d'être de l'équipement et viole généralement des référentiels comme NIST SP 800-41 et les CIS Controls.

La bonne correction

Reconstruisez sur les principes de refus par défaut et de moindre privilège :

1. Inventoriez les flux réellement requis (source, destination, port, protocole) — utilisez des journaux de connexion / NetFlow pour ne pas casser la production.
2. Écrivez des règles d'autorisation explicites et étroitement délimitées pour exactement ces flux.
3. Ordonnez-les pour que les règles spécifiques précèdent les générales, et placez un refus par défaut (avec journalisation) en bas pour attraper tout le reste.
4. Validez, puis supprimez la règle any/any.

Pourquoi les autres réponses sont fausses

• « C'est efficace et on peut la garder » confond « correspond vite » avec « sécurisé ». Elle est efficace pour laisser passer les attaques.
• La déplacer en bas reste dangereux : elle masque désormais le refus par défaut, ré-autorisant tout ce que les règles explicites n'autorisaient pas déjà. La règle any/any doit simplement être supprimée, pas déplacée.
• La renommer est cosmétique — le comportement de correspondance des paquets est identique.

L'examinateur veut voir que vous comprenez l'ordre d'évaluation comme un contrôle de sécurité, que vous savez migrer vers le moindre privilège sans coupure et qu'une politique propre se termine par un refus par défaut plutôt que par une autorisation globale.