È buona norma vietare un indirizzo IP se vengono effettuati troppi tentativi di accesso?

La risposta a questa domanda dipende molto dalla posizione di sicurezza del tuo sito, che decide se il rischio di accesso non autorizzato è maggiore o minore del rischio di Denial of Service per alcuni utenti.

Per i siti ad alto rischio, potrei optare per l'opzione di blocco, in particolare laddove è probabile che la maggior parte della base utenti sia utente domestico e pertanto è probabile che disponga di indirizzi IP distinti.

Un compromesso potrebbe essere il punto in cui si rilevano gli attacchi per indovinare la password, aggiungere un po 'di anti-automazione (ad esempio CAPTCHA) ai login da quell'indirizzo IP per un po'. Ciò ha l'effetto di rendere l'attacco più difficile da eseguire senza bloccare completamente gli utenti legittimi dal sito.

Se ricevi ancora molti accessi non validi con CAPTCHA completato, sembra che tu stia vedendo un attacco più mirato (dato che probabilmente dovranno pagare per un servizio di risoluzione CAPTCHA se il tuo CAPTCHA è buono), e a quel punto sarei più propenso a bloccare l'indirizzo IP per un po 'e reindirizzare gli utenti a un messaggio che spiega il blocco (qualcosa come "attività malevole è stata rilevata dal tuo indirizzo IP, contatta l'assistenza su [your_support_email_qui]).

Come dice @Rory, dipende dalla tua posizione di sicurezza, ma se non è un sito ad alto rischio e sei preoccupato di bloccare più utenti che condividono lo stesso IP, un approccio che potresti utilizzare sarebbe quello di tenere traccia il numero di tentativi di accesso per IP e applicare una limitazione molto moderata (per un umano) che renderebbe un attacco di forza bruta proibitivamente costoso.

Ad esempio, se nell'ultimo secondo sono stati tentati più di X da un dato indirizzo IP (dove X è il numero stimato di tentativi di accesso simultanei al secondo da un singolo indirizzo IP) invia un 403 (o meglio, un 429 ) con un messaggio che dice qualcosa come "Troppi tentativi sono stati fatti di recente, si prega di attendere qualche istante e riprovare."

In questo modo, è molto improbabile che un umano abbia mai un problema anche se ha un IP condiviso, mentre qualsiasi attacco di forza bruta sarà limitato a X al secondo, che è da centinaia a migliaia di volte più lento di un non -un attacco strozzato.

Se volevi renderlo un po 'più sicuro senza ricorrere al bando automatico, potresti anche inviare un'e-mail automatica per supportare ogni volta che la soglia massima di accesso è stata raggiunta un numero eccessivo di volte (forse 100) da un singolo IP . In questo modo puoi esaminare i log e decidere autonomamente se quel particolare indirizzo IP vale o meno il perma-banning.

Questo approccio scambia un po 'di sicurezza per l'usabilità, dal momento che stiamo evitando i captcha o qualsiasi altra cosa che possa rallentare un umano.

Vorrei menzionare un altro problema: questa può essere una catastrofe di usabilità ...

Questo blocco può essere molto fastidioso (mi è successo più di una volta). Si consideri il caso di un provider internet con indirizzi IPv6 nativi in cui IPv4 è disponibile solo tramite NAT. Diciamo che ci sono 1000 persone dietro questo NAT, cioè 1000 persone con lo stesso indirizzo IP. Se ne vietate solo uno dal loro indirizzo (probabilmente IPv4?), Vietate anche le altre 999 persone. Sembra una buona idea? Io non la penso così Non sono sicuro degli effetti collaterali se controlli l'indirizzo IPv6.

(lo scenario sopra con IPv4-only-over-NAT si applica almeno per alcuni dei principali provider di Internet in Germania)

Un'altra soluzione praticabile è creare un meccanismo alternativo per l'accesso dell'utente. L'utente sarebbe in grado di utilizzare questo meccanismo alternativo quando il normale meccanismo di accesso è stato disabilitato (a causa di troppi tentativi di accesso falliti da parte di Mallory)

Questo meccanismo alternativo in genere richiederebbe molte più informazioni per garantire che solo l'utente reale sia in grado di accedere con successo. Ad esempio, oltre alla password potremmo richiedere all'utente di fornire uno o più di questi:

• un codice SMS

• un dongle hardware

• un codice inviato a un'email (protetta)

Questo meccanismo alternativo non deve essere limitato ai tassi (altrimenti Mallory semplicemente lo invierà con la spazzatura per ottenere la negazione del servizio).

Poiché non è limitato in base alla frequenza, gli input devono essere abbastanza lunghi da resistere agli attacchi "infiniti" di forza bruta.