Ho un utente che viene attaccato da qualcuno o da uno script che colpisce ripetutamente l’endpoint forgot_password molte volte al giorno utilizzando il suo indirizzo e-mail. Questo sta accadendo da diversi giorni. Poiché ciò invia e-mail, è anche potenzialmente abusivo per il sistema. Dall’accesso nginx access.log, ho tracciato l’indirizzo IP per parte di questo tempo a un altro utente sul sistema e ho inviato un messaggio di avvertimento, ma ciò potrebbe non aiutare. Ho anche aggiunto questo indirizzo IP in Admin > Logs > Screened IPs; tuttavia, non sono sicuro di cosa farà esattamente, oltre a impedire temporaneamente l’accesso. L’indirizzo IP può cambiare ed è cambiato, e probabilmente si tratta di un indirizzo dinamico, ma qualcuno potrebbe anche attivare una VPN e ricominciare.
Qualcuno ha un suggerimento su come gestire questa situazione?
Ciao Dan, se non ti dispiace, ho un paio di domande preliminari.
Hai sospeso l’utente?
Permetti a chiunque di creare un account o approvi tu tutti i nuovi account?
Puoi sospendere l’utente andando su admin/users/list/active e cliccando sul nome dell’utente responsabile. Una volta sulla sua pagina delle informazioni, scorri fino a Permessi e clicca su Sospendi. Assicurati che l’utente sia disconnesso, perché la sospensione potrebbe non avere effetto finché non si disconnette. Se è ancora connesso, in alto a destra nella stessa pagina c’è una casella blu per disconnetterlo tu stesso. Una volta disconnesso, non potrà più accedere con le sue vecchie credenziali.
Se approvi i nuovi account e il “colpevole” continua con la sua infrazione (e sei sicuro di chi sia), l’utente dovrà aspettare che sia tu ad approvare l’account. Dato che hai già uno (o più?) indirizzi IP che ha utilizzato, se appare un nuovo utente con quello stesso IP, sai cosa fare.
Puoi anche visitare le preferenze dell’utente e, sotto Account, visualizzare i dispositivi utilizzati di recente, che dovrebbero mostrare anche l’indirizzo (o gli indirizzi) IP utilizzati per l’accesso. Questo potrebbe fornirti ulteriori indirizzi IP da filtrare.
È qui che l’approvazione degli account si rivela utile.
Come fa questa persona ad accedere al profilo di un altro utente per richiedere un reset della password? Questa è la domanda importante.
Ovviamente, questa ricerca non filtra le richieste legittime. Ho esaminato manualmente i dati di oggi e ieri e ho notato alcune richieste legittime (non provenienti dall’indirizzo IP ripetuto). La stragrande maggioranza proviene da un indirizzo IP ricorrente che cambia ogni pochi giorni. Non è molto grave per il sistema, ma lo è per l’utente che riceve le richieste. Penso che l’unica cosa che possa fare sia configurare nginx per bloccare gli indirizzi IP, ma dato che cambiano… forse se controllo e aggiorno manualmente per una settimana o due, la persona smetterà di provare, anche se probabilmente solo per un breve periodo. La vittima dice che questo è successo inizialmente a lui circa 1,5 anni fa.
È decisamente fastidioso se qualcuno decide di attivare ripetutamente la funzione “password dimenticata” a tuo nome… ma non possiamo bloccare l’utente dai reset della password basandoci su questo, perché impedire a qualcuno di effettuare un reset della password è anch’esso una forma di molestia.
Credo che qui ci sia un limite di frequenza dell’ordine di più tentativi al minuto; puoi esaminare questo percorso del codice @riking e confermare che funzioni ancora correttamente? Potremmo aumentarlo, ma non potrebbe coprire in modo sicuro “un paio di volte al giorno”.
Inoltre, bannare un indirizzo IP tramite Amministratore, Log, IP filtrati dovrebbe impedire a quell’indirizzo IP di richiedere un reset della password, credo, e dovremmo anche verificare che funzioni come previsto @riking.
Non c’è un’opzione per evitare di ricevere un’email per il reset della password, anche se ho l’autenticazione a due fattori attiva con chiavi di ripristino.
Alcuni siti che ho visitato mostrano il tuo indirizzo IP prima ancora che richieda un reset della password, affermando che verrà inviato alla tua email.
Tutto questo è solo un fastidio minore, dato che raramente controllo questa email per qualsiasi cosa. Tutte le email vengono filtrate e impostate su “segna messaggio come letto”, così non appare che devo leggerle. Ho configurato il filtro a gennaio e ho guardato la cartella (etichetta in Gmail) solo oggi.
L’immagine che non sono riuscito a includere nella 1ª risposta.
Quando Gmail riceve più messaggi con lo stesso oggetto, li raggruppa.
Immagino che dopo 100 messaggi identici, passi semplicemente ai successivi 100.
Una semplice soluzione che puoi adottare è cambiare la tua email da test@gmail.com a test+SOMESECRETONLYYOUKNOW@gmail.com.
Le email da Discourse arriveranno comunque al tuo solito account Gmail, ma nessuno potrà inviarti richieste di recupero password e nessuno potrà indovinare un hash sicuro.
Penso che, praticamente, questa sia la cosa migliore da fare in questo caso.
Potremmo limitare il tasso di richieste fino a una volta a settimana, ma sarebbe comunque fastidioso. Usando l’indirizzamento con il simbolo + eliminerai completamente il problema.
Possiamo limitare la frequenza delle richieste per un utente specifico, oltre che le richieste da una determinata posizione (un limite che stiamo già vedendo funzionare molto bene al momento). Forse potremmo concedere fino a 2 token di reset non scaduti prima di dire: “per favore, attendi semplicemente la email”?
Un altro approccio potrebbe consistere nel limitare temporalmente gli e-mail di reimpostazione della password, ad esempio a 3 ore tra un token e l’altro. In questo caso, se viene richiesta un’e-mail di reimpostazione della password prima della fine del periodo di attesa, può essere visualizzato un semplice messaggio: “Abbiamo già inviato un’e-mail per la reimpostazione della password; controlla la tua casella di posta. Se l’e-mail non arriva nelle prossime 2 ore, contatta l’amministratore del sito all’indirizzo %contact_email% per assistenza”.
Ho modificato l’email nel forum in ‘email+something@gmail.com’ e ho fatto un test con la navigazione in incognito su un browser diverso. Sono comunque riuscito ad accedere. Forse perché la richiesta viene sempre inviata solo con il nome utente, mai con l’indirizzo email effettivo.
Per il momento tutte le richieste false sono cessate, poiché Dan deve aver risolto il problema, sia in privato con l’individuo coinvolto sia con altri mezzi.
Se fosse disponibile un’opzione per una domanda di sicurezza (da attivare a livello di utente), sono sicuro che ridurrebbe notevolmente le richieste, dato che il troll semplicemente non conoscerebbe la risposta. “Qual è il tuo film preferito?” oppure “Il tuo ristorante preferito”.
Grazie a tutti per le vostre rapide risposte nel tentativo di risolvere questo problema, che, purtroppo, sembra essere il primo, e speriamo l’ultimo.
Immagino che il problema sia che si può semplicemente fare lo scraping di un forum per ottenere gli username e poi scatenare un’onda di richieste di recupero password per trollare.
Forse potremmo aggiungere una modalità in cui è necessario inserire l’email esattamente per attivare il recupero password: ‘Recupero password rigoroso’, disattivato di default?
Penso che anche essere presi di mira una volta a settimana sia troppo; non possiamo risolvere questo problema limitando semplicemente il tasso di richieste.
Esiste un modo per offrire uno o due reset “gratuiti” prima di imporre la digitazione esatta, entro un certo lasso di tempo? O forse aggiungere la verifica esatta solo per un singolo account dopo un certo numero di reset, ma in modo automatico e globale?
Alcuni di noi letteralmente non hanno idea di che giorno sia, figuriamoci ricordare senza errori il proprio indirizzo email esatto.
@Chinaski, spero che la situazione venga risolta rapidamente e finalmente per te.
Grazie a tutti per le risposte. Spero che quanto sopra funzioni, poiché sembra la soluzione più diretta al momento, ma non l’ho testato poiché le molestie si sono diradate. (L’utente che potrebbe aver attaccato afferma di aver disattivato gli ospiti sul suo WiFi, ma non possiamo essere certi che quella fosse la fonte.)
Con migliaia di utenti attivi (siamo ancora in fase di migrazione a Discourse), capisco il tuo dolore. Questo problema si presenta così spesso, con persone che dimenticano quale email hanno usato e cose del genere; è stato facilmente uno dei nostri ticket di supporto più richiesti negli anni, è pazzesco.
Richiedere l’inserimento dell’email per il recupero della password certamente non sarà mai una funzionalità attivata di default.
Ma se un forum è sotto assedio, come nel caso dell’OP, potrebbe essere un semplice interruttore da attivare per alcune settimane per eliminare questo fastidioso attacco.
Ho reso le regole più stringenti, così nel caso peggiore un utente può ottenere al massimo 6 reset al giorno. Questo dovrebbe limitare in una certa misura le email.
Ho anche seguito il consiglio di @riking e ora rispettiamo gli indirizzi email filtrati: se un amministratore blocca un IP, quell’IP non potrà più partecipare a questa “festa”.
Una grande omissione qui, @riking, che potrebbe aiutare un po’ l’autogestione, è che l’email di “reset della password” non include l’indirizzo IP della persona che l’ha avviata:
@codinghorror, cosa ne pensi di aggiungere l’indirizzo IP dell’initiatore nelle email di impostazione della password (potremmo anche nasconderlo in parte)? Questo permetterebbe un’autogestione molto più efficace.
Jane viene attaccata
Jane notifica all'amministratore del sito che 12.12.12.12 continua a resettare le password
L'amministratore blocca 12.12.12.12
Le persone hanno accesso a molti IP, quindi questo può ancora trasformarsi in un gioco del gatto e del topo, ma almeno è meglio di prima e i limiti sono più rigidi.
Facebook utilizza questo trucco, che trovo utile implementare:
Questo permette loro di evitare di includere gli indirizzi IP nelle email; tracciano tutto lato server e il link contiene un ID nel database. In questo modo, bloccare un abusatore può diventare un’operazione a un solo clic.
Per contesto, Facebook richiede l’email per il reset della password (non hanno nemmeno un reset della password nel senso tradizionale; si tratta semplicemente di accedere tramite email).
Ho analizzato 100 richieste false e ho individuato un pattern, che suggerisce l’uso di uno script.
Questo pattern è coerente in tutte le 100 richieste false in un singolo raggruppamento in Gmail.
Come fa questa persona ad accedere al profilo di un altro utente per richiedere un reset della password? Questa è la domanda importante.
