Bruteforce vs Denial of Service

Per gli account di amministrazione, avevi ragione, richiedere una VPN è la giusta direzione.
Meglio ancora, richiedono l'autenticazione a più fattori per gli utenti amministratori.

Queste sono sempre buone idee.

Detto questo, se per qualsiasi motivo non è fattibile e sei bloccato con regolari accessi alle password pubbliche, non tutto è perduto.

Supponendo che i tuoi account admin siano tutti soggetti a una politica di password complessa, la forza bruta diretta richiederà molti, molti, molti, molti tentativi. Tentando di forzare la password tramite il modulo di login, tramite Internet, ci vorrà un tempo molto, molto, molto, molto, molto lungo - e ciò sarà fattibile solo se è possibile eseguire molti tentativi di accesso in parallelo, usando molti computers.
L'elemento chiave qui è velocità .

Quindi, la soluzione è di rallentare i ripetuti tentativi di accesso, senza arrestare realmente l'utente reale (chi sta tentando di accedere con lo stesso account nello stesso momento in cui sta andando avanti la bruteforce).
No, non pensate nemmeno di provare CAPTCHA - mentre questi hanno qualche piccolo effetto, non è neanche lontanamente abbastanza da rallentare il flusso di attacchi, di un ordine di grandezza (la migliore scommessa è probabilmente intorno al 20% - non abbastanza lento) .

Una soluzione molto più efficace (e più semplice), è limitando la frequenza .
Cioè non più di 5 tentativi di accesso in un minuto. O 50. O anche 500.
Questo può anche essere visto come un meccanismo di blocco automatico rilasciato, con un ritardo molto breve.
La matematica è ancora a tuo favore - puoi tapparla in ogni caso a seconda delle minacce previste) e puoi comunque lasciare il margine per consentire al vero utente di accedere.

Dopo diversi lockout, potresti voler implementare lockout più lunghi per IP, ma fai attenzione con questo approccio, poiché gli indirizzi IP di solito non si allineano con un utente specifico (IP condiviso, IP di roaming, ecc.). Quindi usalo, se devi, ma gentilmente.

Inoltre, assicurati di avvisare un amministratore, dopo diversi blocchi, consentendo ulteriori risposte manuali.

Per una soluzione semplice, direi di implementare un ritardo in aumento esponenziale per utente per indirizzo IP.

Ritardo richiesto tra i tentativi 1 e 2 dall'IP a.b.c.d per l'utente x : 1 secondi

... tentativi 2 e 3: 2 secondi

... tentativi 3 e 4: 4 secondi

...

... tentativi 7 e 8: 1 minuto 4 secondi

In questo modo un avversario non può accedere a DoS da un indirizzo IP o da un singolo utente e la forza bruta viene mitigata in modo abbastanza efficace perché il ritardo diventa rapidamente irragionevole. Anche se hanno accesso a un gran numero di indirizzi IP, probabilmente non ci sarebbe abbastanza per forzare lo spazio delle chiavi della password, solo alcune parole del dizionario.

Questo vorrebbe consentire agli utenti con forza bruta la stessa password, ma se vedi quel numero di richieste non riuscite dovresti probabilmente segnalarlo comunque (nel senso che un utente con più tentativi falliti è probabilmente non insolito, ma molti utenti con cattivi tentativi dallo stesso indirizzo IP in rapida successione sarebbero sospettosi).

Il modo corretto per farlo consiste nell'utilizzare un limite di velocità per IP e introdurre un CAPTCHA all'accesso per gli account utente che hanno avuto un numero elevato di tentativi di accesso non validi. Il CAPTCHA non ha bisogno di essere particolarmente strong, in quanto è principalmente lì per prevenire attacchi drive-by non mirati. Uno dei vantaggi di questo metodo è che impedisce gli attacchi con molti password per utente singolo e gli attacchi con password singola per più utenti, senza causare la condizione DoS.

Tuttavia, vorrei sconsigliare un timeout infinito. Se un utente malintenzionato si trova sulla stessa rete dell'utente, potrebbe avere lo stesso indirizzo IP pubblicamente, consentendo loro di interrompere l'utente per sempre inviando richieste di accesso errate. Questo potrebbe essere un caso piuttosto oscuro per la maggior parte, ma prendere in considerazione le reti universitarie e scolastiche. Invece, la limitazione della velocità non imporrebbe alcun ritardo sui primi 2 tentativi falliti, 5 secondi sul terzo tentativo, 15 secondi sul 3 ° e 30 secondi per tutti i tentativi successivi.

Un caso interessante è un attacco a password singola con molti utenti da un gran numero di IP sorgente, ad es. sopra Tor. Questo probabilmente sconfiggere la maggior parte di questi meccanismi. Uno dei modi migliori che ho visto per prevenire uno scenario di attacco di questo tipo è il monitoraggio della frequenza di accesso globale e l'introduzione di limiti di velocità e CAPTCHA in tutto il sito quando viene rilevato un attacco su larga scala.

Per gli account di amministratore fissi, potrebbe valere la pena avere una schermata di accesso separata. Ciò può essere monitorato e controllato molto più strettamente e consente di evitare problemi con la maggior parte dei tentativi di guida.

Un altro meccanismo utile per aumentare il costo dei tentativi di indovinare la password è una funzione di prova del lavoro sul lato client. Ho visto questi in uso su alcuni siti, e penso che siano abbastanza accurati. Essenzialmente il server invia un valore di sfida c e il client deve calcolare un valore di sale s tale che i primi bit n di sha1(c || s) siano zero. Il valore di n può essere ottimizzato nello stesso modo in cui un conteggio di iterazione può essere ottimizzato in un algoritmo di derivazione chiave. Il client deve calcolare un valore di s (tramite forza bruta) che soddisfi i criteri e inviarlo al server. Il server può quindi verificare banalmente ed economicamente che s sia corretto. L'implementazione di questo sul lato client sarebbe normalmente effettuata in JavaScript. Per gli utenti legittimi, questo non dovrebbe richiedere più di un secondo di ritardo all'accesso, ma per gli aggressori che utilizzano i propri sistemi per tentare migliaia di password aumenta il costo in termini di tempo e consumo energetico. Inoltre, nei casi in cui una botnet o altro malware viene utilizzato come piattaforma per questi tentativi di password, l'utilizzo elevato della CPU è più probabile che avvisa l'utente di qualcosa che non va nella loro macchina.

Potrei suggerire una soluzione low tech? Non avere account predefiniti. Rimuovere root e administrator su linux / windows è la prima cosa che faccio. Non posso parlare verso un pannello di gestione sconosciuto, ma questa potrebbe essere un'opzione.

Il blocco continuo degli IP che eseguono attacchi bruteforce è un ottimo modo per farlo. Se la tua applicazione registra i tentativi falliti in una posizione standard come syslog, puoi facilmente scrivere una prigione per fail2ban per bloccare automaticamente gli IP offensivi dopo un certo numero di errori di autenticazione.

Quelle domande sull'immagine. Sai, che parola c'è in questa immagine ... Dopo il tentativo fallito 3 devi rispondere quale parola è nella foto per spingere il tuo tentativo di accedere. In questo modo in realtà non blocchi l'account, ma impedisci al sistema automatico di continuare a funzionare cambiando la richiesta di input.

Se sei preoccupato può essere OCR fare una domanda che ha più risposte con una bolla riempire in (pulsante di scelta), cioè fare una domanda che un essere umano avrebbe saputo, ma nessuna macchina avrebbe saputo.

Quale delle seguenti rime con l'arancione?

A) Washington B) Nulla C) Sasquatch ecc ...

Anche combinali.

Infine, utilizza l'autenticazione a più fattori. Accedo al mio account StarCraft (il valore geek è appena salito) utilizzando un'app per iOS per darmi un token.

Alcune cose vengono in mente.

1) Non utilizzare nomi utente amministrativi predefiniti ... mai. Non c'è motivo per questo. Mentre la sicurezza per oscurità non è veramente sicura, lasciare i tuoi nomi utente amministrativi evidenti rende comunque la vita più semplice per un utente malintenzionato. Se non conoscono il nome utente dell'amministratore, non possono provare a tenerlo bloccato.

2) Autentica automaticamente la sessione dall'e-mail per reimpostare la password / consentire l'accesso. Ciò consente un approccio alternativo per entrare senza doversi preoccupare del blocco. È più noioso in quanto richiede l'invio di una e-mail per permetterti di entrare, ma funziona. Una volta entrato, cambiare di nuovo il nome utente fermerà effettivamente l'attacco.

3) Whitelist IP: questa opzione dovrebbe sempre essere un'opzione, potresti farlo essere inserito nella whitelist per un periodo limitato se lo desideri e potresti farlo in modo simile a come funziona # 2, dove la whitelist verrà aggiunta quando l'e-mail il collegamento è stato cliccato.

4) Le VPN come hai detto funzioneranno, è simile in linea di principio alla whitelisting di un IP, ma consentirebbe un IP legittimo per un client legittimo. A seconda del contesto, potrebbe essere eccessivo il modo in cui cambiare un nome utente è ancora il modo più semplice per aggirare questo tipo di attacco DoS.

Non blocchi un utente solo con il suo nome utente, lo blocchi per username + IP. In questo modo l'utente legittimo non verrà bloccato. D'altra parte, dos bot dovrà cambiare IP e alla fine sarà bloccato l'intero intervallo IP della bot farm.