Como veis, hemos creado un fichero de 10M que se convertirá en 10GB al descomprimirse. Ahora, para construir una simple defensa simplemente usa un pequeño script que, dependiendo del User-Agent, enviará la "bomba" creada:

<?php
 $agent = lower($_SERVER['HTTP_USER_AGENT']);
 
 //check for nikto, sql map or "bad" subfolders which only exist on wordpress
 if (strpos($agent, 'nikto') !== false || strpos($agent, 'sqlmap') !== false || startswith($url,'wp-') || startswith($url,'wordpress') || startswith($url,'wp/'))
 {
       sendBomb();
       exit();
 }
 
 function sendBomb(){
         //prepare the client to recieve GZIP data. This will not be suspicious
         //since most web servers use GZIP by default
         header("Content-Encoding: gzip");
         header("Content-Length: ".filesize('10G.gzip'));
         //Turn off output buffering
         if (ob_get_level()) ob_end_clean();
         //send the gzipped file to the client
         readfile('10G.gzip');
 }
 
 function startsWith($haystack,$needle){
     return (substr($haystack,0,strlen($needle)) === $needle);
 }

Como dice su autor, no es la "panacea" puesto que todos sabemos que cambiar el User-Agent es trivial, pero ya supondría una molestia para script kiddies y podrían implementarse otros triggers (por número de peticiones, IPs o países, payloads, etc.).

El resultado dependiendo del navegador o herramienta utilizada sería el siguiente:

- IE 11: se incrementa la memoria, IE se bloquea
- Chrome: se incrementa la memoria, se muestra un error
- Edge: se incrementa la memoria, luego drippea y carga en bucle
- Nikto: parece escanear bien pero no reporta nada (ninguna salida)
- SQLmap: alto uso de memoria hasta que se bloquea

Fuente: How to defend your website with ZIP bombs
Via: www.hackplayers.com