¿Qué tan práctico es aplicar una fuerza bruta a un número de 10 dígitos a través de la URL?

Aproximadamente un día

Si tenemos suerte: no hay limitación, podemos realizar cada prueba con una solicitud HEAD, podemos realizar muchas pruebas en una sola conexión HTTP con Keepalive y podemos tener muchas conexiones simultáneas.

En ese caso, estamos más limitados por el ancho de banda. Supongamos que creamos una solicitud ajustada de 100 bytes, lo que significa que debemos enviar un total de 100 * 10 ¹⁰ bytes. Y supongamos que tenemos una conexión decente de 100 Mbps, que hará unos 10 megabytes por segundo. Eso llevaría 100.000 segundos, un poco más de un día.

Este es el mejor de los casos, en la práctica es probable que haya problemas que eviten que funcione tan rápido. Podríamos tener varios sistemas trabajando simultáneamente para hacerlo más rápido, pero en algún momento sobrecargaremos el servidor.

Rodar un número de 10 dígitos no se acumula en la mayoría de los sistemas, independientemente del script / idioma utilizado. El problema más grande aquí es la cantidad de conexiones que se abren simultáneamente y el retraso entre las solicitudes. Un buen sistema configurado bloqueará demasiadas solicitudes que se originan en la misma dirección (ya sea por el firewall o el propio daemon).

Por ejemplo:

#!/bin/bash
for i in {1..1000}
do
   curl "www.[somewebsite].com/$i" > "${i}_out.txt"
done

Es posible que desee enlazar esto.

Depende de varios factores.

lado del servidor

• ancho de banda del servidor
• ¿Este número solicitado genera una consulta en alguna base de datos?
• Cualquier script de firewall / seguridad para detectar este tipo de actividad y bloquearlo
• Cualquier otro recurso que pueda ser un cuello de botella como cpu o memoria.
• Si usted es ese tipo de personas afortunadas que lo intentarán en un servidor que los registros se almacenan en un sistema de archivos muy limitado, y este tipo de actividad consumirá cada byte libre que haga que la aplicación se detenga.

lado del cliente

• Su ancho de banda

Mis consideraciones con respecto a esta actividad:

Primero haga una consulta de DNS y vea si hay más de un servidor para esa dirección. Eso ayudará, más servidor, más puede dividir la carga.

Pruebe el firewall, obtenga un VPS y realice algunas pruebas para obtener una idea de su entorno sin incluir en la lista negra su dirección IP. Pruebe algunas tasas, 100, 1000, 10000, por segundo. Probar el tiempo promedio de respuesta para cada hora del día. Si los tiempos de respuesta cambian, entonces su servidor tiene algunas ventanas de tiempo que reciben más tráfico / solicitudes y ese será un buen momento para no estresar al servidor.

Con todos los resultados anteriores sabrá qué hacer. Si el servidor tiene más ancho de banda que usted, lo que sucede casi todo el tiempo, puede obtener un VPS para ayudarlo, elija uno cerca del servidor. Tendrá su plan sobre cuántas solicitudes serán óptimas para archivar su solución, por ejemplo, si los servidores reciben más carga por la mañana, puede usar 1000 / s durante el día, por ejemplo, de 8:00 a 22:00, y utilizar tantos los servidores pueden responder de 10pm a 8am.

Solo tenga en cuenta que este tipo de actividad puede hacer que algunos servicios se bloqueen o se carguen tanto, que no pueda responder a los usuarios y que se pueda considerar un ataque de denegación de servicio. Puede causarle problemas debido a varios factores, no sé de todos los países, en varios países este tipo de ataque es un delito. Comuníquese con el administrador del sistema sobre sus intenciones, antes de bloquear cualquier sistema y hacerse responsable de un tiempo de inactividad.

Un día es muy poco realista , independientemente de los recursos.

Hay 86,400 segundos en un día. Redondear hasta 100k. Divide 1B por 100k y obtendrás 10,000 consultas por segundo. Esto es algo grande. El servidor necesitará una historia de balanceo de carga decente y una buena cantidad de capacidad informática. Para referencia, si tenemos 100 máquinas con 8 núcleos cada una (para un total de 800 núcleos), tendremos que dar vuelta a cada solicitud como máximo 80 ms , que es ajustado pero no es del todo irracional . El cliente también necesitará una capacidad acorde con la del servidor, y suponiendo que usted sea un atacante de sombrero negro, probablemente esté utilizando una red de bots o algo por el estilo.

En realidad, debe estar operando una red de bots, ya que el cliente debe estar distribuido geográficamente de tal manera que el servidor pueda equilibrar la carga sin atravesar los enlaces de red de alta latencia. Esto es crítico porque la latencia entre el servidor y el cliente cuenta para nuestro presupuesto de 80 ms. Si el cliente está completamente en América pero la mitad del servidor está en Europa, la latencia transatlántica arruinará completamente nuestro rendimiento y necesitaremos una capacidad significativamente mayor para compensarlo (o, de lo contrario, simplemente tendremos que atender todas las solicitudes con la mitad estadounidense del servidor, que tiene problemas de capacidad similares).

  

¡Pero espera! Usted dijo 'independientemente de los recursos'. ¿Por qué me estás lanzando números de recursos?

Porque las personas que operan servicios web a esta escala generalmente tienen un monitoreo lo suficientemente bueno como para detectar una repentina inundación de tráfico de QPS de 10k desde una red de bots. Con toda probabilidad, su objetivo determinará que usted está atacándolos DDoS (que es básicamente lo que está haciendo) y desplegará mitigaciones estándar (por ejemplo, sirviendo 503s o CAPTCHAs, ocultando el tráfico, etc.). En este punto, su ataque fallará o al menos tomará más tiempo de lo que usted planeó, y las autoridades ahora estarán trabajando para desmantelar su botnet.

Entonces, si quieres que tu ataque realmente funcione, no puedes hacerlo a esta velocidad. Su objetivo no puede manejar el tráfico o es lo suficientemente inteligente como para detectarlo y bloquearlo.