FirewallFirewall25 oct. 202625 Oct 20266 min de lecture
5 erreurs que l'on retrouve sur presque tous les FortiGate5 mistakes we find on almost every FortiGate
Règles « any / any », administration exposée, firmware en fin de support, inspection désactivée, journaux que personne ne lit : le retour d'expérience de nos audits, et comment corriger sans couper la production."Any / any" rules, exposed administration, end-of-support firmware, inspection disabled, logs nobody reads: lessons from our audits, and how to fix them without cutting production.
Dësen Artikel ass op Franséisch an op Englesch verfügbar. Dir liest hei d'franséisch Versioun.
Un FortiGate bien configuré est un excellent équipement. Un FortiGate installé il y a quatre ans et jamais revu est une porte dont on a perdu la clé. En auditant des firewalls en production au Luxembourg, dans l'industrie, la logistique, les cabinets et les administrations, nous retrouvons les mêmes écarts avec une régularité frappante. Aucun n'est une faute professionnelle ; tous sont la conséquence normale du temps qui passe. Voici les cinq plus fréquents, pourquoi ils comptent, et comment les corriger sans casser la production.
1. Les règles « any / any » que plus personne n'ose toucher
Le symptôme. Une politique de sécurité autorisant toute source vers toute destination sur tout service, souvent nommée « TEMP », « TEST » ou « DEBUG », créée pour résoudre un problème urgent. Sur un cluster audité récemment : 27 règles de ce type, dont 9 sans aucun trafic depuis six mois.
Le risque. Ces règles neutralisent la segmentation. Un poste compromis sur le LAN atteint les serveurs, l'OT ou le site distant sans obstacle. Elles contournent aussi les profils de sécurité, puisqu'on les crée rarement avec l'IPS ou l'antivirus activés.
La correction. Identifier les règles sans hit grâce aux compteurs, les désactiver (pas les supprimer) pendant deux semaines, puis les retirer. Pour celles qui portent du trafic réel, remplacer any par les objets précis : adresses, groupes, services. Le FortiGate indique pour chaque règle les objets effectivement utilisés ; c'est votre liste de courses.
2. L'administration exposée sur l'interface WAN
Le symptôme. HTTPS, SSH ou, pire, HTTP activés sur l'interface Internet pour « pouvoir intervenir de chez soi », sans restriction d'adresse source, avec un compte admin et un mot de passe partagé entre plusieurs prestataires.
Le risque. C'est l'écart le plus directement exploitable. Les interfaces d'administration de firewalls exposées sont scannées en permanence, et plusieurs vulnérabilités critiques de ces dernières années visaient précisément ce vecteur. Un mot de passe faible ou réutilisé suffit.
La correction. Désactiver l'accès administratif sur le WAN. Administrer via le VPN ou une interface de gestion dédiée. Si un accès externe est indispensable, le limiter avec les trusted hosts aux adresses du prestataire, imposer l'authentification à deux facteurs (FortiToken ou intégration avec votre annuaire), créer un compte nominatif par intervenant et retirer le compte admin par défaut de l'usage quotidien.
3. Le firmware en fin de support
Le symptôme. Une version de FortiOS qui n'est plus maintenue, parce que « ça marche » et que la fenêtre de maintenance n'a jamais été trouvée. Souvent associée au SSL-VPN en mode tunnel, lui-même en voie d'abandon par Fortinet au profit d'IPsec et de ZTNA.
Le risque. Les vulnérabilités d'un firmware en fin de vie sont publiques, documentées et intégrées dans les outils d'attaque. L'équipement devient le point d'entrée le plus simple du réseau, et aucun autre contrôle ne compense.
La correction. Planifier la mise à jour en suivant le chemin de migration recommandé par Fortinet, version par version, avec une sauvegarde de configuration avant chaque étape et un test de bascule sur le cluster. Prévoir une fenêtre de 45 minutes par nœud. Et profiter de l'opération pour migrer les accès distants vers IPsec ou ZTNA.
4. L'inspection désactivée « parce que ça ralentissait »
Le symptôme. Des règles de sortie sans profil IPS, antivirus ni filtrage web, ou une inspection SSL réduite au mode certificate inspection sur tout le trafic utilisateur. Souvent décidé un jour de lenteur, jamais remis en question.
Le risque. Un firewall qui ne regarde pas le contenu n'est qu'un routeur avec des règles. La majorité des menaces actuelles transitent dans des flux chiffrés et sortants : téléchargement d'un malware, communication vers un serveur de commande, exfiltration. Sans inspection, elles passent.
La correction. Réactiver les profils de sécurité sur les règles de sortie, en commençant par l'IPS et le filtrage web, qui ont peu d'impact sur les performances. Pour l'inspection SSL profonde, procéder par étapes : d'abord les catégories à risque, avec des exceptions documentées pour la banque et la santé, et un certificat déployé sur les postes. Si l'équipement ne suit pas, c'est un indicateur de dimensionnement, pas une raison de renoncer.
5. Des journaux activés que personne ne lit
Le symptôme. La journalisation est activée sur le disque local, parfois vers un FortiAnalyzer, mais personne ne consulte les alertes, aucune notification n'est configurée, et la rétention couvre quelques jours.
Le risque. Sans exploitation des journaux, une intrusion se découvre quand elle devient visible, c'est-à-dire trop tard. Et sans historique, l'analyse après incident est impossible. Les obligations de notification de NIS2 et de DORA, en 24 et 4 heures, sont alors hors de portée.
La correction. Centraliser les journaux, définir une rétention d'au moins six mois, configurer des alertes sur les événements qui comptent (connexions administratives, échecs d'authentification répétés, détections IPS critiques, changements de configuration), et désigner quelqu'un pour les lire. Si ce quelqu'un n'existe pas en interne, c'est précisément le rôle d'un service de supervision managé.
Ce qu'il faut retenir
Ces cinq erreurs ont un point commun : elles sont invisibles tant que personne ne regarde. Un audit de configuration prend quelques jours, un plan de correction se déroule sur un trimestre, et la supervision transforme un firewall en capteur. C'est l'ordre dans lequel nous recommandons de procéder, et c'est ce que mesure le score de notre audit Firewall Insight.
A well-configured FortiGate is an excellent piece of equipment. A FortiGate installed four years ago and never reviewed is a door whose key has been lost. Auditing firewalls in production in Luxembourg, across industry, logistics, professional firms and public bodies, we find the same gaps with striking regularity. None of them is professional misconduct; all are the normal consequence of time passing. Here are the five most frequent, why they matter, and how to fix them without breaking production.
1. The "any / any" rules nobody dares touch anymore
The symptom. A security policy allowing any source to any destination on any service, often named "TEMP", "TEST" or "DEBUG", created to solve an urgent problem. On a recently audited cluster: 27 such rules, 9 of them with no traffic for six months.
The risk. These rules neutralise segmentation. A compromised workstation on the LAN reaches the servers, the OT or the remote site unhindered. They also bypass the security profiles, since they are rarely created with IPS or antivirus enabled.
The fix. Identify rules with no hits using the counters, disable (not delete) them for two weeks, then remove them. For those carrying real traffic, replace any with precise objects: addresses, groups, services. The FortiGate shows for each rule the objects actually used; that is your shopping list.
2. Administration exposed on the WAN interface
The symptom. HTTPS, SSH or, worse, HTTP enabled on the Internet interface so as to "be able to intervene from home", with no source address restriction, an admin account and a password shared between several providers.
The risk. This is the most directly exploitable gap. Exposed firewall administration interfaces are scanned constantly, and several critical vulnerabilities in recent years targeted precisely this vector. A weak or reused password is enough.
The fix. Disable administrative access on the WAN. Administer via the VPN or a dedicated management interface. If external access is indispensable, limit it with trusted hosts to the provider's addresses, enforce two-factor authentication (FortiToken or integration with your directory), create a named account per person and retire the default admin account from daily use.
3. End-of-support firmware
The symptom. A FortiOS version that is no longer maintained, because "it works" and the maintenance window was never found. Often paired with SSL-VPN in tunnel mode, itself being phased out by Fortinet in favour of IPsec and ZTNA.
The risk. The vulnerabilities of end-of-life firmware are public, documented and built into attack tools. The device becomes the simplest entry point into the network, and no other control compensates.
The fix. Plan the update following Fortinet's recommended upgrade path, version by version, with a configuration backup before each step and a failover test on the cluster. Allow a 45-minute window per node. And use the opportunity to migrate remote access to IPsec or ZTNA.
4. Inspection disabled "because it slowed things down"
The symptom. Outbound rules with no IPS, antivirus or web filtering profile, or SSL inspection reduced to certificate inspection mode on all user traffic. Often decided on a slow day, never revisited.
The risk. A firewall that does not look at content is just a router with rules. Most current threats travel in encrypted, outbound flows: malware download, communication with a command server, exfiltration. Without inspection, they get through.
The fix. Re-enable security profiles on outbound rules, starting with IPS and web filtering, which have little performance impact. For deep SSL inspection, proceed in stages: first the risky categories, with documented exceptions for banking and health, and a certificate deployed on the workstations. If the device cannot keep up, that is a sizing indicator, not a reason to give up.
5. Logs enabled that nobody reads
The symptom. Logging is enabled to the local disk, sometimes to a FortiAnalyzer, but nobody looks at the alerts, no notification is configured, and retention covers a few days.
The risk. Without log analysis, an intrusion is discovered when it becomes visible, that is, too late. And without history, post-incident analysis is impossible. The NIS2 and DORA notification obligations, within 24 and 4 hours, are then out of reach.
The fix. Centralise the logs, define a retention of at least six months, configure alerts on the events that matter (administrative logins, repeated authentication failures, critical IPS detections, configuration changes), and appoint someone to read them. If that someone does not exist in-house, that is precisely the role of a managed monitoring service.
Key takeaway
These five mistakes have one thing in common: they are invisible as long as nobody looks. A configuration audit takes a few days, a remediation plan runs over a quarter, and monitoring turns a firewall into a sensor. That is the order in which we recommend proceeding, and it is what the score of our Firewall Insight audit measures.
Combien de ces erreurs sur votre firewall ?How many of these are on your firewall?
Firewall Insight : score /100, top 10 des risques, correspondance NIS2 et plan d'action en 5 jours ouvrés. Premier diagnostic gratuit en 15 minutes.Firewall Insight: score /100, top 10 risks, NIS2 mapping and an action plan within 5 business days. First free diagnostic in 15 minutes.