Les bonnes pratiques pour la configuration d’un firewall d’entreprise

Le firewall, ou pare-feu en français, est un logiciel et/ou un équipement matériel dont le rôle est de filtrer le trafic entrant et sortant d’un réseau informatique. Il contribue à renforcer la sécurité du système d’information (SI), mais une mauvaise configuration peut constituer l’une des principales causes de compromission.

Son rôle est central dans la stratégie de sécurité périmétrique du SI, car il constitue souvent le principal point de contrôle du trafic réseau. En appliquant des politiques de sécurité strictes, il est possible de réduire de manière considérable la surface d’attaque du SI.

Cependant, malgré leur importance, les firewalls sont souvent mal configurés. Une erreur de configuration peut avoir de nombreux impacts sur le SI, entraîner une compromission et/ou provoquer des interruptions de service.

Le but de cet article est de passer en revue les erreurs de configuration les plus fréquentes et de présenter les bonnes pratiques permettant de garantir un niveau de sécurité et de fonctionnement optimal.

---

Bonnes pratiques de configuration d’un firewall

Bonnes pratiques concernant l’architecture

Premièrement, nous allons aborder les bonnes pratiques en matière de choix d’architecture.

Mise en place d’un cluster

Un cluster de firewalls est un groupe de pare-feu qui collaborent afin d’améliorer la performance, la disponibilité et la fiabilité. Sa mise en place constitue un réel gain pour votre infrastructure, à condition que le périmètre qu’il protège justifie cet investissement. Un cluster comprend a minima deux membres, ce qui implique un doublement des coûts de matériel, de licences et de maintenance. Il existe deux types de cluster :

• Actif / Passif
• Actif / Actif

En cas de choix d’un mode Actif / Actif, il est impératif de dimensionner les boîtiers afin que leur pic d’utilisation ne dépasse pas 50 %. En cas de perte de l’un des deux membres, l’autre doit être en mesure d’absorber l’intégralité du trafic sans dégradation de service.

La plupart des grands constructeurs (Palo Alto, Fortinet, Check Point, Juniper) supportent les modes Actif / Passif et Actif / Actif, avec certaines contraintes pour le mode Actif / Actif (synchronisation des sessions, complexité de routage, risque de latence, etc.).

Dans la majorité des cas, il est recommandé d’utiliser un mode Actif / Passif. Ce mode, universellement supporté par les constructeurs, est fiable et offre une configuration plus simple. En cas d’incident, il est également plus aisé d’identifier la cause du dysfonctionnement via un seul point actif.

Le mode Actif / Actif est à privilégier dans des environnements à très hauts débits.

Un firewall dédié par contexte

Il est recommandé d’isoler chaque contexte (un environnement par client ou par métier, par exemple) sur un firewall dédié afin de garantir une sécurité renforcée et une meilleure disponibilité.

• Sécurité : disposer d’un firewall par zone permet, en cas de compromission, de ne pas impacter l’ensemble du SI et de réduire les risques de propagation latérale.
• Disponibilité : en cas d’incident, cela limite le risque de point de défaillance unique (Single Point of Failure) pour plusieurs environnements critiques. Des règles dédiées à un contexte réduisent les erreurs de configuration, assurent une granularité plus fine et facilitent les audits.

Si vous souhaitez prétendre à des certifications comme l’ISO 27001, il sera plus simple de démontrer la séparation des environnements grâce à des firewalls dédiés par zone.

Isoler les flux de production des flux de management

Il est essentiel d’isoler les flux de production des flux de management pour des raisons similaires à l’utilisation d’un firewall dédié par contexte. Cette séparation renforce la sécurité du SI et améliore sa disponibilité.

• Sécurité : les flux de management et de production n’ont pas vocation à être soumis aux mêmes contraintes. Isoler les flux d’administration est indispensable pour garantir leur intégrité et limiter les risques. Par exemple, l’accès aux flux d’administration peut être restreint via un VPN dédié, réduisant ainsi la surface d’attaque.
• Disponibilité : si l’accès de management est indisponible, la production reste opérationnelle. À l’inverse, si l’accès de production est indisponible, l’accès de management reste possible pour investiguer et rétablir le service au plus vite.

Bonnes pratiques concernant l’administration des comptes

Limitation des droits pour les comptes de service

Il est fréquent de constater que les comptes de service disposent de droits excessifs. Pourtant, il n’est pas toujours nécessaire d’attribuer des droits en lecture/écriture (RW). Par exemple, pour effectuer la sauvegarde d’un firewall, un compte en lecture seule (RO) est suffisant dans la majorité des technologies.

Cette limitation réduit la surface d’attaque du SI et diminue les risques liés aux erreurs humaines. Si un administrateur utilise un compte de service en lecture seule, une erreur de manipulation n’aura aucun impact sur la disponibilité des firewalls.

Le principe du moindre privilège est une bonne pratique largement reconnue, notamment par la norme ISO 27001.

Comptes nominatifs pour les administrateurs

Un compte nominatif par administrateur facilite la traçabilité. En cas de compromission ou de modification erronée d’une configuration, il devient plus simple d’identifier la cause racine.

Il est également recommandé de superviser l’utilisation du compte administrateur local des firewalls. En cas de tentative d’accès non légitime, une alerte peut être déclenchée. L’usage de ce compte doit être strictement réservé aux situations où les comptes nominatifs sont indisponibles.

Bonnes pratiques concernant les règles de flux

Nettoyage des règles non utilisées

Il est essentiel de mettre en place une politique claire et récurrente de nettoyage des règles de firewall. Une bonne hygiène des règles de flux améliore la performance, la lisibilité et réduit les risques liés aux configurations obsolètes.

Selon les technologies, différents indicateurs permettent d’identifier les règles inutilisées, tels que « Last Hit » ou « Hit Count ».

Exemple de processus :

• Si une règle n’est plus utilisée depuis six mois, elle peut être désactivée pendant trois mois (les délais doivent être adaptés à la criticité et au contexte métier).
• Pendant la période de désactivation, mettre en place un monitoring des logs afin de détecter d’éventuels flux bloqués ou incidents.
• Obtenir une validation métier avant toute suppression définitive.
• En l’absence d’incident et après validation, procéder à la suppression de la règle.

Ce processus peut être automatisé, avec une validation humaine obligatoire. La génération de rapports réguliers facilite la revue et la traçabilité.

L’ensemble de ces actions doit être tracé dans un outil dédié (qui, quand, pourquoi) afin de faciliter les analyses post-incident.

⚠️ Certains flux peuvent être rarement utilisés mais critiques (PRA, maintenance, etc.).

Maîtriser les ouvertures de flux

L’utilisation du mot-clé « ANY » dans les règles de flux doit être évitée autant que possible. Chaque ouverture doit être strictement maîtrisée afin de limiter la surface d’attaque du SI.

Bonnes pratiques :

• Éviter les règles avec ANY en IP source ou destination, ports ou protocoles.
• Privilégier des règles précises (IP ou sous-réseaux définis, ports spécifiques).
• Limiter la durée des ouvertures larges ou des protocoles obsolètes (Telnet, SNMPv1, etc.) et prévoir une date d’expiration.
• Documenter et justifier toute exception avec validation métier.
• Mettre en place un monitoring pour détecter les usages anormaux.

En cas d’audit ou de remédiation, il peut être nécessaire de segmenter progressivement une règle trop large afin d’éviter toute interruption de service critique.

Activation de la journalisation

La journalisation est indispensable pour l’analyse des événements et l’investigation en cas d’incident. Sans logs, il devient difficile de retracer les flux et d’identifier l’origine d’un problème.

Il n’est toutefois pas nécessaire d’activer la journalisation sur l’ensemble des règles, au risque de surcharger les firewalls et les systèmes de collecte. Une approche ciblée est à privilégier.

Bonnes pratiques :

• Activer la journalisation de manière granulaire.
• Journaliser les règles critiques (accès Internet, VPN, administration, etc.).
• Utiliser des profils de logs adaptés aux usages.
• Désactiver la journalisation sur les règles intra-zone.
• Centraliser les logs dans un outil dédié (SIEM ou équivalent).
• Définir une politique de rétention claire.
• Superviser les comportements anormaux et leurs impacts.

Bonnes pratiques concernant la gestion des objets

La mise en place d’un référentiel de nomenclature, régulièrement mis à jour, permet d’éviter les doublons et de faciliter la compréhension des configurations.

Exemples de préfixes :

• NET : réseaux
• HOST : hôtes
• GRP : groupes
• SRV_TCP / SRV_UDP : services

Les équipes en charge de l’exploitation doivent être formées et sensibilisées au respect de ces nomenclatures.

Privilégier l’utilisation de groupes

Il est recommandé d’utiliser des groupes d’objets (plages IP, services) plutôt que des objets unitaires. Cela simplifie la lecture des règles et facilite la maintenance. En cas d’évolution, seule la modification du groupe est nécessaire, ce qui réduit les risques d’erreur.

Gestion centralisée des firewalls

Mise en place d’un manager

Dans le cadre d’un parc composé de plusieurs clusters, la mise en place d’un manager est fortement recommandée. Cet outil permet d’uniformiser les configurations, de centraliser la gestion des objets et de simplifier l’administration via une interface unique.

Managers de firewalls :

• FortiManager (Fortinet)
• Panorama (Palo Alto)
• Security Management Server (Check Point)

Managers de logs :

• FortiAnalyzer (Fortinet)
• Panorama – mode Log Collector (Palo Alto)
• Log Server / SmartEvent Server (Check Point)

Chez Palo Alto, Panorama peut assurer à la fois les fonctions de management et de collecte de logs. Toutefois, pour les infrastructures conséquentes, il est recommandé de séparer ces rôles.

Bonnes pratiques :

• Mettre en place une gestion stricte des droits.
• Prévoir la haute disponibilité (cluster Actif / Passif).
• Journaliser les actions administratives.
• Mettre en place des sauvegardes régulières et tester les restauration
• Rédaction d’un processus clair de validation avant déploiement des configurations sur les firewalls.
• Mise en place de créneau de push dédié à l’implémentation des configurations sur les boîtiers.

Le but de l’ensemble de ces outils est d’uniformiser au maximum votre parc afin de faciliter son administration tout en garantissant la sécurité et la traçabilité.

Mise en place d’un orchestrateur

Pour les environnements les plus vastes, un orchestrateur (Tuffin, Algosec, …) peut également apporter une plus-value en centralisant la gestion des politiques de sécurité. Il permet notamment l’implémentation automatique des règles de flux et la validation des changements via des workflows dédiés.

Conclusion

Un firewall n’est pas une solution « miracle ». Son efficacité dépend de la rigueur humaine engagée lors de sa configuration. La technologie ne remplace pas la nécessité de mettre en place des processus clairs partagés.

Les firewalls ne protègent efficacement que si leur configuration est maîtrisée, cohérente et régulièrement révisée. Cela implique :

• Une architecture adaptée et résiliente.
• Une gestion stricte des droits.
• Une hygiène des règles de flux.
• Une standardisation des pratiques

En résumé, la sécurité ne dépend pas uniquement des outils, mais de la discipline et de la gouvernance appliquées à leur utilisation. Un firewall bien configuré et administré est un atout majeur pour réduire la surface d’attaque de votre SI.