Réponse à incident : un pare-feu qui ne redémarre pas au boot expose votre base de données

Un serveur Linux redémarre, à l'occasion d'une mise à jour, d'une maintenance de l'hébergeur, ou simplement d'un reboot planifié. Rien de spectaculaire en apparence. Sauf que ce serveur hébergeait un service de données (une base Elasticsearch, une base NoSQL, ou tout autre service exposant une API réseau) dont la seule protection reposait sur un pare-feu logiciel filtrant les connexions entrantes. Au redémarrage, le pare-feu ne repart pas. Le service, lui, redémarre normalement et se met à écouter sur toutes les interfaces réseau, sans qu'aucune authentification ne soit demandée. Résultat : n'importe qui sur Internet peut interroger la base et en aspirer le contenu. Ce scénario, en apparence anodin, est l'une des causes de fuite de données les plus documentées et les plus récurrentes. Voici comment il se produit, comment le détecter, et la méthode pour y répondre puis l'empêcher de se reproduire.

#1. Le scénario type

Beaucoup de PME (et d'ETI) sécurisent un service de données sensible par une seule barrière : un pare-feu réseau (Shorewall, UFW, iptables) qui n'autorise les connexions qu'à partir d'adresses IP de confiance. Le service lui-même (base de données, moteur de recherche, outil interne) n'a pas d'authentification propre, soit parce qu'il n'en propose pas nativement dans sa configuration par défaut, soit parce que "le pare-feu suffit déjà" a été la logique retenue au moment de l'installation.

Ce schéma fonctionne, jusqu'au jour où le pare-feu ne redémarre pas en même temps que le reste du système. Plusieurs causes techniques, courantes et souvent silencieuses, peuvent l'expliquer :

• Le service n'a jamais été activé au démarrage. Sur Debian et dérivés, apt install installe le paquet et permet de le lancer manuellement, mais ne garantit pas qu'il redémarre automatiquement après un reboot. Avec systemd, il faut explicitement systemctl enable le service pour qu'il soit relancé au prochain démarrage : un simple systemctl start ne le fait que pour la session en cours.
• Un réglage de configuration hérité reste sur "désactivé". Historiquement, Shorewall sur Debian embarque dans /etc/default/shorewall une variable startup qui doit être positionnée à 1 pour que le service démarre : à 0 (la valeur par défaut à l'installation, par sécurité, pour éviter de se retrouver bloqué hors du serveur avec une règle mal écrite), le service reste inerte même s'il est par ailleurs activé côté systemd.
• Une migration vers systemd a fait sauter le lien de démarrage. Lors du passage d'un système historique (init.d/sysvinit) vers systemd, que ce soit via une montée de version de l'OS ou une réinstallation, les anciens liens d'activation ne sont pas toujours repris automatiquement par l'unité systemd équivalente. Le service reste installé, fonctionnel une fois lancé à la main, mais silencieusement absent de la séquence de démarrage.
• Un problème d'ordonnancement des unités systemd. Si l'unité du pare-feu démarre avant que les interfaces réseau ne soient pleinement disponibles (absence de After=network-online.target et Wants=network-online.target dans son fichier d'unité), elle peut se lancer, échouer silencieusement à appliquer ses règles sur des interfaces pas encore prêtes, et laisser croire que tout va bien alors que rien n'est filtré.

Dans les quatre cas, le symptôme est identique : après un redémarrage, le pare-feu est absent ou inactif, et le service qu'il était censé protéger se retrouve en accès libre.

#2. Comment détecter ce type d'exposition

Comme le service concerné n'a pas d'authentification propre, rien n'alerte de l'intérieur : pas de tentative de connexion refusée, pas de mot de passe erroné, pas de blocage. Les signaux qui doivent alerter sont ailleurs :

• Un volume de requêtes ou un trafic réseau inhabituel sur le port du service, visible dans les journaux applicatifs ou les métriques réseau
• Des adresses IP inconnues, hors du périmètre habituel de l'entreprise, dans les journaux d'accès du service
• Une alerte externe : un chercheur en sécurité, un client, ou un partenaire qui signale avoir pu accéder à des données qui n'auraient pas dû être publiques
• Lors d'un contrôle de routine après une opération de maintenance : le pare-feu apparaît arrêté (systemctl status renvoie inactive ou dead) alors qu'il tournait avant le dernier redémarrage
• Un signalement via les outils publics de cartographie d'Internet, qui indexent en continu les services exposés sans authentification

#3. La réponse en urgence : la méthode en trois temps

Face à ce type d'exposition, la réponse suit une logique en trois étapes distinctes : arrêter l'exposition en cours, corriger la cause pour qu'elle ne revienne pas au prochain redémarrage, et enfin mettre en place une protection qui ne dépende plus d'une seule barrière.

#3.1 Diagnostic et arrêt de l'hémorragie

La priorité absolue est de refermer l'exposition. Concrètement :

1. Vérifier l'état réel du pare-feu (systemctl status shorewall, ou l'équivalent pour ufw/iptables-persistent selon l'outil en place).
2. Le relancer immédiatement (systemctl start shorewall) pour couper l'accès public au service en quelques secondes.
3. Analyser les journaux d'accès du service exposé sur toute la fenêtre pendant laquelle le pare-feu était inactif : quelles adresses IP se sont connectées, quel volume de données a été lu, si des actions d'écriture ou de suppression ont eu lieu.

Cette dernière étape conditionne la suite : si des données personnelles étaient accessibles pendant la fenêtre d'exposition, l'article 33 du RGPD impose une notification à la CNIL dans les 72 heures suivant la découverte, via notifications.cnil.fr. Le délai court dès la découverte, pas depuis la correction complète : mieux vaut une notification initiale documentée qu'un dépassement du délai.

#3.2 Correctif durable : empêcher la rechute au prochain redémarrage

Relancer le pare-feu referme la porte pour l'instant, mais ne garantit rien pour le prochain reboot si la cause n'est pas corrigée. Cette étape consiste à :

• Identifier précisément pourquoi le service ne redémarre pas seul (service jamais activé, variable de configuration héritée, migration d'init incomplète, ordonnancement d'unité incorrect).
• Activer le service de façon persistante avec systemctl enable, et vérifier avec systemctl is-enabled que l'activation est bien prise en compte.
• Corriger, le cas échéant, les variables de configuration héritées d'anciennes installations (comme startup=1 dans /etc/default/shorewall sur les configurations Debian historiques).
• Vérifier l'ordonnancement des unités systemd concernées pour que le pare-feu ne démarre qu'une fois le réseau réellement disponible.

#3.3 Garde-fou et défense en profondeur

Cette dernière étape est celle qui a le plus de valeur à long terme, et c'est aussi celle qui est le plus souvent négligée une fois l'urgence passée.

Un garde-fou de surveillance. Une tâche planifiée (cron) ou un agent de supervision qui vérifie en continu que le pare-feu tourne, et qui alerte, voire relance le service automatiquement, s'il venait à s'arrêter. Ce type de contrôle transforme une exposition qui pourrait durer plusieurs jours en un incident détecté et corrigé en quelques minutes.

La défense en profondeur, le vrai correctif de fond. Le pare-feu est un contrôle de périmètre : il filtre qui peut atteindre le service, mais ne protège rien une fois franchi, désactivé ou mal configuré. Un service de données critique ne devrait jamais reposer sur cette seule barrière. Concrètement :

• Activer l'authentification native du service quand elle existe (fonctions de sécurité intégrées d'Elasticsearch ou d'une autre base, comptes et mots de passe applicatifs).
• À défaut d'authentification native suffisante, placer le service derrière un proxy imposant une authentification, ou le faire écouter uniquement sur une interface privée (localhost, réseau interne, VPN), jamais directement sur une interface publique.
• Considérer le pare-feu comme une couche de protection supplémentaire, pas comme la seule ligne de défense.

#4. Ce qu'il ne faut pas faire

• Ne pas se contenter de relancer le pare-feu sans comprendre pourquoi il s'est arrêté : sans correction de la cause, le problème revient, parfois plusieurs mois plus tard, au prochain redémarrage.
• Ne pas considérer un service comme protégé au seul motif qu'il est "censé être" derrière un pare-feu, sans avoir vérifié s'il dispose d'une authentification propre.
• Ne pas ignorer la fenêtre d'exposition passée sous prétexte que le service est refermé : il faut établir depuis combien de temps l'exposition durait et si des requêtes suspectes ont eu lieu, pour qualifier correctement l'incident.
• Ne pas repousser la notification CNIL si des données personnelles étaient accessibles : le délai de 72 heures court dès la découverte, pas depuis la correction technique complète.
• Ne pas traiter l'incident comme clos une fois le pare-feu relancé et activé au démarrage : sans authentification sur le service lui-même, la même famille de problème peut se reproduire sous une autre forme (erreur de règle, nouvelle interface réseau, changement d'hébergeur).

#5. Quand faire appel à un professionnel

Certaines situations dépassent ce qu'une équipe interne peut diagnostiquer et corriger seule dans l'urgence :

• Vous ne savez pas depuis combien de temps le service était exposé, ni identifier précisément ce qui a été consulté
• Le service concerné contient des données personnelles ou des données sensibles pour l'entreprise
• Vous devez documenter l'incident pour une assurance cyber, un partenaire, ou une notification à la CNIL
• Vous n'êtes pas certain que la correction appliquée tiendra réellement au prochain redémarrage
• Vous souhaitez un audit plus large pour vérifier qu'aucun autre service de l'infrastructure ne repose sur le même schéma de protection unique

#6. L'intervention M-KIS

L'Équipe M-KIS intervient sur ce type d'exposition selon la même méthode en trois temps détaillée plus haut, appliquée concrètement à votre infrastructure :

1. Diagnostic et arrêt de l'hémorragie : vérification de l'état du pare-feu et des services exposés, remise en protection immédiate, analyse des journaux d'accès pour qualifier la fenêtre d'exposition.
2. Correctif durable : identification de la cause exacte de la non-persistance au démarrage, correction et vérification par un redémarrage réel du serveur.
3. Garde-fou et défense en profondeur : mise en place d'une surveillance continue du pare-feu, et surtout, ajout d'une authentification sur le service de données concerné, pour qu'une seule barrière défaillante ne suffise plus jamais à exposer vos données.

Cette méthode s'inscrit dans notre offre de réponse à incident et intervention curative. Pour un suivi continu de ce type de dérive de configuration une fois l'incident refermé, notre SOC managé Wazuh open source surveille en continu l'état des services critiques de votre infrastructure, sans dépendance à des outils propriétaires cloud américains.

Équipe M-KIS : vous suspectez une exposition de ce type, ou souhaitez simplement vérifier qu'aucun service critique de votre infrastructure ne repose sur une seule barrière de protection, contactez-nous par mail à [email protected]. Nous répondons rapidement pour qualifier la situation et organiser, si nécessaire, une intervention.

Récapitulatif de la méthode, dans l'ordre :

1. Vérifier l'état du pare-feu et le relancer immédiatement s'il est arrêté
2. Analyser les journaux d'accès pour qualifier la fenêtre et l'ampleur de l'exposition
3. Notifier la CNIL sous 72 heures si des données personnelles étaient accessibles
4. Identifier la cause exacte de la non-persistance au démarrage et la corriger
5. Vérifier la correction par un redémarrage réel du serveur, pas un simple redémarrage de service
6. Mettre en place une surveillance continue du pare-feu
7. Ajouter une authentification sur le service de données lui-même, pour ne plus dépendre d'une seule barrière