Quatre erreurs de configuration de pare-feu courantes qui ouvrent l'accès aux acteurs malveillants

Lorsque Jody Brazil a lancé FireMon, c'était par nécessité de journaliser les modifications de politiques de pare-feu afin d'éviter les accès non intentionnels. Plus de vingt ans après, certaines de ces mêmes erreurs de configuration de pare-feu liées aux politiques restent omniprésentes, en particulier avec des postures de cybersécurité toujours plus complexes – et parfois déficientes.

« Qu'il soit ou non à l'origine du problème, le pare-feu est souvent pointé du doigt en cas d'interruption de service », déclare Tim Woods, VP Technology Alliances chez FireMon. Lorsque le pare-feu est effectivement en cause, il s'agit souvent d'une erreur de configuration qui offre aux attaquants un accès non prévu.

« Les acteurs malveillants recourent à l'automatisation pour scanner Internet et tester en continu la présence d'erreurs de configuration », explique Tim Woods. « Ils comptent sur des règles trop permissives, qui constituent une voie d'exploitation facile. »

Souvent, des règles sont temporairement levées ou « ouvertes » afin d'autoriser un accès à des fins métier légitimes, comme le déploiement d'une nouvelle application auprès des collaborateurs. Un administrateur peut alors assouplir les restrictions du pare-feu pour accorder des privilèges à cette application.

« L'intention réelle est de revenir plus tard pour resserrer cette règle », précise Tim Woods. « Le problème, c'est que 15 autres priorités surviennent et que l'on ne revient jamais corriger cette règle. »

Tout semble fonctionner, mais l'administrateur a laissé une ouverture exploitable par les acteurs malveillants.

Quatre erreurs de configuration de pare-feu courantes

Tim Woods a bien voulu détailler quatre types d'erreurs de configuration de pare-feu pouvant conduire à un environnement trop permissif.

1. Mise hors service de matériel

Supposons qu'un administrateur ait créé une règle d'accès de pare-feu pour un serveur marketing donné et que ce serveur soit ensuite mis hors service. Malheureusement, il a omis de supprimer la règle d'accès associée, désormais inutile. Celle-ci devient donc dormante. Un mois plus tard, un collègue réutilise l'ancienne adresse IP du serveur pour mettre en place un nouvel équipement : la règle dormante « se réveille » et finit par ouvrir un accès réseau involontaire à des ressources non prévues.

2. Règles en double

Les règles en double sont exactement ce que leur nom indique : elles reproduisent un chemin d'accès logique existant. Elles ne constituent pas un problème critique immédiat, mais à mesure qu'elles s'accumulent, elles ajoutent une complexité inutile à la politique de sécurité appliquée.

3. Règles de pare-feu masquées

Une règle masquée s'apparente à une règle en double, mais produit l'action inverse. Vous avez ainsi une règle qui autorise l'accès et une autre qui le refuse. Un administrateur de pare-feu qui examine manuellement une politique de sécurité peut mal interpréter son comportement réel. Il voit la règle de refus, mais passe à côté de la règle d'autorisation située plus haut. La règle « masquée » n'est donc jamais observée.

« C'est une erreur technique », indique Tim Woods. « Vous obtenez des règles qui se chevauchent, ou une règle coincée tout en bas. » L'administrateur ne sait parfois pas où placer la règle dans une politique et la met par défaut en bas de liste, explique Tim Woods, sans se rendre compte qu'une règle similaire ou contradictoire est appliquée à un niveau supérieur. Le comportement des règles de la politique devient alors facile à mal interpréter.

4. Inflation des politiques

« Il n'est pas rare que 30-40 % d'une politique de pare-feu reste inutilisée dans les grandes entreprises », note Tim Woods.

Là où il y a 20 ans on comptait 200-300 lignes de règles, les politiques actuelles peuvent en contenir de 10 000 à 100 000. Multipliez ce chiffre par le nombre total de pare-feu et le volume de règles devient ingérable. Cette inflation des politiques résulte en grande partie de l'accumulation de règles inutilisées, en double, masquées et trop permissives. Elle dégrade l'hygiène globale de la politique de sécurité appliquée.

Le cloisonnement des équipes de sécurité provoque des erreurs de configuration

Aux raisons évoquées ci-dessus s'ajoute une fragmentation des responsabilités en matière de sécurité observée ces dernières années, les organisations ne conservant plus une approche centralisée de la sécurité.

Là où une équipe de sécurité centrale gérait autrefois l'ensemble des contrôles, ce sont désormais les responsables métier, les parties prenantes, les équipes devops, les équipes de sécurité cloud et la sécurité informatique qui prennent en charge le déploiement des contrôles de sécurité lors du lancement d'applications, de charges de travail et de ressources. Dans les environnements actuels d'« entreprise hybride » de grande taille, la responsabilité de la sécurité se situe souvent dans une zone grise, observe Tim Woods.

« Nous ne jouons souvent plus la même partition », déclare Tim Woods. « Et ces silos, cette fragmentation qui s'est installée, créent des failles de sécurité. »

Avec le temps, l'écart de complexité se creuse. À mesure que le volume de règles augmente, le nombre de règles inutilisées, redondantes et trop permissives augmente également.

Plus cet écart se creuse, plus la probabilité d'une erreur humaine s'introduisant dans l'équation est élevée, et plus la probabilité que des erreurs de configuration surviennent et affectent le système est grande, souligne Tim Woods.

La gestion automatisée des politiques de sécurité résout les erreurs de configuration

Pour anticiper les problèmes de configuration, Tim Woods suggère d'utiliser une solution de gestion des politiques de sécurité réseau qui identifie et étiquette toutes les modifications apportées aux politiques de pare-feu.

« Il y a une question à laquelle il faut répondre chaque fois qu'une modification intervient », déclare Tim Woods. « Et cette question est : la modification qui vient de se produire sur mon réseau cause-t-elle un préjudice ? Oui ou non. »

Autrement dit, la modification de la politique a-t-elle eu un impact négatif sur la posture de sécurité de votre organisation ? Étiqueter la complexité aide en définitive à la réduire, explique Tim Woods. La capacité à analyser une modification au moment où elle se produit apporte de la visibilité. Mais un administrateur humain ne peut pas suivre le volume considérable d'alertes. C'est là qu'une plateforme d'automatisation conçue à cet effet prend le relais. À chaque modification, l'application la compare à l'ancienne règle, crée un enregistrement du changement et exécute des évaluations de la règle dans le contexte de la politique.

En résumé

Les erreurs de configuration de pare-feu ont plusieurs origines. Tim Woods, de FireMon, a identifié quatre causes courantes d'erreurs de configuration, puis a apporté un éclairage sur la complexité des effectifs de sécurité susceptible de conduire à ce type d'erreurs. Enfin, pour remédier aux erreurs de configuration des politiques de pare-feu, Tim Woods recommande une plateforme de gestion des politiques de sécurité réseau conçue à cet effet, capable d'automatiser la visibilité et l'analyse de toutes les modifications de politiques de pare-feu. Pour un guide complet sur la mise en œuvre correcte des pare-feu afin d'éviter ces écueils courants, consultez notre guide étape par étape de la mise en œuvre d'un pare-feu.