Ich habe einen weltweit geöffneten OpenLDAP-Server (mit Benutzerkennwörtern), den ich zu sichern versuche.
Schritt 1 bestand darin, den Datenzugriff über ACLs auf authentifizierte Benutzer zu beschränken.
Schritt 2, um Brute-Force-Angriffe zu verhindern, war die Implementierung von ppolicy. Scheint gut zu funktionieren, cool.
Schritt 3 wird darin bestehen, „mit dem Benutzer umzugehen, der ausgesperrt wurde und schwört, dass es nicht seine Schuld war“, indem DN-Aussperrungen und ihre möglichen Ursachen so früh wie möglich erkannt werden.
Ich habe angefangen, Skripte zu schreiben, die das Vorhandensein des Attributs pwdAccountLockedTime prüfen, per E-Mail warnen, Klingeln läuten usw. Das ist in Ordnung, aber ich finde es schwierig, das mit Daten in den Protokollen zu verknüpfen, die besagen, wann die fraglichen Anmeldungen erfolgten, von wo aus sie durchgeführt wurden usw. Alle Daten sind da, aber sie alle zusammenzuführen ist eine echte Qual. Ich bin mir sicher, dass ich nicht der Einzige bin, der mit diesem Problem konfrontiert ist (oder versuche ich, das falsche Problem zu lösen?) und dass es Lösungen gibt, ich konnte sie nur nicht finden. Liege ich falsch?
Ich habe vergessen zu sagen, dass fail2ban nicht wirklich geeignet ist. Es gibt viele Clients, deren Adressen ich nicht unbedingt kenne, die wahrscheinlich legitime Massenanfragen an das Verzeichnis stellen und fail2ban nicht bestehen würden. Klingt seltsam, ich weiß, aber unsere Konfiguration hier ist kompliziert und wir müssen damit vorliebnehmen. Deshalb schaue ich mir ppolicy an.
Kurz gesagt, ich hätte gerne eine Möglichkeit, das Auftreten von pwdAccountLockedTime zu überwachen und, wenn das passiert, sofort die Informationen darüber zu haben, welcher Benutzer betroffen ist, die pwdFailureTime-Werte, welche Anfragen zu diesem Zeitpunkt gestellt wurden und von welchen IP-Adressen in einer einzigen, leicht lesbaren Protokolldatei. Das wäre großartig, so etwas gibt es doch sicher?
Antwort1
Ich würde Schritt 3 in Frage stellen. Das Durchsuchen der Protokolle, um möglicherweise betroffene Benutzer zu finden, behebt nicht das eigentliche Problem, nämlich dass sie sich nicht anmelden können.
Sie müssen lediglich eine Verwaltungsaktion ausführen, um das Konto mit einem temporären neuen Kennwort zurückzusetzen. Dieses Kennwort teilen Sie dem Benutzer bei seiner Beschwerde mit (nachdem Sie ihn auf andere Weise authentifiziert haben) und das er bei der nächsten Anmeldung ändern muss. All dies lässt sich über Richtlinien erreichen.