Com'è pratico aggiungere una bruteforce a un numero di 10 cifre tramite URL

Circa un giorno

Se siamo fortunati: non c'è nessuna limitazione, possiamo eseguire ogni test con una richiesta HEAD, possiamo eseguire molti test su una singola connessione HTTP con Keepalive e avere molte connessioni simultanee.

In questo caso siamo per lo più limitati dalla larghezza di banda. Supponiamo di creare una richiesta stretta di 100 byte, il che significa che dobbiamo inviare un totale di 100 * 10 ¹⁰ byte. E supponiamo di avere una buona connessione a 100 Mbps, che farà circa 10 megabyte al secondo. Ci vorrebbero 100.000 secondi - poco più di un giorno.

Questo è il caso migliore, in pratica ci sono probabilmente problemi che impediscono il suo funzionamento così veloce. Potremmo avere più sistemi che lavorano simultaneamente per renderlo più veloce, ma a un certo punto sovraccaricheremo il server.

Il roll-back di un numero di 10 cifre non scorre a lungo sulla maggior parte dei sistemi, indipendentemente dallo script o dalla lingua utilizzata. Il problema più grande qui è il numero di connessioni aperte contemporaneamente e il ritardo tra le richieste. Un buon sistema configurato bloccherà troppe richieste che provengono dallo stesso indirizzo (o dal firewall o dal daemon stesso).

Ad esempio:

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

Potresti voler infilarlo.

Dipende da diversi fattori.

Lato server

• Larghezza di banda del server
• Questo numero richiesto genera una query su qualche database?
• Qualsiasi script firewall / sicurezza per rilevare questo tipo di attività e bloccarlo
• Qualsiasi altra risorsa che possa essere un collo di bottiglia come cpu o memoria.
• Se sei quel tipo di persone fortunate che proveranno su un server che i registri sono archiviati su un file system molto limitato, e questo tipo di attività consumerà ogni byte libero di esso facendo fermare l'applicazione.

Lato client

• La tua larghezza di banda

Le mie considerazioni su questa attività:

Prima fai una query DNS e vedi se c'è più di un server per quell'indirizzo. Ciò aiuterà, più server, più puoi dividere il carico.

Verifica il firewall, ottieni un VPS ed esegui alcuni test per ottenere un'ideologia del tuo ambiente senza mettere in blacklist il tuo indirizzo IP. Prova alcuni tassi, 100, 1000, 10000 al secondo. Prova il tempo medio di risposta per ogni ora del giorno. Se i tempi di risposta cambiano, quindi il tuo server ha finestre temporali che ricevono più traffico / richieste e che sarà un buon momento per non stressare il server.

Con tutti i risultati di cui sopra saprai cosa fare. Se il server ha più larghezza di banda che hai, cosa succede quasi sempre, puoi ottenere un VPS per aiutarti, sceglierne uno vicino al server. Avrai il tuo piano su quante richieste saranno ottimali per archiviare la tua soluzione, ad esempio, se i server ricevono più carico al mattino, puoi utilizzare 1000 / s durante il giorno, ad esempio dalle 8:00 alle 22:00, e usarne altrettanti i server possono rispondere dalle 22:00 alle 8:00.

Tieni presente che questo tipo di attività potrebbe causare l'arresto anomalo di alcuni servizi o un carico così grande, che non sarà in grado di rispondere agli utenti e che può essere considerato un attacco di tipo Denial of Service. Può metterti nei guai a causa di diversi fattori, non so di tutti i paesi, in diversi paesi questo tipo di attacco è un crimine. Contatta l'amministratore di sistema in merito alle tue intenzioni, prima di bloccare qualsiasi sistema e diventare responsabile di un periodo di inattività.

Un giorno non è realistico , indipendentemente dalle risorse.

Ci sono 86.400 secondi in un giorno. Arrotondare fino a 100k. Dividi 1B per 100k e ottieni 10.000 query al secondo. Questo è piuttosto grande. Il server avrà bisogno di una storia decente di bilanciamento del carico e una buona dose di capacità di calcolo. Per riferimento, se disponiamo di 100 macchine con 8 core ciascuna (per un totale di 800 core), dovremo attivare ogni richiesta al massimo 80 ms , che è stretto ma non del tutto irragionevole . Il cliente avrà anche bisogno di una capacità commisurata a quella del server e, presumendo che tu sia un attaccante black hat, probabilmente stai utilizzando una botnet o qualcosa del genere.

In realtà, devi operare una botnet, perché il client deve essere distribuito geograficamente in modo tale che il server possa bilanciare il carico senza attraversare i collegamenti di rete ad alta latenza. Questo è fondamentale perché la latenza tra server e client conta per il nostro budget di 80 ms. Se il cliente è interamente in America ma metà del server è in Europa, la latenza transatlantica rovinerà completamente le nostre prestazioni e avremo bisogno di molta più capacità per compensare il problema (altrimenti dovremo semplicemente soddisfare tutte le richieste con la metà americana del server, che presenta problemi di capacità simili).

But wait! You said 'regardless of resources.' Why are you throwing resource numbers at me?

Poiché le persone che gestiscono servizi Web su questa scala generalmente dispongono di un monitoraggio abbastanza buono da rilevare un flusso di traffico di 10k QPS da una botnet. Con ogni probabilità, il tuo obiettivo determinerà che tu stia attaccando DDoS (che è fondamentalmente quello che stai facendo) e distribuisci mitigazioni standard (ad esempio servendo 503 o CAPTCHA, oscurando il traffico, ecc.). A questo punto, il tuo attacco fallirà o almeno richiederà molto più tempo del previsto, e le autorità ora lavoreranno per smantellare la tua botnet.

Quindi se vuoi che il tuo attacco funzioni effettivamente, non puoi farlo a questa velocità. O il tuo target non può gestire il traffico, oppure è abbastanza intelligente da rilevarlo e bloccarlo.