Ces chiffres qui devraient vous empêcher de dormir

Commençons par un chiffre qui ne laisse aucune place au doute : parmi 2 931 bases de données MySQL exposées scannées récemment, 2 930 étaient déjà ciblées par des opérateurs de ransomware. Ce n'est pas une prédiction. Ce n'est pas un "ça pourrait arriver". C'est un constat de ciblage confirmé.

Le pourcentage ? Lâchez le mot : 99,96 %.

Si vous pensiez qu'une base de données exposée pouvait passer inaperçue, tranquillement oubliée sur l'internet jusqu'à ce que quelqu'un tombe dessus par hasard, ces données réduisent cette illusion en poussière. Les acteurs malveillants n'attendent pas. Ils observent.

Un playbook vieux de six ans qui fonctionne toujours aussi bien

Le plus perturbant ? Le playbook utilisé n'a rien de sophistiqué. Pas de chaîne d'attaque zero-day dernier cri. C'est essentiellement la même méthodologie qui circule depuis 2019-2020.

Concrètement, on parle de :

• Scanning automatisé des ports de base de données exposés (3306 pour MySQL)
• Credential stuffing avec des identifiants par défaut ou faibles
• Énumération de la base pour identifier les cibles à forte valeur
• Exfiltration silencieuse des données avant chiffrement
• Déploiement de ransomware avec des délais de plus en plus agressifs

Les outils ont mûri. L'automatisation s'est perfectionnée. Mais le point d'entrée principal ? La mauvaise configuration. Des ports ouverts. Des environnements de test oubliés, toujours connectés au réseau public.

Ce n'est pas l'œuvre d'acteurs étatiques sophistiqués. C'est du scanning opportuniste à échelle industrielle, exécuté par des groupes qui ont transformé le compromis de bases de données en modèle économique efficace.

Pourquoi les bases exposées sont des cibles faciles

Vous pourriez vous demander : si c'est si connu, pourquoi est-ce que les bases restent exposées ?

La réponse est trompeusement simple :

1. La commodité du développeur – En local, les ports ouverts facilitent l'accès. Parfois, on passe en production avec ces paramètres intacts.

2. Les erreurs de config cloud – Les instances cloud publiques démarrent souvent avec des groupes de sécurité permissifs "juste pour tester".

3. Les environnements de test oubliés – Ce serveur staging de 2022 ? Il tourne toujours. Il est toujours exposé.

4. Le manque de visibilité – Les équipes ne savent tout simplement pas ce qui est exposé sur l'internet.

5. L'hypothèse d'invisibilité – "Qui nous ciblerait ?" La réponse : des bots automatisés qui ne font pas de discrimination.

Ce que ça signifie pour votre infrastructure

Si vous utilisez des bases MySQL — que ce soit pour votre application, vos analytiques ou vos données clients — traitez les instances exposées comme compromises, même sans signe visible d'intrusion.

Le playbook de l'attaquant part de ces hypothèses :

• Les bases sont peu surveillées
• Les backups se trouvent sur le même système compromis
• Les organisations paniqueront et paieront plutôt que de restaurer depuis des backups vérifiés
• Les temps de détection et réponse sont assez longs pour que le chiffrement en vaille la peine

Et ils n'ont pas tort, dans bien des cas.

Actions immédiates à prendre

Auditez votre exposition :

• Utilisez des outils comme Shodan, Censys ou BinaryEdge pour vérifier si vos IP apparaissent dans les bases de scan internet
• Passez en revue les groupes de sécurité et ACL réseau de votre provider cloud
• Assurez-vous qu'aucun port de base n'est accessible depuis 0.0.0.0/0

Durcissez l'authentification :

• Imposez des mots de passe forts et uniques pour tous les comptes base
• Mettez en place de l'allowlisting IP partout où c'est possible
• Envisagez du tunneling de connexion via VPN ou bastion host plutôt que l'exposition directe

Vérifiez votre stratégie de backup :

• Les backups sont-ils stockés hors ligne ou dans une zone de sécurité séparée ?
• Quand a eu lieu le dernier test de restauration réussi ?
• Dissez-vous de la capacité de recovery à un point dans le temps ?

Activez la journalisation et la surveillance :

• Les logs d'audit doivent capturer les tentatives de connexion, les requêtes et les actions administratives
• Configurez des alertes pour les patterns d'accès inhabituels ou l'export massif de données
• Envisagez des solutions DAM (Database Activity Monitoring)

Le tableau de fond : la sécurité comme infrastructure

Ce n'est pas juste un problème de base de données. C'est un rappel que la sécurité doit être traitée comme une infrastructure fondamentale, pas comme une réflexion après coup.

Chez NameOcean, on voit ce pattern en boucle — startups et développeurs qui vont vite, qui livrent des features, et qui exposent accidentellement leur infrastructure. La pression pour itérer rapidement est réelle, mais le coût d'un incident ransomware ou d'une fuite de données dépasse largement les heures d'ingénierie nécessaires pour sécuriser correctement les choses dès le départ.

Votre registrar de domaine, votre hébergeur, votre configuration DNS — ce sont autant de points d'entrée qui méritent la même rigueur que vous appliquez (normalement) à votre couche base de données.

Conclusion : supposez que vous êtes observé

Les 2 930 bases identifiées ne sont pas des anomalies. Elles sont représentatives d'une réalité plus large : si votre base est exposée à l'internet, elle est déjà sur le radar de quelqu'un.

Le playbook a six ans parce qu'il fonctionne. Ne laissez pas la familiarité avec ces méthodes d'attaque vous endormir sur vos lauriers. Utilisez-la plutôt comme motivation pour agir.

Auditez votre exposition. Verrouillez les accès. Vérifiez vos backups. Et souvenez-vous : dans le paysage de menaces actuel, l'invisibilité n'est pas une stratégie de sécurité.

Restez vigilants.

Des questions sur la sécurisation de votre infrastructure base ou votre environnement d'hébergement ? Laissez-les en commentaire — on est là pour vous aider à construire de manière sécurisée dès le départ.