Estoy jugando con Hydra y una autenticación xmpp.
Creé mi propio servidor xmpp básico, reproduciendo una autenticación (del lado del servidor) desde un archivo pcap de texto claro. Creo que tengo un error en el manejo de mis conexiones (estoy creando un hilo por cada nueva conexión pero lo cierro por error) pero no importa, este no es mi punto.
He solucionado este problema de escalabilidad. Para aquellos interesados, se debió a una optimización de Hydra, que no se repite la primera, llamémosla "solicitud de saludo". Una autenticación regular necesita 4 solicitudes o respuestas de un cliente, 4 paquetes del servidor también. Y esta optimización salta la primera, yendo directamente a la segunda, que se parece a eso en mi caso: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1'/>
Estadísticas / Información:
- Conf de la máquina virtual: 2 CPU, 2 GB de RAM.
- Ubicación de la contraseña en la lista de palabras: posición 795 de 60k.
- Tarea única: ~ 50 intentos / min - > ~ 17min para encontrar la contraseña.
- 16 tareas: ~ 820 intentos / min - > 1h14min para completar sin encontrar el pw ('debido al problema de manejo de las conexiones).
Nuevas estadísticas (después de la optimización):
- Tarea única: ~ 90 intentos / min - > 9min 13s
- 16 tareas: ~ 1400 + intentos / min - > 33s
La pregunta es: ¿Hydra divide la lista de palabras en 16 partes iguales? Y como?
El tamaño de una parte es ~ 3.8k contraseñas. ¿Está el hilo 1 trabajando en las primeras contraseñas de 3.8k? El hilo 2 que trabaja en el 3801rst - > 7600? y así sucesivamente hasta el hilo 16? ¿De modo que las últimas 16 contraseñas probadas serían la 3799, la 7599 y así sucesivamente?
La otra posibilidad es que el subproceso 1, por ejemplo, proceda a cada 1% 16 (módulo) de contraseña de la lista de palabras, de modo que las contraseñas se prueban en el mismo orden que si solo tuviéramos 1 tarea (/ subproceso) en ejecución.
Puedo probarlo yo mismo, pero si alguien ya lo hizo, ilumina mi oscuridad.