Come identificare in modo univoco gli utenti con lo stesso indirizzo IP esterno?

How to uniquely identify users with the same external IP address? Is there any way to uniquely identify such users?

Sì, ci sono molti modi:

• Cookie
• Evercookies (codice JavaScript che utilizza molte tecniche diverse per memorizzare le informazioni di identificazione, tra cui i flash cookie, le varie opzioni di archiviazione HTML5, i browser hanno visitato la cronologia dei collegamenti, ecc.)
• Fingerprinting del dispositivo: usa l'intestazione HTTP (principalmente User Agent, ma anche le altre intestazioni e il loro ordine possono aiutarti)
• Fingerprinting del dispositivo con JavaScript: con JavaScript, puoi ottenere molte informazioni, come risoluzione dello schermo, fuso orario, plug-in, caratteri di sistema, ecc.
• Comportamento: la velocità con cui gli utenti compilano i moduli, dove su un pulsante fanno clic, ecc.

Ma la maggior parte di questi non è utile nella difesa dagli attacchi di forza bruta, dal momento che il programma che li sta eseguendo probabilmente non accetterà i cookie o eseguirà JavaScript.

Nel tuo caso, potresti provare:

• Intestazione HTTP: potrebbero essere già sufficienti per distinguere gli utenti che utilizzano lo stesso indirizzo IP (ovviamente, un utente malintenzionato può semplicemente cambiarli a caso, ma suppongo che la maggior parte al momento non lo faccia).
• Accelerazione della luce: non è necessario bloccare gli indirizzi IP, è sufficiente rallentare la procedura di accesso per loro. In questo modo, la forzatura bruta diventa molto meno fattibile, ma gli utenti reali che utilizzano lo stesso indirizzo IP possono ancora accedere.
• CAPTCHA : questi infastidiranno gli utenti legittimi, ma si spera che non molti utenti usino effettivamente un indirizzo IP da cui provengono gli attacchi di forza bruta (Naturalmente, ci sono strumenti per risolvere automaticamente i CAPTCHA, ma è ancora più difficile di nessun CAPTCHA).
• Potrebbe essere necessario che un utente accetti i cookie e invii varie informazioni identificative prima di poter accedere (come la risoluzione dello schermo, il fuso orario, ecc.). Ovviamente, anche un hacker può farlo, ma non credo che nessuno strumento bruteforce possa farlo, quindi dovrebbero scrivere uno script personalizzato. Ma questo potrebbe anche infastidire gli utenti legittimi.

Puoi ottenere l'indirizzo IP interno degli utenti anche da Internet utilizzando HTML5 e amp; WebRTC . Puoi consultare l'articolo Local IP discovery con HTML5 WebRTC : Rischio per la sicurezza e la privacy? per ulteriori informazioni e provalo su link .

Il sito web che pubblica l'articolo sembra non essere disponibile. Tuttavia, ritengo che questo artice WebRTC abbia rilevato la perdita degli indirizzi IP locali può dare anche alcune informazioni.

Non c'è un metodo non falsificabile per quanto ne so. Se hai già accelerato il numero massimo di tentativi a otto tentativi al minuto con un timeout di un minuto. Un timeout di un minuto non è generalmente considerato fastidioso a patto che tu fornisca informazioni sufficienti all'utente.

Assicurati di rivedere attivamente questi casi in cui vi sono sospetti bruteforces da un indirizzo IP, poiché potrebbe essere interessante indagare su chi sta provando a rinforzarti.

La maggior parte degli altri metodi menzionati qui sono facilmente sconfitti e / o riducono significativamente le prestazioni.

Ecco perché i firewall per applicazioni Web (WAF) non si basano su di essi.

2 metodi affidabili sono:

• Analizza la sequenza di pacchetti nell'intestazione IP: la maggior parte degli stack TCP / IP numero di pacchetti in sequenza, quindi se il numero è casuale, allora il il client è probabilmente dietro NAT (una connessione Internet condivisa con altri clienti). C'è un sovraccarico di RAM per ricordare l'ID del pacchetto precedente, ma è paragonabile a un cookie di sessione. Questo è più difficile da spoofare dal momento che l'utente malintenzionato deve riscrivere il pacchetto a un livello basso, ma non impossibile, quindi dovrebbe essere combinato con la limitazione della velocità: consentire agli IP pubblici NATted di avere più hit / secondo.
• Cookie di sessione con autenticazione crittografica: I normali cookie di sessione sono non sufficienti. Non sono crittografati con HTTP e, anche con HTTPS, potrebbero non essere parte di un payload crittografato HTTPS e quindi non autenticati. link fallo correttamente. Assicurati che non sia solo crittografato, ma autenticato / "firmato". link " fun-and-profit "Se si ha accesso solo al codice dell'app Web, questa è l'opzione migliore. Ovviamente se i cookie sono disabilitati, quindi eseguire un JavaScript sul lato client che distingue tra browser e bot (chiamare per la risoluzione dello schermo, ecc. Che un bot non supporta e restituire lo stato del bot se lo script fallisce). Combina questo con la limitazione della velocità mediante cookie di sessione autenticati o, se i cookie sono disattivati, la limitazione della velocità basata su IP ("throttling") o il blocco. Questo accetta / rifiuta la richiesta all'inizio della routine del parser IP / HTTP, conservando i cicli futuri della CPU, dal momento che un utente malintenzionato può ritentare migliaia di volte. A causa di DHCP / PPPoE / nuovi cookie di sessione, i divieti dovrebbero scadere dopo pochi minuti. Tieni presente che devi elencare in bianco gli IP non falsificati dei crawler dei motori di ricerca come Google e Baidu. Altrimenti la classifica delle ricerche potrebbe risentirne.

Se combini la tua soluzione con la limitazione della velocità, il limite di frequenza corretto dovrebbe essere 1-2 volte il numero di URL per pagina. Ad esempio, se login.php include 2 file CSS, 4 file JavaScript e 10 immagini più la stessa pagina, è necessario consentire almeno un totale di 17 risultati per cookie sessione client, al secondo. Altrimenti potresti bloccare / limitare le richieste normali.

Per gli attacchi persistenti, dovresti chiedere al tuo ISP di bloccare / blackhole la rotta verso monte.

Perché non usare le altre soluzioni?

'User-Agent:' è molto semplice da parodiare:

wget -O index.html --user-agent="My Fake Browser"

I cookie di sessione, "X-Forwarded-For:" L'intestazione HTTP e altre intestazioni sono anche banali da rubare / spoofare. Google "Firesheep" o "Cookie Manager +" o "Modifica plug-in intestazioni" o "Plug-in LiveHeaders" ecc. Per prova.

La limitazione della velocità non è sufficiente da sola, perché un attacco invisibile si randomizza o aumenta il tempo di attesa tra le richieste:

wget --limit-rate=10 http://example.com/index.php

La forza bruta di solito non è il tuo unico problema. link Coding e testare una protezione efficace richiede tempo. Per risparmiare tempo e / o cicli di CPU sui server Web: si moltiplica i rifiuti se si dispone di una server farm: l'host Web dovrebbe offrire un WAF front-end con questo configurato per te. Questa è la soluzione migliore: non farlo dal lato server. Vai a monte.

L'identificazione univoca potrebbe essere difficile, ma c'è la possibilità di aggiungere variabili del server come User Agent e variabili locali come i cookie (entrambi possono essere falsificati e / o aggirati, ma almeno aggiunge alcune variazioni accanto all'indirizzo IP). Se JavaScript è un'opzione puoi provare fingerprinting del browser (JavaScript o HTML5 Canvas)