Un rançongiciel moderne ne chiffre plus votre serveur dès son entrée. Il fait d’abord quelque chose de bien plus intelligent : il cherche vos sauvegardes. Il sait que s’il laisse votre historique intact, vous restaurerez et ne paierez pas. La bonne question n’est donc pas de savoir si vous avez des sauvegardes, mais si votre propre serveur peut les toucher.
Comment se déroule une vraie attaque
Le schéma se répète. L’attaquant entre par un identifiant volé, une vulnérabilité non corrigée ou une pièce jointe. Puis, au lieu de chiffrer immédiatement, il reste silencieux pendant des semaines à explorer le réseau : quels serveurs existent, où sont les données importantes, et surtout où sont les sauvegardes et avec quels identifiants on y accède.
Quand il décide d’agir, l’ordre est toujours le même : détruire ou chiffrer l’historique des sauvegardes, puis chiffrer les données de production, et seulement ensuite afficher la demande de rançon. Quand vous l’apprenez, vous n’avez plus où revenir.
Le défaut de conception que presque tous ont
Voici le point qui change tout. Dans la plupart des installations, le serveur de production détient des identifiants pour écrire sur le stockage de sauvegarde, puisque c’est lui qui les envoie. Cela paraît raisonnable, et c’est exactement la porte d’entrée.
Si le serveur peut écrire, supprimer ou écraser à destination, tout attaquant qui le contrôle hérite de cette capacité. Il n’a rien d’autre à découvrir : il a déjà la clé, rangée dans un fichier de configuration.
Les rustines qui ne suffisent pas
Chiffrer les sauvegardes ne résout rien : un attaquant n’a pas besoin de les lire, les supprimer suffit. Un second disque non plus, s’il est monté sur le même système. Et des sauvegardes cloud avec des identifiants d’écriture stockés sur le serveur sont aussi vulnérables qu’un disque local.
Le modèle qui fonctionne : inverser le sens
La défense est conceptuellement simple : que le serveur de sauvegarde vienne chercher les données, au lieu que le serveur de production les envoie.
Avec ce changement, les identifiants existants sont en lecture seule sur votre source, et ils vivent sur le système de sauvegarde, pas sur le serveur exposé. Un attaquant qui contrôle votre production peut ravager la source, mais n’a aucune route vers l’historique : pas d’identifiants, et le pare-feu empêche l’ouverture d’une connexion dans ce sens.
Le pire qui puisse arriver alors, c’est de perdre les données vivantes, ce qui est exactement le scénario pour lequel les sauvegardes existent.
Les signaux qui trahissent une attaque avant la rançon
Un bon système de sauvegarde est aussi un détecteur précoce, car il voit des choses que l’administrateur ne regarde pas chaque jour :
- La sauvegarde la plus récente vieillit. Si la dernière a plus de 36 heures, quelque chose s’est arrêté sans que personne ne le remarque.
- Zéro nouveau bloc pendant plusieurs jours. Les données chiffrées par un attaquant changent complètement : ce symptôme signifie généralement que la sauvegarde ne s’exécute plus, pas qu’il n’y a aucun changement.
- L’espace occupé diminue sans nettoyage programmé. Quelqu’un supprime de l’historique.
Les deux derniers sont des signatures classiques d’une attaque en cours, et un prestataire attentif peut vous alerter avant l’apparition de la demande de rançon.
Ce qu’il faut vérifier chez vous cette semaine
Ouvrez la configuration de vos sauvegardes et répondez honnêtement : votre serveur de production détient-il des identifiants pour modifier la destination des sauvegardes ? Un processus avec droits d’administrateur sur ce serveur pourrait-il supprimer l’historique ? Quelqu’un surveille-t-il que les sauvegardes continuent d’arriver ? À quand remonte votre dernière restauration ?
Si une réponse vous met mal à l’aise, vous savez par où commencer.
Notre conception
Dans nos services de sauvegarde, c’est toujours nous qui ouvrons la connexion, avec des identifiants en lecture seule sur votre source, et le pare-feu refuse explicitement toute connexion en sens inverse. La détection de panne silencieuse est incluse et surveille les trois signaux ci-dessus. Le tout dans deux centres de données en propre en Andorre.