Réponse Ransomware ZFS : le guide des snapshots qui vous sauve

À quoi ressemble un ransomware sur ZFS (et ce qu’il n’est pas)

Le ransomware n’est pas une chose unique. Sur le stockage, il se présente typiquement dans l’un de ces cas :

• Ransomware qui chiffre des fichiers : parcourt un arbre de fichiers et réécrit des fichiers (ou écrit de nouvelles copies chiffrées puis supprime les originaux). Sur ZFS, cela se traduit principalement par des écritures aléatoires et un fort turnover des métadonnées.
• Comportement de type wiper : supprime, tronque, écrase. Même effet : le dataset en ligne devient inutilisable.
• Attaquant avec identifiants : le pire des cas. Ils n’ont pas besoin de malwares sophistiqués. Ils se connectent comme vous (ou votre automatisation) et lancent des commandes destructrices : suppression de snapshots, destruction de datasets, arrêt de la réplication.
• Compromission de l’hyperviseur/VM : chiffrement à l’intérieur de la machine virtuelle. ZFS voit de grosses écritures vers des zvols ou images VM, pas des fichiers individuels.
• Compromission de la cible de sauvegarde : l’attaquant touche le système qui stocke vos « sauvegardes », et les chiffre aussi. Si votre machine ZFS est la cible de sauvegarde et qu’elle est modifiable depuis l’environnement infecté, félicitations : vous avez construit un auto-sabotage haute performance.

Les snapshots ZFS aident surtout dans les deux premiers cas. Ils aident dans le troisième seulement si la suppression de snapshots est contrainte et que la réplication a un espace de sécurité. Si les attaquants peuvent supprimer les snapshots et les copies répliquées, vos snapshots ne sont plus qu’une histoire rassurante que vous vous racontez.

Une citation à garder en tête quand la situation s’échauffe : L’espoir n’est pas une stratégie. — idée souvent paraphrasée attribuée au management des opérations. Le point tient même si l’attribution est floue : l’espoir ne passe pas les audits et ne restaure pas les données.

Sémantique des snapshots : pourquoi ça marche

Les snapshots ZFS sont des vues à un instant donné d’un dataset. Ils sont peu coûteux parce que ZFS utilise le copy-on-write : les nouvelles écritures allouent de nouveaux blocs ; les blocs existants référencés par un snapshot restent en place. C’est l’avantage central : le ransomware peut réécrire le dataset en direct autant qu’il veut ; votre snapshot pointe toujours vers les anciens blocs.

Deux écueils : les snapshots ne sont pas magiques et ils ne sont pas immuables par défaut. Si un attaquant (ou un outil d’automatisation mal configuré) peut exécuter zfs destroy pool/ds@snap, vos « sauvegardes immuables » deviennent une « curiosité historique ». Aussi : les snapshots conservent des états corrompus mais cohérents. Si le ransomware chiffre proprement vos fichiers, les snapshots conservent la vue pré-chiffrement, mais seulement si vous avez un snapshot pris avant le début du chiffrement.

Décisions du modèle de menace qui comptent

• Supposez que les identifiants sont compromis jusqu’à preuve du contraire. Votre hôte de restauration ne doit pas faire confiance à l’hôte infecté.
• Préférez restaurer ailleurs plutôt que restaurer sur place pour les systèmes critiques si vous le pouvez. Cela vous offre des éléments de forensic et réduit le risque de réinfection.
• La réplication est votre « air gap » seulement si elle n’est pas continuellement modifiable et supprimable depuis le même plan de contrôle.

Faits et historique qui changent votre réaction

Ce ne sont pas des trivia. Ce sont les petites vérités qui déterminent si votre récupération sera un succès ou un post-mortem.

1. Les snapshots ZFS sont arrivés tôt et sont restés curieusement sous-utilisés. Sun a introduit ZFS au milieu des années 2000 avec les snapshots comme fonctionnalité de première classe, bien avant que « ransomware » ne devienne un mot de conseil d’administration.
2. Le copy-on-write est à la fois le superpouvoir et le piège de performance. Il rend les snapshots peu coûteux, mais des réécritures aléatoires soutenues (bonjour le ransomware) peuvent fragmenter l’espace libre et augmenter la latence.
3. La suppression de snapshots peut être coûteuse. Détruire de gros snapshots anciens peut déclencher un travail massif sur les space maps et l’I/O, ce qui compte en plein incident quand vous essayez de restaurer rapidement.
4. Le « send/receive » ZFS peut être une machine à remonter le temps forensique. Vous pouvez répliquer l’état incrémental et reconstruire des timelines, pas seulement restaurer des données.
5. Les opérateurs de ransomware sont passés à la double extorsion. Les incidents modernes impliquent souvent vol de données plus chiffrement. Les snapshots règlent le chiffrement ; ils n’annulent pas l’exfiltration.
6. Les attaquants ont appris à cibler les sauvegardes. La dernière décennie les a poussés vers la suppression des shadow copies, des snapshots VSS, des catalogues de sauvegarde — et oui, des snapshots ZFS si elles sont accessibles.
7. Des politiques de snapshots immuables existent, mais ce sont des choix opérationnels. Sur certaines plateformes, vous pouvez configurer des holds, des permissions déléguées ou des domaines d’administration séparés. Rien n’est automatique ; tout demande de la discipline.
8. Le chiffrement peut aider et nuire. Le chiffrement natif ZFS protège contre le vol de disques bruts et peut limiter certaines analyses forensiques, mais il n’empêche pas un ransomware s’exécutant en tant qu’utilisateur pouvant lire/écrire des fichiers.
9. Les restaurations rapides exigent une planification d’espace libre. Le meilleur snapshot du monde est inutile si vous ne pouvez pas le monter, le cloner ou le recevoir parce que votre pool est à 95% et en colère.

Blague #1 (courte, pertinente) : Le ransomware est la seule charge de travail qui fait soudainement apprécier à tout le monde l’ingénierie de stockage « ennuyeuse ». C’est comme un audit surprise, mais avec plus de grossièretés.

La première heure : contenir, préserver, décider

Dans la première heure vous ne « restaurez » pas. Vous achetez des options.

1) Contenir l’ampleur

Si le chiffrement est en cours, chaque minute compte. Coupez le chemin d’écriture. Cela peut signifier :

• Déconnecter les exports SMB/NFS du réseau.
• Arrêter les services applicatifs qui écrivent sur les datasets affectés.
• Désactiver les comptes compromis ou révoquer les jetons.
• Quarantaine de l’hôte au niveau du switch ou du firewall.

La contention bat l’ingéniosité. Si vous ne pouvez pas arrêter les écritures, vous ne pouvez pas faire confiance à la timeline.

2) Préserver les preuves sans ralentir excessivement la récupération

Vous avez besoin de suffisamment de preuves pour répondre à « comment sont-ils entrés ? » et « jusqu’où cela a-t-il été ? » sans transformer cela en foire scientifique forensique. Un compromis pratique :

• Prendre un nouveau snapshot des datasets affectés immédiatement (oui, même si les données sont corrompues). Vous figez l’état courant pour une analyse ultérieure.
• Exporter les logs (logs d’auth, logs SMB, logs applicatifs) hors de l’hôte.
• Si vous répliquez, mettre en pause et copier l’état courant de la réplication pour examen ultérieur ; ne pas écraser l’historique propre.

3) Décider du mode de récupération

Vous avez trois grands schémas :

• Rollback sur place : rapide, risqué. Bon pour des partages de fichiers simples si vous êtes confiant que l’hôte est propre et que vous connaissez le bon snapshot.
• Cloner le snapshot et servir le clone : plus sûr. Vous pouvez monter le clone en lecture seule initialement, valider, puis basculer.
• Restaurer sur un système propre ailleurs : le plus sûr. Prend plus de temps et nécessite de la capacité, mais réduit le risque de réinfection et préserve le système compromis pour l’investigation.

Ma préférence : pour tout ce qui exécute du code (serveurs CI, serveurs applicatifs avec volumes modifiables, datastores VM), restaurer ailleurs. Pour des partages de fichiers « bêtes » avec une bonne hygiène d’identité, les clones sont un bon compromis.

Playbook de diagnostic rapide (triage par goulot)

Voici la liste « que vérifier en premier, deuxième, troisième » quand tout le monde vous regarde et que vous devez arrêter de deviner.

Première étape : l’attaquant écrit-il encore ?

• Regardez s’il y a des I/O d’écriture soutenues et du turnover de fichiers sur les datasets affectés.
• Confirmez si des clients SMB/NFS sont encore connectés et modifient activement des données.
• Décision : si les écritures sont en cours, isolez ou arrêtez les services avant toute autre action.

Deuxième étape : avez-vous encore des snapshots propres ?

• Listez les snapshots récents et vérifiez que vous disposez d’une timeline couvrant avant le début présumé du chiffrement.
• Vérifiez si des snapshots ont été supprimés récemment (trous inattendus).
• Décision : si l’historique de snapshots manque, basculez immédiatement vers la réplication/hors site ou autres sauvegardes ; ne perdez pas de temps à planifier un rollback impossible.

Troisième étape : quel est votre goulot de restauration — CPU, disque, réseau ou espace ?

• Espace : utilisation du pool et fragmentation ; si vous êtes près du plein, les clones/receives peuvent échouer.
• Disque : latence élevée, resilvering ou erreurs ; restaurer sur un pool mourant est une lente tragédie.
• Réseau : réplication ou restauration sur des liens ; mesurez le débit et la perte de paquets.
• CPU : chiffrement/compression peut limiter les vitesses send/receive ; vérifiez si vous êtes lié par le CPU.
• Décision : choisissez rollback vs clone vs restaurer-ailleurs en fonction de la contrainte. Si l’espace est serré, le rollback peut être la seule option ; si l’hôte est suspect, restaurez ailleurs même si c’est plus lent.

Quatrième étape : valider la propreté sans se réinfecter

• Montez d’abord les snapshots/clones candidats en lecture seule.
• Scannez à la recherche de motifs connus de ransom note, de nouvelles extensions et d’exécutables/scripts récemment modifiés dans les chemins partagés.
• Décision : choisissez le point de restauration où les données métier sont intactes et les artefacts malveillants absents (ou au moins compris).

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les commandes que vous exécutez réellement, avec des sorties réalistes et ce que vous faites ensuite. Les noms d’hôtes et de pools sont des exemples ; gardez les vôtres cohérents. L’incident suppose le pool tank avec les datasets tank/share et tank/vm.

Tâche 1 : confirmer la santé du pool (ne restaurez pas sur une plateforme en feu)

cr0x@server:~$ zpool status -x
all pools are healthy

Ce que cela signifie : Pas d’erreurs de device connues ni de resilvering en cours.

Décision : Poursuivre. Si vous voyez DEGRADED, FAULTED ou un resilvering, prévoyez des restaurations plus lentes et considérez une restauration sur un autre matériel.

Tâche 2 : vérifier la capacité du pool et le risque de fragmentation

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap,health
NAME  SIZE  ALLOC   FREE  FRAG  CAP  HEALTH
tank  54.5T  41.8T  12.7T   41%  76%  ONLINE

Ce que cela signifie : 76% utilisé, fragmentation modérée. Pas idéal, pas fatal.

Décision : Les clones et receives devraient fonctionner. Si CAP > 90%, attendez-vous à des échecs et priorisez le rollback ou ajoutez de la capacité d’abord.

Tâche 3 : identifier quels datasets sont frappés

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME        USED   AVAIL  REFER  MOUNTPOINT
tank        41.8T  11.9T   128K  /tank
tank/share   8.4T  11.9T   8.4T  /srv/share
tank/vm     31.2T  11.9T  31.2T  /srv/vm

Ce que cela signifie : tank/vm est énorme ; si des VM sont impactées, le temps de restauration sera dominé par cet espace.

Décision : Scinder l’incident : les partages de fichiers peuvent se récupérer rapidement ; le datastore VM peut nécessiter une approche différente (restaurer un sous-ensemble, prioriser les VM critiques).

Tâche 4 : surveiller l’I/O en temps réel pour confirmer que le chiffrement est actif

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        41.8T  12.7T    410   8120   32.1M  1.02G
  raidz2-0                  41.8T  12.7T    410   8120   32.1M  1.02G
    sda                         -      -     52   1015   4.0M  128M
    sdb                         -      -     51   1010   4.1M  127M
    sdc                         -      -     51   1012   4.0M  128M
    sdd                         -      -     51   1012   4.0M  128M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Écritures soutenues importantes. Si ce n’est pas une fenêtre de charge connue, supposez un chiffrement actif ou une réécriture de masse.

Décision : Contenir : désactiver les partages, arrêter les services, mettre l’hôte en quarantaine. Ne pas lancer de rollback tant que des écritures sont en cours.

Tâche 5 : lister les snapshots et repérer les trous

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -s creation | tail -n 8
tank/share@auto-2025-12-26-0700  Fri Dec 26 07:00 2025   56M
tank/share@auto-2025-12-26-0800  Fri Dec 26 08:00 2025   60M
tank/share@auto-2025-12-26-0900  Fri Dec 26 09:00 2025   58M
tank/share@auto-2025-12-26-1000  Fri Dec 26 10:00 2025   62M
tank/share@auto-2025-12-26-1100  Fri Dec 26 11:00 2025   59M
tank/share@auto-2025-12-26-1200  Fri Dec 26 12:00 2025   61M
tank/share@auto-2025-12-26-1300  Fri Dec 26 13:00 2025   63M
tank/share@auto-2025-12-26-1400  Fri Dec 26 14:00 2025   65M

Ce que cela signifie : Des snapshots horaires réguliers existent jusqu’à 14:00. Bon signe.

Décision : Identifiez quand le chiffrement a commencé ; choisissez le snapshot juste avant. S’il y a un trou (heures/jours manquants), suspectez une suppression de snapshots ou une automatisation défaillante — basculez sur la réplication/hors site.

Tâche 6 : prendre un snapshot « scène de crime » maintenant

cr0x@server:~$ zfs snapshot -r tank/share@incident-2025-12-26T1425Z
cr0x@server:~$ zfs list -t snapshot -o name,creation | grep incident | tail -n 2
tank/share@incident-2025-12-26T1425Z  Fri Dec 26 14:25 2025

Ce que cela signifie : Vous avez figé l’état courant pour une analyse ultérieure.

Décision : Conservez-le. Ne supprimez pas de snapshots « mauvais » pendant la réponse à l’incident ; ils seront précieux pour la sécurité/juridique.

Tâche 7 : vérifier les holds de snapshot (et en ajouter un quand il faut préserver)

cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  -     -
cr0x@server:~$ zfs hold keep tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  keep  Fri Dec 26 14:28 2025

Ce que cela signifie : Un hold empêche la suppression accidentelle de ce snapshot jusqu’à sa libération explicite.

Décision : Placez des holds sur vos snapshots « dernier connu bon » candidats avant de commencer toute manipulation.

Tâche 8 : confirmer ce qui a changé récemment (triage à fort signal)

cr0x@server:~$ zfs diff -H tank/share@auto-2025-12-26-1200 tank/share@auto-2025-12-26-1400 | head
M	/srv/share/finance/Q4.xlsx
M	/srv/share/finance/Q4.xlsx.locked
+	/srv/share/READ_ME_NOW.txt
M	/srv/share/projects/roadmap.docx
M	/srv/share/projects/roadmap.docx.locked

Ce que cela signifie : Vous voyez des marqueurs typiques de ransomware : nouvelle note de rançon, fichiers réécrits, nouvelles extensions.

Décision : Choisissez un snapshot antérieur à l’apparition de ces artefacts. Si les artefacts apparaissent sur de nombreux snapshots, le chiffrement a commencé plus tôt que prévu.

Tâche 9 : inspecter un snapshot sans rien modifier

cr0x@server:~$ ls -la /srv/share/.zfs/snapshot/auto-2025-12-26-1200 | head
total 12
drwxr-xr-x   9 root root    9 Dec 26 12:00 .
drwxr-xr-x  10 root root   10 Dec 26 14:00 ..
drwxr-xr-x  12 root root   12 Dec 20 09:10 finance
drwxr-xr-x  34 root root   34 Dec 24 17:03 projects

Ce que cela signifie : Les snapshots sont visibles via le répertoire .zfs (si activé et non masqué par les paramètres de partage).

Décision : Utilisez la navigation des snapshots pour une validation rapide. Si vous êtes sur une plateforme où .zfs n’est pas exposé, montez un clone à la place.

Tâche 10 : cloner un snapshot pour validation en lecture seule

cr0x@server:~$ zfs clone -o mountpoint=/mnt/restore_share -o readonly=on tank/share@auto-2025-12-26-1200 tank/share-restore
cr0x@server:~$ zfs get -o name,property,value readonly,mountpoint tank/share-restore
NAME              PROPERTY    VALUE
tank/share-restore  readonly    on
tank/share-restore  mountpoint  /mnt/restore_share

Ce que cela signifie : Vous avez maintenant un clone monté en lecture seule pour validation et scan.

Décision : Validez le contenu et contrôlez des répertoires critiques. Si c’est propre, planifiez la bascule : promouvoir le clone ou rsync les données vers une destination propre.

Tâche 11 : rollback sur place (uniquement quand vous acceptez le risque)

cr0x@server:~$ zfs rollback -r tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs list -o name,used,refer,mountpoint tank/share
NAME        USED  REFER  MOUNTPOINT
tank/share  8.1T  8.1T  /srv/share

Ce que cela signifie : L’état du dataset est revenu à ce snapshot ; -r effectue le rollback des descendants aussi.

Décision : Utilisez ceci uniquement lorsque vous avez fermé la voie d’accès de l’attaquant et que vous êtes sûr d’avoir choisi le bon snapshot. Le rollback est rapide, mais il supprime les changements plus récents. Assurez-vous que l’entreprise accepte la fenêtre de perte de données.

Tâche 12 : identifier ce qui retient de l’espace (pourquoi « df » ment pendant les snapshots)

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren tank/share
NAME        USED  USEDSNAP  USEDDATA  USEDCHILD
tank/share  8.4T     1.1T     7.3T       0B

Ce que cela signifie : Les snapshots immobilisent 1.1T de blocs. Ce n’est pas du « gaspillage » ; c’est votre filet de sécurité.

Décision : Ne supprimez pas de snapshots pour « libérer de l’espace » en plein incident sauf si vous avez des sauvegardes hors site vérifiées et que vous êtes sur le point d’atteindre une panne critique.

Tâche 13 : vérifier l’état de la réplication (le hors-site est-il propre et à jour ?)

cr0x@server:~$ zfs get -H -o value receive_resume_token tank/share
-
cr0x@server:~$ zfs list -t snapshot -o name -s creation -r tank/share | tail -n 3
tank/share@auto-2025-12-26-1200
tank/share@auto-2025-12-26-1300
tank/share@auto-2025-12-26-1400

Ce que cela signifie : Aucun resume token n’indique qu’aucun receive interrompu n’existe de ce côté ; la chaîne de snapshots existe localement.

Décision : Sur votre cible de réplication, confirmez qu’elle possède des snapshots antérieurs à l’infection et que les permissions de suppression sont restreintes. Si la cible est « trop synchronisée », vous avez peut-être répliqué des données chiffrées aussi — cherchez des points plus anciens.

Tâche 14 : faire un send/receive contrôlé vers un nouveau dataset

cr0x@server:~$ zfs send -R tank/share@auto-2025-12-26-1200 | zfs receive -u tank/restored/share
cr0x@server:~$ zfs list -o name,mountpoint -r tank/restored
NAME                MOUNTPOINT
tank/restored        /tank/restored
tank/restored/share  /tank/restored/share

Ce que cela signifie : Vous avez restauré une copie à un instant donné dans un arbre de datasets séparé, sans écraser l’original.

Décision : Privilégiez ceci quand vous avez besoin d’une séparation propre et que vous avez de l’espace. Vous pouvez ensuite pointer les exports vers le dataset restauré après validation.

Tâche 15 : confirmer les propriétés du dataset qui impactent la vitesse et la cohérence de la récupération

cr0x@server:~$ zfs get -o name,property,value compression,recordsize,atime,sync tank/share
NAME       PROPERTY     VALUE
tank/share compression  lz4
tank/share recordsize   1M
tank/share atime        off
tank/share sync         standard

Ce que cela signifie : Ces paramètres affectent la performance et le comportement de la charge. Pour les workloads de type VM, recordsize et sync sont particulièrement pertinents.

Décision : Ne modifiez pas ces paramètres pendant l’incident à moins de savoir exactement pourquoi. Le « tuning en pleine panne » est un hobby pour ceux qui aiment les conséquences surprises.

Tâche 16 : vérifier les risques du modèle de permissions (qui peut détruire des snapshots ?)

cr0x@server:~$ zfs allow tank/share
---- Permissions on tank/share ---------------------------------------
Local+Descendent permissions:
user backupsvc create,destroy,mount,snapshot,send,receive
user appsvc   mount

Ce que cela signifie : L’utilisateur backupsvc peut détruire des snapshots. C’est un identifiant de grande valeur.

Décision : Dans la phase de durcissement post-incident, retirez destroy sauf si absolument requis, et séparez les rôles de création de snapshot et de destruction.

Stratégies de restauration : rollback, clone et « restaurer ailleurs »

Stratégie A : rollback sur place (la plus rapide, la plus tranchante)

Le rollback est une massue. C’est aussi un sauveur quand l’entreprise saigne et que vous avez un dataset bien compris (comme un partage de fichiers) et une cadence de snapshots fiable.

À utiliser quand :

• Vous avez une haute confiance que le vecteur de compromission est contenu (identifiants tournés, partages désactivés, malware supprimé).
• Vous pouvez tolérer la perte des changements depuis le snapshot.
• Le dataset n’héberge pas d’exécution de code qui pourrait se relancer (par ex. scripts partagés exécutés par des serveurs).

À éviter quand :

• Vous suspectez que l’hôte est encore compromis.
• Le dataset est un datastore VM ou une base où les rollbacks peuvent entrer en conflit avec la cohérence applicative.
• Vous avez besoin de forensics sur l’état chiffré et ne pouvez pas vous permettre d’écraser les preuves.

Stratégie B : cloner un snapshot et basculer (plus sûr, encore rapide)

Un clone vous permet de valider et de servir des données propres sans détruire le dataset courant. Vous pouvez aussi garder le dataset « infecté » intact pour l’investigation. Opérationnellement, vous pouvez changer les mountpoints, les exports ou les partages SMB pour pointer vers le clone.

Attention : les clones consomment de l’espace au fur et à mesure qu’ils divergent. Si vous servez le clone pendant des semaines, il devient « production », et l’original devient « ce truc qu’on supprimera un jour ». Ce jour n’arrive jamais, et votre CAP augmente discrètement. Planifiez le nettoyage.

Stratégie C : restaurer ailleurs (la décision d’adulte)

Restaurez sur un hôte/pool séparé quand vous ne faites pas confiance au système touché. C’est le choix par défaut pour les datastores VM, les bases de données et tout ce qui a une automatisation privilégiée liée.

Bénéfices opérationnels :

• Plan de contrôle propre : nouvelles clés SSH, nouveaux identifiants, nouveaux exports.
• Risque de réinfection réduit : les attaquants persistent souvent dans l’environnement original.
• Travail en parallèle : une équipe restaure pendant qu’une autre fait le forensic sur l’hôte compromis.

Coûts :

• Capacité et temps. Il faut de l’espace pour recevoir et valider.
• Le débit réseau peut devenir le goulot.

Blague #2 (courte, pertinente) : La seule chose plus effrayante que restaurer depuis des sauvegardes est de découvrir que vos sauvegardes faisaient de la « danse interprétative » au lieu de répliquer.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne gérait un partage de fichiers sur ZFS pour les départements. Ils étaient fiers de leurs snapshots horaires. Le helpdesk pouvait restaurer des fichiers en naviguant dans .zfs/snapshot. Ça semblait moderne. C’était pourtant bâti sur une unique hypothèse : « seuls les admins peuvent supprimer des snapshots. »

Pendant une compromission par phishing, l’attaquant a atterri sur une station Windows puis a obtenu des identifiants appartenant à un compte de service utilisé pour des « restores en libre-service ». Ce compte avait bien plus de pouvoir que son nom ne le laissait entendre. Il pouvait snapshotter, monter et — parce que quelqu’un ne voulait pas gérer des scripts de rétention qui échouaient — détruire.

L’attaquant n’avait pas besoin de connaissances ZFS pointues. Il a trouvé l’historique shell et des scripts d’automatisation, puis a exécuté quelques commandes ZFS pour effacer la chaîne de snapshots avant de chiffrer le partage en direct. Le chiffrement fut bruyant ; la suppression des snapshots fut silencieuse.

La récupération fut possible, mais pas à partir des snapshots locaux. L’équipe dut récupérer une ancienne copie hors site répliquée hebdomadairement (pas horairement), réhydrater des téraoctets sur un lien contraint, puis répondre à la question que personne n’aime : « Alors, qu’avons-nous perdu ? »

La correction fut simple et humiliante : les permissions déléguées furent séparées. La création de snapshots et la réplication furent séparées de la destruction des snapshots, et des holds furent appliqués sur les points quotidiens les plus récents. Ils cessèrent aussi d’exposer .zfs aux utilisateurs et remplacèrent les restores en libre-service par un workflow contraint. Le système devint un peu moins pratique et beaucoup plus survivable.

Mini-récit 2 : l’optimisation qui a mal tourné

Un autre site hébergeait des images VM sur ZFS. Ils voulaient plus de performance pour leur workload le plus fréquent et firent une série de réglages agressifs : recordsize plus grand, comportement sync assoupli dans certains endroits, et un planning de snapshots réduit « pour diminuer l’overhead ». Tout était justifié par des benchmarks et quelques beaux graphes.

Puis un ransomware frappa un jump host ayant accès au réseau de gestion VM. L’attaquant n’a pas chiffré les fichiers sur l’hôte ZFS ; il a chiffré à l’intérieur des guests. Le stockage a vu une tempête d’écritures aléatoires sur plusieurs gros zvols. Le planning de snapshots réduit signifiait que leur dernier point propre pour plusieurs VM critiques remontait à plusieurs heures.

Le tuning de performance a empiré la récupération. Avec moins de snapshots, ils ont tenté de répliquer des images volumineuses entières depuis le dernier point bon. Le lien réseau devint le goulot, et la surcharge CPU due à la compression/le chiffrement côté envoi ajouta l’insulte. Les restaurations furent correctes, mais assez lentes pour dépasser les objectifs internes de récupération.

Le post-mortem ne disait pas que ZFS était « lent ». Il disait qu’ils avaient optimisé pour l’état stable en oubliant le mode défaillance. Ils réintroduisirent des snapshots plus fréquents pour les datasets VM, séparèrent « tuning de performance » et « conception de récupération », et imposèrent des exigences strictes autour des points de restauration pour les systèmes tier-0. Les graphes steady-state s’améliorèrent. Mais surtout, le prochain incident se terminerait par une restauration, pas une négociation.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise régulée utilisait ZFS pour des partages départementaux et un petit cluster d’analytics. Leur politique de snapshots était terne : snapshots toutes les 15 minutes pendant 24h, horaires pendant 7 jours, quotidiens pendant un mois. La réplication se faisait vers une cible hors site sous un domaine administratif différent, avec des permissions de suppression de snapshots non déléguées à l’automation de production.

Ils faisaient aussi un exercice de restauration trimestriel. Pas une simulation table-top. Une vraie restauration d’un dataset représentatif vers un hôte propre, avec chrono et checklist. Les ingénieurs détestaient ça comme on déteste se brosser les dents : on sait que c’est bien, mais ça reste une punition.

Quand le ransomware est arrivé via une station compromise, le partage de fichiers fut endommagé. Ils ont contenu l’accès rapidement, cloné le dernier snapshot bon vers un mount de quarantaine et validé l’absence d’artefacts de rançon. La bascule prit des heures, pas des jours.

La réplication hors site fut le héros silencieux. Même si l’attaquant avait réussi à supprimer les snapshots locaux, la cible hors site possédait des points plus anciens protégés par politique et permissions. Le rapport d’incident restait douloureux, mais la récupération fut procédurale. Pas d’improvisation, pas d’exploits nocturnes, pas de « on pense que tout est là ».

Ce qui les a sauvés n’était pas du génie. C’était le refus de traiter les snapshots comme une fonctionnalité et le fait de les traiter comme un produit avec des exigences : rétention, protection et tests de restauration.

Durcir les snapshots pour que la prochaine fois soit ennuyeuse

Cadence des snapshots : adaptez-la au comportement du ransomware

Le ransomware agit souvent rapidement, mais pas toujours. Parfois il chiffre opportunément, parfois il progresse lentement pour éviter la détection. Votre plan de snapshots devrait supposer que vous ne le remarquerez que plus tard.

• Tier 0 (données métiers partagées) : snapshots toutes les 15 minutes pendant 24h, horaires pendant 7j, quotidiens pendant 30j est une base raisonnable.
• Datastores VM : des snapshots fréquents aident, mais ne prétendez pas qu’ils sont cohérents applicativement. Utilisez-les comme points de restauration crash-consistents et associez-les à des sauvegardes côté guest pour les bases critiques.
• Répertoires personnels : fort turnover ; définissez les attentes de rétention pour éviter d’exploser l’espace des snapshots.

Protéger les snapshots contre la suppression (là où vivent les adultes)

La défense tient surtout à qui peut faire quoi. Les snapshots sont vulnérables si les droits de suppression appartiennent au même pool d’identifiants que les opérations quotidiennes.

• Utilisez des holds sur les snapshots “ancre” quotidiens/hebdomadaires, surtout sur les cibles de réplication.
• Séparez les privilèges : la création et la réplication de snapshots sont courantes ; la destruction de snapshots doit être rare et contrôlée.
• Séparez les domaines d’administration : les cibles de réplication ne devraient pas accepter de connexions interactives des comptes admin de production si vous pouvez l’éviter.
• Rendez la cible de sauvegarde ennuyeuse et minimaliste : peu de paquets, peu de services, règles firewall strictes, exports en lecture seule quand c’est possible.

Conception de la réplication : bâtir volontairement un « espace d’erreur »

Si vous répliquez chaque minute et que vous propagez aussi les suppressions immédiatement, vous avez construit un pipeline haute disponibilité pour les désastres. Ajoutez de la friction :

• Retarder les actions destructrices : la rétention et la suppression de snapshots sur la cible doivent être indépendantes de la source.
• Conservez une rétention plus longue hors site : la cible est l’endroit où garder l’historique que vous espérez ne jamais utiliser.
• Envisagez une réplication pull : la cible initie des pulls depuis la source en utilisant des identifiants limités, plutôt que la source qui pousse vers la cible avec des droits étendus.

Tests de restauration : arrêtez de vous mentir

Les snapshots ne sont pas des sauvegardes tant que vous ne pouvez pas les restaurer sous contrainte. Faites des drills. Mesurez-les. Vérifiez le contenu. Documentez les étapes. Mettez la checklist là où elle pourra être trouvée à 3h du matin par quelqu’un qui n’a pas construit le système.

Erreurs fréquentes : symptôme → cause racine → correction

1) « Nous avons rollbacké mais les utilisateurs voient encore des fichiers chiffrés »

Symptôme : Après le rollback, certains répertoires contiennent encore des fichiers .locked ou des notes de rançon.

Cause racine : Vous avez rollbacké le mauvais dataset (ou le mauvais snapshot), ou les utilisateurs regardent un chemin d’export différent (namespace DFS, mapping SMB, cache hors ligne côté client).

Correction : Confirmez les mountpoints des datasets et les définitions de partage ; vérifiez la sélection du snapshot avec zfs diff. Videz ou invalidez les caches clients si nécessaire. Assurez-vous de ne pas avoir restauré seulement un dataset enfant alors que le parent reste infecté.

2) « Le rollback échoue avec ‘dataset is busy’ »

Symptôme : ZFS refuse le rollback à cause de montages actifs.

Cause racine : Des processus ont encore des fichiers ouverts, ou le dataset est exporté via NFS/SMB, ou un jail/container l’utilise.

Correction : Arrêtez les services, désexportez les partages, et démontez si nécessaire. Utilisez des clones/receive-ailleurs si vous ne pouvez pas arrêter tout en sécurité.

3) « Nous ne pouvons pas cloner ou recevoir : plus d’espace »

Symptôme : Les opérations de clone/receive échouent ; pool proche du plein.

Cause racine : CAP élevé ou rétention de snapshots immobilisant de grandes quantités de données, plus l’amplification d’écriture de l’incident.

Correction : Ajouter de la capacité (idéal), migrer des datasets non critiques ailleurs, ou effectuer un rollback en place (si sûr). Évitez les suppressions massives de snapshots en période d’I/O de pointe ; elles peuvent aggraver les performances.

4) « La cible de réplication a aussi des données chiffrées »

Symptôme : Les snapshots hors site incluent des artefacts de ransomware.

Cause racine : La réplication s’est exécutée après l’infection ; rétention trop courte ; suppressions propagées ; pas de points d’ancrage protégés.

Correction : Conservez une rétention plus longue sur la cible, utilisez des holds, découplez les politiques de suppression et envisagez une réplication différée ou pull. Pendant l’incident, arrêtez la réplication immédiatement pour éviter d’écraser de l’historique sain.

5) « Les restaurations sont douloureusement lentes »

Symptôme : Débit send/receive bien inférieur aux attentes.

Cause racine : Limitation CPU (chiffrement/compression), goulot réseau, fragmentation du pool, ou workloads concurrents (scrubs, resilvers, écritures actives du ransomware).

Correction : Mesurez : vérifiez iostat, usage CPU, débit du lien. Mettez en pause les tâches non essentielles. Restaurez sur un autre pool si l’original est surchargé ou malade.

6) « Les snapshots ont disparu, mais personne n’avoue les avoir supprimés »

Symptôme : Chaîne de snapshots manquante ; logs peu clairs.

Cause racine : Automatisation sur-privilegiée ou compte de service compromis a exécuté des commandes destructrices, ou un script de rétention a mal fonctionné dans des conditions limites.

Correction : Auditez les permissions déléguées et l’automatisation. Gâtez la suppression. Placez des holds sur les ancres. Centralisez les logs des actions administratives ZFS et des événements d’auth de façon immuable et alertez sur les suppressions de snapshots.

7) « Nous avons restauré, puis nous avons été réinfectés »

Symptôme : Le chiffrement reprend après la recovery.

Cause racine : Vous avez restauré les données mais pas la confiance. Identifiants compromis, malware persistant, ou partages exposés sont restés.

Correction : Faites tourner les identifiants avant la bascule, reconstruisez les hôtes compromis et réintroduisez l’accès progressivement. Traitez la restauration comme un changement contrôlé, pas comme un bouton magique d’annulation.

Checklists / plan pas à pas

Checklist de réponse à incident (vue stockage/opérateur)

1. Contenir : désactiver les exports SMB/NFS ou les firewaller ; arrêter les apps écriture-intensives ; mettre en quarantaine les endpoints compromis.
2. Figer : prendre un snapshot @incident-* des datasets affectés pour preuve.
3. Vérifier la santé : zpool status, capacité, erreurs. Si le pool est malade, planifiez une restauration ailleurs.
4. Arrêter la réplication : mettre en pause les jobs pour ne pas répliquer l’état chiffré sur l’historique sain.
5. Trouver le dernier snapshot connu bon : utiliser zfs diff, contrôler le contenu, chercher des artefacts de rançon.
6. Le protéger : appliquer zfs hold sur les snapshots candidats.
7. Choisir le mode de récupération : rollback, clone et bascule, ou restaurer ailleurs.
8. Valider en quarantaine : monter le clone en lecture seule ; scanner les artefacts ; confirmer que les fichiers critiques s’ouvrent correctement.
9. Bascule : repointer les partages/mounts ; réactiver l’accès par étapes ; surveiller les écritures et les logs d’auth.
10. Durcissement post-restore : tourner les clés, ajuster zfs allow, appliquer la rétention, protéger la cible.
11. Documenter la timeline : heures des snapshots, point de restauration choisi, fenêtre de perte, actions entreprises.
12. Faire un drill de restauration plus tard : oui, plus tard. Mais planifiez-le avant que tout le monde n’oublie.

Checklist de bascule (basée sur clone)

1. Créer un clone à partir du dernier snapshot connu bon, monter en lecture seule.
2. Valider la structure des répertoires, faire des vérifications d’intégrité pour des échantillons critiques, et l’absence d’artefacts évidents de ransomware.
3. Créer un clone inscriptible (ou promouvoir le workflow) si vous devez servir les données activement.
4. Mettre à jour les exports SMB/NFS pour pointer vers le mountpoint du clone (ou échanger les mountpoints de façon atomique quand c’est possible).
5. Remettre le service pour un petit groupe pilote d’abord.
6. Surveiller l’I/O, les échecs d’auth et les nouveaux schémas de création de fichiers pendant au moins un cycle métier.
7. Décider seulement après quoi faire de l’ensemble infecté : conserver pour le forensic, archiver ou détruire après approbations.

Checklist de durcissement post-incident (résilience des snapshots)

1. Séparer les permissions déléguées ZFS : retirer la suppression de snapshots des comptes courants.
2. Appliquer des holds sur les snapshots ancre (quotidiens/hebdomadaires) sur la cible de réplication.
3. Découpler les politiques de rétention entre source et cible ; ne pas propager la suppression aveuglément.
4. Centraliser les logs pour les commandes administratives et événements d’auth ; alerter sur la suppression de snapshots.
5. Réduire les chemins d’accès écrits : partages least-privilege, réseaux admin séparés, MFA quand possible.
6. Planifier des tests de restauration et mesurer RTO/RPO avec des tailles de données réelles.

FAQ

1) Les snapshots ZFS sont-ils des sauvegardes « immuables » ?

Non. Les snapshots sont des références durables à un instant donné, pas immuables par défaut. Si quelqu’un peut exécuter zfs destroy dessus, ils sont supprimables. Utilisez des holds, la séparation des privilèges et la réplication hors site sous un domaine admin différent si vous voulez une immutabilité pratique.

2) Dois-je rollbacker ou cloner ?

Cloner quand c’est possible ; rollbacker quand c’est nécessaire. Les clones préservent les preuves et permettent de valider avant la bascule. Le rollback est plus rapide et simple mais supprime les changements récents et peut réintroduire un risque si l’hôte est encore compromis.

3) Comment savoir quel snapshot est propre ?

Utilisez une combinaison : timeline de l’incident (quand les symptômes ont commencé), zfs diff entre snapshots et inspection directe d’un clone ou de l’arborescence snapshot en lecture seule. Cherchez les notes de rançon, nouvelles extensions et motifs de modifications massives.

4) Et si le ransomware a chiffré des disques VM (zvols) au lieu de fichiers ?

Vous pouvez toujours rollbacker ou restaurer le dataset zvol, mais le point de restauration doit prédater le chiffrement. Préparez-vous à de gros transferts de données et à une validation plus lente. Pour les bases critiques, associez les restaurations ZFS à une récupération au niveau applicatif (journaux de transactions, sauvegardes cohérentes côté guest).

5) Activer le chiffrement ZFS arrêtera-t-il le ransomware ?

Non. Le chiffrement ZFS protège les données au repos et peut réduire certains scénarios de vol, mais un ransomware s’exécutant avec un accès légitime peut toujours lire/écrire et chiffrer vos fichiers à l’intérieur du dataset.

6) Les attaquants peuvent-ils supprimer des snapshots via SMB/NFS ?

Pas directement via des opérations de fichiers. Mais s’ils compromettent des identifiants ayant un accès shell/API à l’hôte ZFS — ou l’automatisation qui gère les snapshots — ils peuvent supprimer des snapshots avec des commandes ZFS. Votre risque est lié à l’identité et aux privilèges, pas au protocole SMB en lui-même.

7) Dois-je continuer à exposer .zfs/snapshot pour des restores en libre-service ?

C’est pratique et souvent mal utilisé opérationnellement (les gens traitent les snapshots comme une corbeille). Si vous le gardez, restreignez qui peut y accéder et assurez-vous que les privilèges de suppression de snapshots sont strictement contrôlés. Beaucoup d’environnements sont mieux servis par un workflow de restauration contrôlé.

8) Pourquoi libérer de l’espace est devenu plus difficile après l’incident ?

Parce que les snapshots immobilisent des blocs. Après des réécritures massives, les anciennes données propres sont toujours référencées par les snapshots, et les nouvelles données chiffrées consomment de l’espace additionnel. C’est attendu. La planification de capacité doit inclure une marge pour les incidents, pas seulement la croissance en steady-state.

9) Est-il sûr de supprimer le dataset chiffré après restauration ?

Techniquement oui, opérationnellement peut-être pas. Obtenez des approbations de la sécurité/juridique si l’incident déclenche des obligations de déclaration. Si vous avez besoin de forensics, conservez l’état chiffré (ou un snapshot de celui-ci) isolé et contrôlé par accès.

10) Quelle est la meilleure amélioration si on ne peut n’en faire qu’une ?

Protéger les snapshots hors site contre la suppression par des identifiants de production compromis. Cela signifie domaine admin séparé, holds sur les ancres et une rétention qui ne peut pas être « nettoyée » par un attaquant.

Prochaines étapes que vous pouvez faire aujourd’hui

Quand le ransomware frappe, les snapshots ZFS peuvent transformer un événement qui ruine une carrière en une mauvaise journée avec une checklist. Mais seulement si vous avez préparé le chemin en amont : points de restauration propres, historique protégé et routine de récupération qui ne dépend pas d’actes héroïques.

Faites ces actions suivantes :

1. Auditez zfs allow sur les datasets critiques. Retirez la destruction de snapshots des comptes routiniers et de l’automatisation qui n’en a pas strictement besoin.
2. Ajoutez des holds sur les snapshots ancre quotidiens/hebdomadaires sur la cible de réplication.
3. Notez votre méthode de « sélection du dernier connu bon » (timeline + zfs diff + validation par clone en lecture seule).
4. Faites un drill de restauration sur un dataset représentatif. Chronométrez-le. Capturez les étapes. Corrigez ce qui vous surprend.
5. Décidez, à l’avance, quand vous ferez rollback vs clone vs restaurer ailleurs. L’incident n’est pas le bon moment pour inventer la philosophie.

Le ransomware est un problème d’ingénierie déguisé en crime. Résolvez-le par l’ingénierie : contraintes, séparation des responsabilités et chemins de récupération testés.