Sto giocando con Hydra e un'autenticazione xmpp.
Ho creato un server xmpp di base, riproducendo un'autenticazione (lato server) da un file pcap in chiaro. Penso di avere qualcosa di sbagliato nella gestione delle mie connessioni (sto creando un thread per ogni nuova connessione ma lo chiudo per errore) ma non importa, non è questo il mio punto.
Ho risolto questo problema di scalabilità. Per chi fosse interessato, era dovuto a un'ottimizzazione di Hydra, che non riproduceva il primo, chiamiamolo "Ciao richiesta". Un'autenticazione regolare richiede 4 richieste o risposte da un client, 4 pacchetti dal server. E questa ottimizzazione salta la prima, andando direttamente al 2 °, che sembra così nel mio caso: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1'/>
Statistiche / Informazioni:
- Conf. della VM: 2 CPU, 2 GB di RAM.
- Posizione della password nella lista di parole: 795 ° posizione su 60k.
- Attività singola: ~ 50 tentativi / min - > ~ 17min per trovare la password.
- 16 attività: ~ 820 tentativi / min - > 1h14min da completare senza trovare il pw ('causa del problema di gestione delle connessioni).
Nuove statistiche (dopo l'ottimizzazione):
- Attività singola: ~ 90 tentativi / min - > 9min 13s
- 16 attività: ~ 1400 + tentativi / min - > 33s
La domanda è: Hydra divide la lista delle parole in 16 parti uguali? E come?
Una dimensione della parte è ~ 3.8k password. Il thread 1 funziona con le prime password da 3.8k? Il thread 2 che lavora sul 3801rst - > 7600? e così via fino al thread 16? In modo che le ultime 16 password testate siano 3799, 7599 e così via?
L'altra possibilità è che il thread 1 ad esempio proceda ogni 1% 16 (modulo) password dall'elenco di parole, in modo che le password vengano testate nello stesso ordine di se avessimo solo 1 task (/ thread) in esecuzione.
Posso testarlo da solo, ma se qualcuno lo ha già fatto, per favore illumina la mia oscurità.