Riepilogo
Dovremmo aggiungere un sistema di log di autenticazione standardizzato a Discourse che memorizzi gli eventi di autenticazione da tutti i metodi di autenticazione abilitati per l’analisi e la risoluzione dei problemi.
Dettagli
Forniremmo un provider di logging dell’autenticazione a cui ogni sistema di autenticazione si aggancerebbe e invierebbe eventi.
Ad esempio, il provider di login locale potrebbe avere il seguente elenco (non completo) di eventi:
- qualcuno da [IP] ha fallito il login come utente
fhqwhgadsche non esiste - qualcuno da [IP] ha fallito il login come utente
supermathie, è stato limitato dalla velocità - qualcuno da [IP] ha fallito il login come utente
supermathie, ma ha fornito una password non valida - qualcuno da [IP] ha effettuato il login come utente
supermathie, ha fornito una password valida - qualcuno da [IP] ha fallito il login come utente
supermathie, ha fornito una password valida, ma richiede MFA per continuare - qualcuno da [IP] ha fallito il login come utente
supermathie, ha fornito una password valida, ha fornito un codice TOTP non valido - qualcuno da [IP] ha effettuato il login come utente
supermathie, ha fornito una password valida, ha fornito un codice TOTP valido per il tokenvault-work
Il problema di fare affidamento sui log esistenti (log web) è che, ad eccezione di quello limitato dalla velocità, sembrano tutti esattamente uguali ([200] POST /session HTTP/1.1). Non c’è alcun significato che arrivi al log.
Preoccupazioni
C’è la preoccupazione che gli eventi anonimi generino voci di log e il bilanciamento di ciò con il rilevamento di eventi interessanti dal punto di vista dell’analisi SIEM, ad esempio attacchi di password spraying.
Registrare TUTTO significa che chiunque su Internet può riempire i tuoi log… ma è discutibile se questo sia effettivamente un problema o meno. Nota la conservazione di seguito - forse i fallimenti vengono conservati per un periodo di tempo più breve all’interno del log dell’applicazione.
Una domanda simile sorge riguardo ai log basati su token monouso, ad esempio login-via-email. I token errati probabilmente non sono “interessanti” da registrare, ma i token riprodotti lo sono assolutamente, sia dal contesto SIEM che dal supporto utente.
Domande
Conservazione: conservare tutto per sempre? 30 giorni? 90 giorni? eliminare gli eventi anonimi prima?
Autenticazione con chiave API: le chiamate con chiavi API utente o admin errate dovrebbero essere registrate qui? Probabilmente - aiuterà nel debug.
Quanto dovrebbe essere configurabile? ad esempio, attivare i log di debug per tutto o solo per un provider?
Considerazioni sull’implementazione
L’implementazione dovrebbe essere sufficientemente flessibile da consentire l’aggiunta di un altro provider di archiviazione eventi alla pipeline di logging. Un esempio di tale provider potrebbe essere un file di log grezzo, una coda di messaggi o un bucket S3. I dettagli esatti di un tale provider sono al di fuori dell’ambito di questo argomento, ma l’implementazione dovrebbe essere sufficientemente flessibile da consentire a un plugin di registrarsi per ricevere i log man mano che vengono generati.
Contesto
Abbiamo avuto un cliente che ha richiesto questo con l’intento di alimentare gli eventi al proprio SIEM e ci siamo resi conto che si trattava di una lacuna funzionale in Discourse.
Durante la discussione interna abbiamo anche scoperto che queste informazioni sarebbero utili agli amministratori del sito e ai nostri stessi sostenitori del supporto, poiché i log di autenticazione potrebbero trovarsi in vari posti e si dovrebbe sapere dove cercare per trovarli. Questo si basa sulla conoscenza personale e un log centrale alleggerirebbe notevolmente questo onere.
Un modo conveniente per visualizzare questi log dalla console rails sarebbe vantaggioso per noi e per gli amministratori del sito.