Utiliser une Zip Bomb pour protéger un serveur

• La majeure partie du trafic web provient de bots, dont certains sont utilisés à des fins malveillantes
• Une Zip Bomb est un petit fichier compressé qui, une fois décompressé, se transforme en un fichier très volumineux pouvant surcharger un serveur
• Les techniques de compression sont utilisées sur le web pour transmettre efficacement les données, et les bots en tirent aussi parti
• Lorsqu’un bot malveillant est détecté, le serveur fournit un fichier compressé en gzip afin de le neutraliser
• La Zip Bomb n’est pas une solution parfaite, mais elle est efficace pour bloquer les bots simples

---

Protéger un serveur à l’aide d’une Zip Bomb

• La majeure partie du trafic web provient de bots, dont certains sont utilisés à des fins malveillantes
• Les bots malveillants peuvent repérer les vulnérabilités d’un serveur et y injecter des scripts malveillants pour transformer le serveur en botnet
• Une Zip Bomb est un petit fichier compressé qui, une fois décompressé, se transforme en un fichier très volumineux pouvant surcharger un serveur

Utilisation des techniques de compression

• gzip est une technique de compression utilisée sur le web pour transmettre efficacement les données
• Les navigateurs web comme les bots prennent en charge la compression gzip, ce qui permet d’exploiter au maximum la bande passante
• Lorsqu’un bot malveillant est détecté, le serveur fournit un fichier compressé en gzip afin de le neutraliser

Comment créer une Zip Bomb

• Utiliser la commande dd pour générer 10 Go de données, puis les compresser avec gzip afin d’obtenir un fichier de 10 Mo
• Lorsque le serveur détecte une requête malveillante, il renvoie un fichier Zip Bomb de 10 Mo pour neutraliser le bot

Limites de la Zip Bomb

• La Zip Bomb n’est pas une solution parfaite, et certains bots peuvent la détecter et la contourner
• Cependant, elle reste efficace pour bloquer les bots simples et constitue un outil utile pour protéger un serveur

Articles associés

• Comment traiter 1,3 million de requêtes web
• Modifier la signature d’un serveur Apache
• Respecter Do Not Track dans Google Analytics

[GN⁺]

Avis Hacker News

• Je me souviens que, quand j’étais enfant, j’avais fait comme blague sur ma page perso ln -s /dev/zero index.html. Les navigateurs de l’époque n’aimaient pas ça, et le système se figeait ou plantait parfois
  • Plus tard, les navigateurs ont commencé à vérifier le contenu réel, ce qui a mis fin à ce type de requêtes
• Aujourd’hui, presque tous les navigateurs prennent en charge zstd et brotli, donc ce genre de bombe pourrait être plus efficace
  • Dans un ancien commentaire, quelqu’un montrait un taux de compression de 1,2M:1, et zstd fait encore mieux
• Les bots ne prennent peut-être pas en charge les standards de compression modernes
  • Cela peut être un bon moyen de bloquer les bots : tous les navigateurs modernes prennent en charge zstd, donc si on l’impose aux user agents non présents sur liste blanche, on peut déstabiliser les scrapers
• Dans mon précédent emploi, des bots ont trouvé une vulnérabilité WordPress et injecté un script malveillant sur le serveur
  • C’est amusant de constater que je ne suis pas le seul à avoir vu un shell PHP être déployé sur un serveur moins d’une heure après l’installation de WordPress
• Les zip bombs, c’est amusant. J’ai déjà découvert une faille dans un produit de sécurité qui n’inspectait pas correctement les archives zip au-delà d’une certaine taille
  • Résultat, si on mettait une zip bomb dans un document Office XML, le produit la laissait passer même s’il y avait un malware facilement identifiable à l’intérieur
• J’ai trouvé un moyen de faire planter les clients SSH qui tentaient de deviner le mot de passe root via ssh
  • Au final, des script kiddies ont lancé une attaque DDoS contre mon serveur
  • Je suis donc passé à une méthode consistant à identifier les « mauvais acteurs » et à bloquer leurs IP avec des règles de pare-feu
  • Avec IPv6, cela devient de plus en plus difficile
• Les personnes qui créent des pages web peuvent fabriquer une zip bomb avec un lien invisible pour les humains (texte blanc sur fond blanc, aucun surlignage au survol/clic de l’ancre)
  • Les bots vont la télécharger pour l’examiner (les crawlers et les scrapers IA aussi)
• Il s’agit d’une bombe gzip (qui fonctionne comme une page web compressée normale), pas d’un fichier zip classique destiné à bloquer les virus
• J’ai déployé ça à la place d’un script de honeypot classique
  • Ça ne marche pas très bien
  • Dans les logs du serveur web, on voit que les bots ne téléchargent pas les 10 mégaoctets complets de poison
  • Ils s’arrêtent à des longueurs variables. Jusqu’à présent, je n’ai jamais vu plus d’environ 1,5 Mo récupéré
  • Ou alors est-ce que ça fonctionne ? Est-ce qu’ils décodent le flux en temps réel puis plantent ? Par exemple, est-ce que 1,5 Mo lus dans les logs pourraient en fait être décodés à la volée en 1,5 Go en RAM avant de provoquer un crash ?
  • Impossible de le savoir
• Il y a quelque temps, l’infrastructure anti-censure du Tor Project s’est retrouvée hébergée sur le même site qu’un billet de blog sur les zip bombs
  • Google a exploré l’un des fichiers zip, puis a ajouté le domaine à une liste de domaines malveillants, ce qui a endommagé une partie critique de l’outil Snowflake de Tor
  • Il a fallu plusieurs semaines pour résoudre le problème
• Dans l’une de mes applications, pour protéger les uploads, j’ai créé une partition disque temporaire de taille fixe de 10 Mo afin de limiter l’impact si un fichier trop volumineux est téléversé
• J’utilise depuis des années un script assemblé au fil du temps pour faire quelque chose de similaire
  • Chaque année, je vérifie les logs 404 et j’ajoute à une liste noire les chemins de vulnérabilités les plus populaires
  • Si cette URL est demandée 3 fois, j’ajoute l’hôte à une liste grise qui n’autorise plus que des chemins légitimes limités