Come implementare correttamente le difese contro la forzatura bruta? È meglio memorizzare quante volte qualcuno ha provato ad accedere e bloccarlo dopo X tentativi? E come potrebbe essere identificato "qualcuno"? Con la seduta? Un IP?
Come implementare correttamente le difese contro la forzatura bruta? È meglio memorizzare quante volte qualcuno ha provato ad accedere e bloccarlo dopo X tentativi? E come potrebbe essere identificato "qualcuno"? Con la seduta? Un IP?
La risposta per negare la forza bruta è negare un gran numero di tentativi, dove grande è definito dallo spazio della chiave e dall'accettazione del rischio.
Ogni situazione avrà soluzioni diverse.
Spazio per la carne
Computer
Tutte le soluzioni hanno anche dei compromessi come qualsiasi altra cosa nella vita.
Il blocco dell'account è un'opzione, in cui l'account viene bloccato in modo permanente o per un periodo di tempo dopo x accessi non riusciti. I problemi qui sono i rischi di Denial of Service se un utente malintenzionato tenta di indovinare le password e anche il sovraccarico amministrativo di reimpostazione degli account (supponendo che non sia disponibile un ripristino automatico)
Un'altra opzione è introdurre CAPTCHA nel processo di accesso . Questo ha lo scopo di limitare gli attacchi automatici e bloccare la negazione del servizio dai blocchi degli account. I problemi con esso possono essere i requisiti di accessibilità e il cracking CAPTCHA automatizzato. Da quello che ho visto alcuni CAPTCHA sono più facili da decifrare per il software rispetto ad altri.
Una terza opzione è introdurre un ritardo progressivo nel processo di accesso, quindi per ogni accesso sbagliato fai sì che il processo diventi sempre più lento. Ciò ha un effetto limitato sugli utenti reali ma rende la forzatura bruta automatizzata molto più difficile.
In termini della seconda parte della tua domanda sull'identificazione del "qualcuno" che sta effettuando l'attacco, dipende da cosa stanno facendo . Se stanno solo attaccando un singolo utente, il nome utente è l'identificatore e le azioni sono legate a quell'account. Se stanno forzando brute su un'ampia gamma di utenti, l'IP di origine (forse combinato con l'agente del browser) è un'opzione. Non è perfetto (ad esempio, uso di botnet, spoofing di agenti) ma è probabilmente l'unica informazione su cui dovresti continuare.
L'importante è come identificare il "qualcuno"?
Non puoi farlo tramite l'indirizzo IP: molti utenti potrebbero avere lo stesso indirizzo cliente (questo diventerà ancora di più frequente con il continuo problema della mancanza di indirizzi IPV4).
Può sembrare che un utente si connetta da più indirizzi client, ad es. utilizzando i proxy con bilanciamento del carico di AOL, o meno legittimamente, tramite tor.
Qualsiasi altra cosa sono dati forniti dal client, quindi possono potenzialmente modificare qualsiasi cookie impostato, la stringa dello user-agent ecc.
L'unico approccio pratico è applicare il punteggio euristico alla richiesta per cercare di confrontarla con i tentativi precedenti, ma sarà comunque impossibile distinguere tra attacchi sofisticati e utenti legittimi.
Imposta un punteggio soglia alla quale ritieni che il client stia tentando di forzare il tuo sito, ad esempio -20.
La richiesta di una sessione valida corrente a cui fa riferimento un cookie di sessione (che non è impostato nella pagina che richiede un nome utente / password) è un inizio: se il cookie non viene presentato con i dettagli di autenticazione, reindirizza a una pagina separata che rilascia il cookie e inizializza la sessione con un punteggio di -10 e un punteggio di (ad esempio ) -2 all'indirizzo IP del client. Puoi utilizzare un meccanismo di punteggio dinamico quando inizi a vedere più utenti validi dallo stesso indirizzo. Allo stesso modo potresti mantenere il punteggio dinamico per user-agent e per nome utente.
Quando cookie + auth vengono presentati per un utente inesistente, aggiungi un punteggio di -5 alla sessione, -1 al client address, -5 al nome utente.
Quando cookie + auth viene presentato con una password non valida, aggiungi un punteggio di -3 alla sessione, -1 all'indirizzo del client, -4 al nome utente.
Quando cookie + autenticazione + password valida aggiunge +4 dal punteggio per l'indirizzo client, +3 al nome utente, +2 allo user-agent.
NB è anche necessario impostare un decadimento per consentire il recupero di qualsiasi punteggio tenuto contro indirizzo cliente / agente utente / nome utente, ad esempio + 2 / ora
Devi pensare a cosa succede quando il punteggio supera la soglia. Hai fornito a chiunque un meccanismo per bloccare l'accesso al tuo sito?
Se hai bloccato l'accesso con un punteggio alto per un nome utente specifico, invia un'e-mail con un URL di ripristino all'utente registrato per quello account in modo che possano resettare il punteggio detenuto per il loro nome utente e ridurre il punteggio detenuto per il loro user-agent / indirizzo.
Come suggerisco, intendi il bruteforcing di login / password nell'applicazione web.
Nessuno bruteforza manualmente. Quindi, se ci sono dubbi sul fatto che questo sia un essere umano che cerca di autenticarsi, mostra Captcha, diciamo, dal tentativo di accesso 3-d fallito. Inoltre puoi mettere un timeout tra i tentativi di accesso, ma questo non funzionerà per attacchi distribuiti da IP diversi. Successivamente, ci sono due tipi di bruteforcing: cieco, solo tentativo di login / password casuale e attacco contro un utente. Per l'ultimo attacco è efficace implementare funzionalità come il blocco dell'account per un po 'di tempo e la notifica all'utente tramite e-mail. Per i ciechi la mitigazione della forza bruta può essere più difficile da implementare, soprattutto se il sito è popolare. In questo caso è possibile tenere traccia di tali informazioni sull'utente come IP / Paese / Browser / ecc. E, cercando di combinarle, è possibile ipotizzare se si tratta di un utente valido. Come aggiunta a questo, puoi giocare con i cookie di lunga durata: una volta che l'utente ha effettuato l'accesso, salva il cookie e in seguito lo verifica.
Senza una soluzione di tipo web-application è possibile implementare il server soluzioni di livello come mod_evasive di Apache. O anche scrivere il proprio modulo web-server, specificamente per tali scopi.
Certo, ci sono molti altri modi per rafforzare la mitigazione degli attacchi bruteforce, ma spesso risultano rumorosi, piuttosto inutili e sgradevoli. Cerca di restare con i KISS.
Memorizza i lunghi ips dei precedenti accessi e tentativi di accesso.
Dopo N tentativi falliti metterli contro captcha.
Blocca rapidamente gli indirizzi che non hanno accessi riusciti nella loro cronologia ma un numero di tentativi.
Blocca rapidamente indirizzi che hanno un indirizzo sorgente simultaneo o tentativi inumani a velocità / staminarapidi.
Inoltre, nessuna di queste risposte tiene conto del metodo di forzatura bruta in cui un utente malintenzionato utilizza una password e la prova contro tutti gli account, un'inversione del normale processo e uno contro cui generalmente non è protetto.
Il controllo sarebbe ovviamente quello di avere un processo che monitora più tentativi contro diversi account con la stessa password, ma ancora una volta molto difficile da bloccare anche se provengono da un unico indirizzo, così come blocchi quell'IP ? Potrebbe essere utilizzato anche da utenti validi o semplicemente interrompi gli accessi con quella password, con il rischio di bloccare un utente valido con quella password?
E ovviamente se un utente malintenzionato esegue questo tipo di cosa da una rete distribuita, o su un lungo periodo di tempo, come si correlano gli incidenti in un profilo di attacco?
I meccanismi generali del settore includono il blocco
In primo luogo, ha senso capire quali scenari / attacchi intendi gestire:
(Vedi? Non è così semplice, non è ...) E ci sono diverse soluzioni per ciascuna parte di questi ...
Se si tratta di un sito web aziendale, utilizza il certificato più l'autenticazione della password. Senza un certificato valido non arrivano mai al punto di provare a indovinare la password. Puoi anche usare qualcosa come RSA SecurID al posto del certificato.