Zusammenfassung
Wir sollten ein standardisiertes Authentifizierungsprotokollsystem zu Discourse hinzufügen, das Authentifizierungsereignisse von allen aktivierten Authentifizierungsmethoden zur Analyse und Fehlerbehebung speichert.
Details
Wir würden einen Anbieter für Authentifizierungsprotokolle bereitstellen, in den jedes Authentifizierungssystem eingehakt wird und Ereignisse sendet.
Als Beispiel könnte der lokale Anmeldeprotokollanbieter die folgende (nicht vollständige) Liste von Ereignissen haben:
- Jemand von [IP] ist fehlgeschlagen, sich als Benutzer
fhqwhgadsanzumelden, der nicht existiert. - Jemand von [IP] ist fehlgeschlagen, sich als Benutzer
supermathieanzumelden, wurde aber Raten-limitiert. - Jemand von [IP] ist fehlgeschlagen, sich als Benutzer
supermathieanzumelden, hat aber ein ungültiges Passwort angegeben. - Jemand von [IP] hat sich erfolgreich als Benutzer
supermathieangemeldet, hat ein gültiges Passwort angegeben. - Jemand von [IP] ist fehlgeschlagen, sich als Benutzer
supermathieanzumelden, hat ein gültiges Passwort angegeben, benötigt aber MFA, um fortzufahren. - Jemand von [IP] ist fehlgeschlagen, sich als Benutzer
supermathieanzumelden, hat ein gültiges Passwort angegeben, hat aber einen ungültigen TOTP-Code angegeben. - Jemand von [IP] hat sich erfolgreich als Benutzer
supermathieangemeldet, hat ein gültiges Passwort angegeben, hat einen gültigen TOTP-Code für dasvault-work-Token angegeben.
Das Problem bei der Verwendung vorhandener Protokolle (Webprotokolle) ist, dass mit Ausnahme des Raten-limitierten alle genau gleich aussehen ([200] POST /session HTTP/1.1). Es gibt keine Bedeutung, die in das Protokoll gelangt.
Bedenken
Es besteht die Sorge, dass anonyme Ereignisse Protokolleinträge generieren und dies mit der Erkennung von Ereignissen, die aus Sicht der SIEM-Analyse interessant sind, wie z. B. Passwort-Spraying-Angriffe, in Einklang gebracht werden muss.
Das Protokollieren von ALLEM bedeutet, dass jeder im Internet Ihre Protokolle füllen kann… aber es ist fraglich, ob dies tatsächlich ein Problem ist oder nicht. Beachten Sie die Aufbewahrung unten – vielleicht werden Fehler in kürzeren Zeiträumen im Anwendungsprotokoll aufbewahrt.
Eine ähnliche Frage stellt sich bei Einmal-Token-basierten Protokollen, z. B. Anmeldung per E-Mail. Falsche Token sind wahrscheinlich nicht “interessant” zu protokollieren, aber wiederholte Token sind es absolut, sowohl aus der Sicht von SIEM als auch vom Benutzersupport.
Fragen
Aufbewahrung: alles für immer behalten? 30 Tage? 90 Tage? anonyme Ereignisse früher löschen?
API-Schlüssel-Authentifizierung: Sollen Aufrufe mit ungültigen Benutzer- oder Admin-API-Schlüsseln hier protokolliert werden? Wahrscheinlich – es wird bei der Fehlerbehebung helfen.
Wie viel sollte konfigurierbar sein? z. B. Debug-Protokolle für alles oder nur für einen Anbieter einschalten?
Implementierungsüberlegungen
Die Implementierung sollte flexibel genug sein, um einen weiteren Ereignisspeicheranbieter zur Protokollpipeline hinzuzufügen. Ein Beispiel für einen solchen Anbieter könnte eine Rohprotokolldatei, eine Nachrichtenwarteschlange oder ein S3-Bucket sein. Die genauen Details eines solchen Anbieters sind für dieses Thema nicht relevant, aber die Implementierung sollte flexibel genug sein, dass ein Plugin registriert werden kann, um generierte Protokolle zu empfangen.
Hintergrund
Ein Kunde bat uns darum mit der Absicht, die Ereignisse an sein SIEM zu übergeben, und wir erkannten, dass dies eine Funktion von Discourse war, die fehlte.
Während interner Diskussionen stellten wir auch fest, dass diese Informationen für Website-Administratoren und unsere eigenen Support-Mitarbeiter nützlich wären, da sich Authentifizierungsprotokolle an verschiedenen Orten befinden könnten und man wissen muss, wo man suchen muss, um sie zu finden. Dies basiert auf persönlichem Wissen, und ein zentrales Protokoll würde diese Belastung erheblich verringern.
Eine bequeme Möglichkeit, diese Protokolle von der Rails-Konsole aus anzuzeigen, wäre sowohl für uns als auch für Website-Administratoren von Vorteil.