Quand une bombe de décompression rencontre ZFS : plus de 3.700 15 To écrits sur un disque de XNUMX To

Dans notre travail quotidien, nous sommes souvent confrontés à des problèmes de performance, de sécurité et d'évolutivité. Mais nous rencontrons aussi parfois des cas particulièrement curieux. Aujourd'hui, nous souhaitons partager avec vous l'une de ces situations particulières, rencontrée sur l'un des systèmes gérés pour le compte de l'un de nos clients.

Tout a commencé d’une manière apparemment anodine : une sauvegarde qui a duré trop longtemps. Rien d'inhabituel à première vue, si ce n'est qu'il s'agissait d'une sauvegarde incrémentielle, une opération qui prend généralement quelques minutes. Dans ce cas précis, cependant, la tâche avait été exécutée pendant des heures, toute la nuit. Comportement suspect.

Nous avons ensuite commencé à analyser le système, découvrant un répertoire peuplé de centaines de fichiers provenant de 86 terabyte chacun. Tous créés le même jour, et tous contenus dans un système de fichiers hébergé sur un disque par 15 terabyte.

Cela peut vous paraître absurde. Nous aussi, nous avons d'abord pensé à une erreur d'affichage, à un bug dans les commandes système. Pourtant, tout était bien réel : ces fichiers existaient, ils étaient accessibles, lisibles et traités par le système. Mais comment était-ce possible ?

Un marché de modèles 3D et un téléchargement compromis

Le système en question héberge une plateforme de vente où les utilisateurs peuvent télécharger et vendre des modèles 3D sous différents formats. Les fichiers sont téléchargés, analysés, puis indexés et mis en vente.

Quelqu'un, manifestement avec une intention malveillante (ou simplement pour tester les limites du système), a pensé à télécharger un fichier .rar en le faisant passer pour un modèle 3D. Une fois décompressé, le fichier a généré une archive volumineuse, théoriquement 86 téraoctets, composé entièrement de voix.

Ce type de fichier est appelé bombe de décompression ou encore ZIP BOMB: un très petit fichier compressé (parfois quelques Mo) qui, lors de l'extraction, se dilate considérablement, saturant des ressources telles que le disque, la RAM et le processeur. Dans des scénarios non protégés, il peut entraîner la panne de serveurs entiers.

Comment une petite archive génère-t-elle 86 To ?

Au cœur de Decompression Bomb et ZIP Bomb, la réponse réside dans la nature des données et des algorithmes de compression. Les fichiers contenant uniquement des zéros ou des motifs répétitifs sont extrêmement compressibles.Les algorithmes comme le codage de Huffman (et ses dérivés) fonctionnent en attribuant des codes plus courts aux motifs les plus fréquents. Si un fichier est composé à 100 % d'une seule valeur (par exemple, 0), la compression peut être extrêmement efficace.

Pour mieux comprendre ce phénomène, imaginez devoir décrire en mots une longue ligne d'un million de zéros. Au lieu d'écrire chaque zéro, il suffirait de dire « écrire des zéros un million de fois ». C'est le principe sur lequel reposent les algorithmes de compression : encoder des séquences répétitives avec des informations compactes.

Dans ce cas précis, le fichier .rar Le fichier téléchargé contenait un seul fichier qui, non compressé, devait occuper 86 To, mais son contenu ne comptait que zéro octet. Une fois compressé, le résultat est un fichier minuscule, inférieur à 10 Mo, car toutes les séquences sont encodées de manière extrêmement compacte.

Ce type de contenu est non seulement hautement compressible, mais représente également un réel danger : il est extrêmement facile de générer des fichiers apparemment inoffensifs qui, une fois extraits, peuvent occuper un espace considérable. L'effet est d'autant plus dévastateur que le système qui les extrait manque de contrôles, de quotas ou de protections sur le processeur, la RAM ou l'espace disque.

Un autre aspect intéressant est que, l'algorithme de compression ne pouvant prédire le contenu du fichier décompressé, il doit simplement suivre les instructions : « Écrire zéro pour 86.000.000.000.000 XNUMX XNUMX XNUMX XNUMX d'octets ». Aucune vérification n'est appliquée automatiquement, sauf si explicitement fournie par le système ou l'application. D'où le risque potentiel : un fichier de quelques Mo peut devenir une bombe de centaines de téraoctets.

Dans un environnement non préparé, cela conduit facilement à une saturation du stockage, à des pannes de services actifs et, dans le pire des cas, à une corruption des données et à une perte d'exploitation.

Mais dans notre cas, rien de tout cela ne s'est produit. Pourquoi ?

L'arme secrète : OpenZFS et la compression LZ4

Le système attaqué utilise OpenZFS, un système de fichiers avancé qui prend en charge nativement des fonctionnalités telles que :

• instantanés et restaurations

• contrôle d'intégrité des données

• déduplication

• et, surtout dans ce cas, compression transparente

OpenZFS n'est pas seulement un système de fichiers, mais un véritable outil avancé de gestion du stockage. Parmi ses fonctionnalités les plus puissantes, on trouve : la possibilité d'activer la compression au niveau du jeu de données, d'une manière totalement transparente pour l'application et l'utilisateur finalCela signifie que les données sont compressées lors de l'écriture et décompressées lors de la lecture, sans intervention manuelle ni modification du logiciel côté application.

Qu'est-ce que LZ4 ?

LZ4 est un algorithme de compression sans perte (sans perte) conçu pour être extrêmement rapide, avec un bon compromis entre taux de compression et vitesse. Comparé à d'autres algorithmes comme gzip, LZ4 offre :

• vitesses de compression et de décompression beaucoup plus élevées
• consommation CPU extrêmement faible
• Prise en charge des données binaires et structurées

Elle est particulièrement efficace sur les données redondantes ou répétitives, comme nos fichiers constitués de zéros. Dans ces conditions, LZ4 est capable de compresser des fichiers théoriquement énormes (des dizaines de téraoctets) en quelques kilooctets seulement.

ZFS décide dynamiquement s'il convient de compresser et dans quelle mesure, en fonction du gain réalisable. Si un bloc de données n'est pas rentable à compresser, il est sauvegardé en clair, évitant ainsi une surcharge inutile.

Dans le cas spécifique de cette bombe de décompression, le système de fichiers a interprété les fichiers décompressés (composés de zéros) et les a immédiatement recompressés avec LZ4, allant jusqu'à les écrire physiquement sur le disque occupant seulement une fraction infinitésimale de l'espace logique.

Pourquoi ne l’avons-nous pas remarqué tout de suite ?

Grâce à la compression active, le stockage n'a pas rempli l'espace disponible. Le système de fichiers affichait correctement l'espace libre, les services fonctionnaient correctement et la charge processeur était minimale. Tout semblait normal.

C’est précisément la force – et en même temps le « piège » – de la compression transparente de ZFS : d’une part, elle nous protège des scénarios désastreux tels que les bombes de décompression, mais d’autre part, elle rend difficile de remarquer immédiatement leur présence, car tout continue de fonctionner apparemment sans anomalies visibles.

Seule l'analyse d'une planification anormale dans les sauvegardes nous a fait découvrir la présence des fichiersEn fait, l'une des tâches était en cours d'exécution depuis plusieurs heures, même s'il s'agissait d'une sauvegarde incrémentielle. C'est ce détail qui a éveillé nos soupçons et a déclenché l'enquête.

En utilisant les commandes de diagnostic classiques, nous avons immédiatement remarqué un comportement inhabituel : ls -lh affichait d'énormes fichiers de plusieurs dizaines de téraoctets, tandis que du -sh une consommation négligeable a été signalée, inférieure à quelques mégaoctets. Un signe clair que les fichiers existaient logiquement, mais étaient pratiquement nuls au niveau physique grâce à l'intervention du système de fichiers.

En d’autres termes, sans une analyse ciblée au niveau ZFS (ou une observation indirecte de processus anormaux tels que des sauvegardes ralenties), il n’y aurait pas eu d’alerte ou d’alarme évidente. Ce type d'attaque, sans un système de fichiers avancé, aurait saturé le stockage en quelques secondes. Avec ZFS, cependant, nous nous sommes retrouvés face à une anomalie silencieuse, que nous avons pu étudier sereinement, sans avoir à intervenir en urgence.

Compression dans ZFS : avantages pratiques

Si vous n'avez pas encore envisagé la compression sur vos systèmes ZFS, voici quelques raisons concrètes de le faire. On pense souvent à la compression uniquement pour gagner de la place, mais en réalité, ses avantages sont bien plus vastes et stratégiques :

• Réduction de l'espace occupéLa compression permet d'intégrer beaucoup plus de données dans un même espace physique. Ceci est particulièrement utile dans les environnements où le stockage est coûteux, comme les SSD NVMe ou les disques d'entreprise.

• Amélioration des performancesEn réduisant la quantité de données écrites et lues physiquement sur le disque, les temps d'accès et la charge des opérations d'E/S sont réduits. Dans de nombreux cas, la lecture de données moins compressées et leur décompression en RAM sont plus rapides que la lecture directe de données non compressées depuis le disque.

• Effet positif sur les sauvegardes et les snapshotsLes sauvegardes compressées occupent moins d'espace et sont plus rapides à transférer, notamment lorsqu'elles sont associées à des mécanismes de déduplication ou à des snapshots ZFS. De plus, les snapshots compressés peuvent être répliqués plus efficacement entre les hôtes.

• Fonctionnalité transparenteLa compression ZFS est totalement transparente pour le logiciel utilisé. Elle ne nécessite aucune modification des applications, n'affecte pas la compatibilité des fichiers et ne modifie pas le comportement des processus de lecture et d'écriture.

• Atténuer les attaques comme celle-ciComme nous l'avons vu dans le cas de la bombe de décompression, la compression ZFS a neutralisé un désastre potentiel en évitant la saturation du stockage. Ce type de résilience, activé simplement par une option active, représente un avantage de sécurité tangible.

L'activation de la compression LZ4 sur un ensemble de données dans ZFS est simple :

compression de l'ensemble zfs = réservoir lz4/ensemble de données

Vous pouvez également vérifier son efficacité :

Une valeur supérieure à 1.0 indique que la compression a pris effet.

Ce que nous avons fait après la découverte

Une fois que nous avons compris la source du problème, nous avons bloqué le téléchargement de fichiers compressés potentiellement dangereux en activant :

• des contrôles plus restrictifs sur le type et la structure des fichiers téléchargés

• une limite maximale sur la taille extensible des archives

De plus, nous avons suggéré à l’équipe de développement de l’application certaines bonnes pratiques à mettre en œuvre côté logiciel pour accroître la résilience face à des attaques similaires. Parmi celles-ci :

• effectuer une analyse préventive de la structure interne des archives compressées, même en mode sandbox

• calculer, lorsque cela est possible, une estimation de la taille finale des fichiers une fois extraits, afin d'identifier les cas anormaux avant qu'ils n'impactent le stockage

• appliquer des délais d'attente et des limites de mémoire aux opérations de décompression, afin de bloquer tout abus même pendant l'extraction

Nous avons ensuite supprimé les fichiers que nous avions créés, vérifié qu’il n’y avait aucune référence publique ou lien vers ces contenus et remis le système dans des conditions de fonctionnement normales.

Leçon apprise : les systèmes de fichiers font (beaucoup) de différence

Cette expérience nous a rappelé une fois de plus l'importance stratégique du choix du système de fichiers dans la gestion d'une infrastructure. Nous avons trop souvent tendance à sous-estimer cet aspect, pensant que « l'un vaut l'autre » ou que le système de fichiers par défaut de la distribution Linux est suffisant pour tous les scénarios.

Si le système avait été basé sur ext4 ou XFS, l’attaque aurait probablement réussi, saturant le stockage en quelques instants et bloquant les services essentiels. Sans compression transparente, les fichiers de 86 téraoctets auraient rapidement consommé tout l'espace disponible, provoquant des pannes en cascade, des temps d'arrêt et potentiellement une perte de données.

Grâce à l'architecture moderne de ZFS, nous avons pu limiter l'impact, identifier le problème sereinement et le résoudre sans interruption de service. Le système de fichiers a réagi de manière intelligente et proactive, compressant automatiquement le contenu hautement redondant et évitant ainsi la saturation du stockage.

Cette histoire démontre comment investir dans des technologies fiables comme OpenZFS signifie non seulement améliorer les performances, mais également fournir une protection structurelle contre les comportements anormaux ou les attaques non conventionnelles. Un système de fichiers n’est pas seulement un détail technique : il peut faire la différence entre un crash et un simple journal d’un événement curieux.

OpenZFS : un aperçu

Pour ceux qui ne le connaissent pas, OpenZFS est l'implémentation open source du système de fichiers ZFS, développé à l'origine par Sun Microsystems Au début des années 2000, pour Solaris. Après son acquisition par Oracle, la communauté a développé un fork indépendant, activement maintenu et en constante évolution aujourd'hui.

OpenZFS est l'un des systèmes de fichiers les plus avancés disponibles aujourd'hui pour Linux, BSD et leurs environnements dérivés. Bien plus qu'un système de fichiers traditionnel, c'est une plateforme complète de gestion du stockage, conçue pour la sécurité, l'intégrité des données et la résilience.

Parmi ses principales caractéristiques, nous trouvons :

• Architecture de copie sur écriture (COW):Chaque modification des données génère une nouvelle copie, permettant des instantanés instantanés et des restaurations sans perte.

• Intégrité des données via la somme de contrôleChaque bloc écrit est accompagné d'une somme de contrôle. Si les données sont corrompues, ZFS peut les détecter et, s'il est correctement configuré, les corriger grâce à la redondance.

• Instantanés et réplication efficaces:Vous pouvez prendre des instantanés lisibles instantanément et les répliquer de manière incrémentielle sur des systèmes distants.

• Gestion avancée du stockageRAID-Z, vdev, pools, ensembles de données, limites d'espace, déduplication, compression et mise en cache multi-niveaux ne sont que quelques-unes des options disponibles.

ZFS n'est pas « prêt à l'emploi » sur toutes les distributions, mais avec une courbe d'apprentissage minimale, il offre robustesse et flexibilité supérieures à tout système de fichiers traditionnelDans les contextes critiques ou gourmands en données, la différence est véritablement ressentie.

conclusion

Grâce à la compression LZ4 de ZFS, nous avons pu écrire sur 3.700 terabyte sur un disque de 15 TB Sans s'en rendre compte. Un paradoxe rendu possible uniquement par les fonctionnalités avancées de ce système de fichiers.

Il ne s'agissait pas d'un bug, mais d'une attaque malveillante et ingénieuse qui aurait pu compromettre un serveur entier. La combinaison d'une surveillance constante, d'outils de diagnostic et d'un système de fichiers moderne nous a permis d'isoler, de comprendre et de résoudre rapidement le problème.

Mais surtout, cet épisode a renforcé notre conviction que l'infrastructure doit être conçue non seulement pour des conditions optimales, mais aussi, et surtout, pour faire face aux imprévus. Dans ce cas précis, aucune intervention manuelle d'urgence, aucun basculement ni aucune récupération n'ont été nécessaires. Le système de fichiers a simplement fait son travail.

ZFS a prouvé sa capacité à relever le défi, protégeant le système de manière silencieuse mais efficace. Sa capacité à réagir aux situations anormales sans compromettre les données ni les performances en fait un outil essentiel pour ceux qui recherchent fiabilité et résilience.

En résumé ? Si vous pensez toujours qu'ext4 ou XFS sont « largement suffisants », nous vous encourageons à examiner de plus près ZFS. Vous découvrirez peut-être que votre prochain allié en matière de performances, d'intégrité et de sécurité est déjà là.

Bon travail et… attention aux bombes de décompression !