it-swarm.com.de

Sollten fehlgeschlagene Anmeldeversuche protokolliert werden

Sollten fehlgeschlagene Anmeldeversuche protokolliert werden? Ich bezweifle, dass ein verteilter Brute-Force-Angriff den verfügbaren Speicherplatz der Datenbank erschöpfen kann. Was ist die beste Vorgehensweise dafür?

Ich schütze einen öffentlich zugänglichen Webserver mit vertraulichen Daten.

Aufgrund der bisherigen Antworten stellte sich mir auch die Frage, ob Webserver-Protokolle ausreichen würden, um solche Versuche zu protokollieren. Wäre es redundant, sie in der Datenbank zu protokollieren?

41
John L.

Ja, fehlgeschlagene Anmeldeversuche sollten protokolliert werden:

  • Sie möchten wissen, wann Leute versuchen Einsteigen
  • Sie möchten verstehen, warum Ihre Konten gesperrt werden

Es ist auch sehr wichtig, dass ältere Windows-Protokollierungsprozesse dies nie genug betont haben, um erfolgreiche Anmeldeversuche zu protokollieren. Denn wenn Sie eine Reihe von fehlgeschlagenen Anmeldeversuchen haben, sollten Sie wirklich wirklich wissen, ob auf den letzten eine erfolgreiche Anmeldung folgte.

Protokolle sind relativ klein. Wenn es genügend Anmeldeversuche gab, bei denen die Protokollierung ein Problem verursachen würde, ist "nicht über die Versuche Bescheid wissen" wahrscheinlich ein Problem im schlimmsten Fall als "über sie herausgefunden, als uns die Festplatte ausgegangen ist".


Eine kurze Einschränkung - wie @Polynomial hervorhebt, sollte das Passwort nicht protokolliert werden (ich erinnere mich, dass einige Systeme dies vor 25 Jahren noch getan haben). Sie müssen sich jedoch auch darüber im Klaren sein, dass einige legitime Anmeldeversuche fehlschlagen, wenn Benutzer ihr Kennwort in das Feld Benutzername eingeben, damit Kennwörter protokolliert werden. Zweifel an mir? Durchsuchen Sie Ihre Protokolle nach Windows Event ID 4768:

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

Dementsprechend sollten Sie den Zugriff auf diese Protokolle auf die erforderlichen Personen beschränken. Speichern Sie sie nicht einfach in einem SIEM, auf das das gesamte Unternehmen Lesezugriff hat.


Update zur Adressbearbeitung:

Aufgrund der bisherigen Antworten stellte sich mir auch die Frage, ob Webserver-Protokolle ausreichen würden, um solche Versuche zu protokollieren. Wäre es redundant, sie in der Datenbank zu protokollieren?

Best Practices sind, dass Protokolle in jedem Fall an einen separaten Protokollaggregator weitergeleitet werden sollten. Beachten Sie beispielsweise PCI DSS 10.5.4. In der Praxis ist ein solcher Aggregator normalerweise ein SIEM und funktioniert wie folgt eher eine Datenbank als flache Protokolldateien.

Ja, es ist per Definition "redundant", aber es ist die Art von Redundanz, die ein Sicherheitsmerkmal ist, kein architektonischer Fehler.

Die Vorteile der Anmeldung in einer Datenbank umfassen das Suchen, Korrelieren und Summieren. Zum Beispiel die folgende Splunk-Suche:

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,Host

Ermöglicht es uns, Authentifizierungsfehler nach Benutzer und Host zusammenzufassen:

(Failed logins as per Splunk search

Beachten Sie, dass die Fähigkeit, diskrete Felder wie "Benutzer" und "Host" abzufragen, davon abhängt, ob die SIEM-Protokolle auseinander genommen werden und verstanden wird, was was bedeutet. Die Zugänglichkeit dieser Felder hier ist ein Nebeneffekt von Splunk, der die Protokolle für mich automatisch analysiert.

Angesichts der Tatsache, dass sich Ihre ursprüngliche Frage mit Speicherplatzbeschränkungen befasste, sollte darauf hingewiesen werden, dass jede Datenbank- oder SIEM-Lösung mehr Speicherplatz beansprucht als flache Textdateiprotokolle. Wenn Sie eine solche Lösung verwenden, wird sie aus Sicherheits- und Speicherverwaltungsgründen fast immer auf einem separaten Server abgelegt. (Es gibt jetzt sogar SIEM-in-the-Cloud-Lösungen, die Ihnen das Leben erleichtern!)

50
gowenfawr

Als Ergänzung zu @ gowenfawrs Antwort, die erklärt , warum Sie diese Versuche protokollieren sollten, möchte ich sagen, dass es Möglichkeiten gibt, sicherzustellen, dass Protokolle niemals erschöpft werden Ihre Festplatten.

Zumindest in der Unix-Linux-Welt ermöglichen Tools wie logrotate oder rotatelogs das Ändern der Protokolldatei, wenn ihre Größe einen bestimmten Schwellenwert überschreitet. Sie werden häufig mit dem Apache-Server (Rotatelogs stammen von Apache Foundation) oder mit dem Syslog-System verwendet.

Zum Beispiel wird logrotate verwendet, um eine Protokolldatei (in einem Ring aus mehreren Kopien, im Allgemeinen etwa 10 davon) umzubenennen und sie schließlich zu komprimieren, und warnt das Programm, das das Protokoll generiert, um die Protokolldatei durch Senden erneut zu öffnen ein dediziertes Signal oder über einen beliebigen Befehl.

Auf diese Weise bleibt die Größe Ihrer Protokolldateien unter Kontrolle, wenn Ihr Server einem DoS-Angriff ausgesetzt ist. Natürlich verlieren Sie ältere Ereignisse, aber das ist definitiv besser als ein Absturz des Servers aufgrund einer erschöpften Festplattenpartition.

8
Serge Ballesta

Es hängt wirklich davon ab, welchen Wert Sie Ihrer Meinung nach aus den Informationen ableiten könnten. Es ist nur von begrenztem Wert, Seiten mit Protokollen zu haben, die Ihnen mitteilen, dass Ihr Server angegriffen wird. Es ist mit dem Internet verbunden und wird wahrscheinlich ein Leben lang in unterschiedlichem Maße ständig bombardiert.

Abhängig von der Konfiguration Ihres Servers kann es durchaus zu einem Verfügbarkeitsproblem kommen, da Sie den verfügbaren Speicherplatz mit Protokollen erschöpft haben. Es passiert. Gowenfawr hat zu Recht festgestellt, dass Protokolle nicht viel Speicherplatz beanspruchen. Aus diesem Grund kann es Jahre dauern, bis Probleme mit der Erschöpfung des Speicherplatzes auftreten, aber sie sind ein großer Schmerz, wenn sie auftreten.

Wenn Sie sich für die Protokollierung entscheiden, müssen Sie eine Protokollverwaltungsstrategie entwerfen und einige der folgenden Punkte berücksichtigen:

  • Was mache ich mit meinen Protokollen? Was passiert, nachdem Sie festgestellt haben, dass jemand versucht, Zugriff auf Ihr System zu erhalten ?
  • Enthalten meine Protokolle potenziell sensible Daten? (Denken Sie daran, echte Benutzer können manchmal ihre Anmeldeinformationen fetten Finger). Wenn die Antwort Ja lautet, sollten Sie entweder die Protokolle vor dem Speichern bereinigen oder sie in Ruhe einmal verschlüsseln
  • Ausführlichkeits- und Protokollereignisse
  • Wie oft sollte ich Protokolle drehen? Protokollrotation ist eine ziemlich übliche Methode, um mit Protokollgrößen umzugehen. Sie können damit alte Protokolle komprimieren und möglicherweise besonders alte Protokollarchive löschen
  • Sicherheitsinformationen und Ereignisverwaltung. _Sie haben erwähnt, dass Ihr Server vertrauliche Informationen enthält, je nachdem, was Sie in Betracht ziehen sollten, um SIEM Produkte zu untersuchen, die Ihnen nützliche Erkenntnisse liefern können Protokollierung und andere Daten wie Warnungen, Dashboards, Forensik usw.

Wenn ich persönlich spreche, finde ich Protokolle nur nützlich für forensische Analysen - sie helfen dabei, herauszufinden, was nach einem erfolgreichen Verstoß passiert ist. Wie Gowenfawr erwähnte; Das Protokollieren erfolgreicher Versuche, sich bei einem System anzumelden, ist genauso (wahrscheinlich wichtiger) als die fehlgeschlagenen.

Ein letzter Punkt: Ihr Anmeldemechanismus sollte so aufgebaut sein, dass die Wahrscheinlichkeit, dass eine verteilte Brute Force jemals funktioniert, verschwindend gering ist. Sie haben nicht viele Details zu dem, was Sie erstellt haben, angegeben, aber die Verwendung starker Backend-Algorithmen, insbesondere rechenintensiver Hashes und die Einführung von Backoff-Timing bei Anmeldeversuchen, kann die Wahrscheinlichkeit, dass ein Angreifer jemals auf diese Weise Zugriff erhält, erheblich verringern.

4
Rob C