Ich arbeite daran, NTLM V1-Anmeldungen in der AD-Umgebung vollständig zu entfernen. Dabei wurden viele Ereignisse gefunden, fast alle vom Benutzer „Anonymous Logon“ (4624 Ereignisse), 1 Prozent (4624 Ereignisse) stammten von einigen Benutzern. Hier habe ich also einige Fragen.
- Ist es besser, die „anonyme Anmeldung“ (über die GPO-Sicherheitseinstellungen) zu deaktivieren oder „NTLM V1“-Verbindungen zu blockieren? Welche Risiken bestehen bei einem oder beiden? Diese Anmeldeereignisse stammen meist von anderen Microsoft-Mitgliedsservern.
- Verwendet die anonyme Anmeldung immer „NTLM V1“? Wenn ich also eine anonyme Anmeldung sehe, kann ich dann davon ausgehen, dass definitiv NTLM V1 verwendet wird?
- Was genau ist der Unterschied zwischen den anonymen Anmeldeereignissen 540 und 4624? -> Hinweis: Funktionsebene ist 2008 R2
Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.
Antwort1
Die Frage, die Sie gestellt haben,"Ist es besser, die "anonyme Anmeldung" zu deaktivieren (über GPO-Sicherheitseinstellungen) oder "NTLM V1" zu blockieren?ist keine sehr gute Frage, denn diese beiden Dinge schließen sich nicht gegenseitig aus. Sie können beides tun, keines von beiden oder nur eines und in unterschiedlichem Ausmaß. Es gibt hier viele Grautöne und Sie können es nicht auf Schwarzweiß reduzieren.
Das Deaktivieren von NTLMv1 ist im Allgemeinen eine gute Idee. Dies erfolgt über die LmCompatibilityLevelRegistrierungseinstellung oder über die Gruppenrichtlinie. Beachten Sie, dass dieselbe Einstellung ein leicht unterschiedliches Verhalten hat, je nachdem, ob der Computer ein Domänencontroller oder ein Domänenmitglied ist.
http://technet.microsoft.com/en-us/library/cc960646.aspx
Das potenzielle Risiko bei der Deaktivierung von NTLMv1 besteht darin, dass die Abwärtskompatibilität mitsehralte Windows-Clients und wahrscheinlicher mit Nicht-Microsoft-Clients, die nicht NTLMv2 sprechen. Diese müssten Sie testen. Jede einigermaßen moderne und gepatchte Version von Windows kommt problemlos mit NTLMv2 mit Sitzungssicherheit zurecht (wir sprechen von allem ab Server 2000 oder besser).
Das Deaktivieren der anonymen Anmeldung ist eine ganz andere Sache. Sie können die Möglichkeit anonymer Benutzer deaktivieren, Freigaben, SAM-Konten, Registrierungsschlüssel, alle oder keine dieser Dinge oder eine Kombination davon aufzulisten. Je mehr Sie die anonyme Anmeldung einschränken, desto hypothetischer erhöhen Sie Ihre Sicherheitslage, während Sie an Benutzerfreundlichkeit und Komfort verlieren. (Beispielsweise könnten Ihre Benutzer die Möglichkeit verlieren, Datei- oder Druckerfreigaben auf einem Server aufzulisten usw.)
Man kann also nicht wirklich sagen, welchesbesser.Es handelt sich um zwei unterschiedliche Mechanismen, die zwei völlig unterschiedliche Dinge bewirken.
Ereignis 540 ist spezifisch für eine „Netzwerk“-Anmeldung, z. B. wenn ein Benutzer über das Netzwerk eine Verbindung zu einem freigegebenen Ordner oder Drucker herstellt. Es handelt sich auch um eine Ereignis-ID im Win 2003-Stil. Sie erkennen dies daran, dass sie nur aus drei Ziffern besteht. Entsprechende Ereignisse in Vista/2008 wurden in vierstellige IDs umgewandelt:
Eric Fitzgerald sagte: Ich habe zweimal (hier und hier) über die Beziehung zwischen den „alten“ Ereignis-IDs (5xx-6xx) in WS03 und früheren Windows-Versionen und zwischen den „neuen“ Sicherheitsereignis-IDs (4xxx-5xxx) in Vista und höher geschrieben.
Kurz gesagt, EventID(WS03) + 4096 = EventID(WS08) für fast alle Sicherheitsereignisse in WS03.
Ausnahmen sind die Anmeldeereignisse. Die erfolgreichen Anmeldeereignisse (540, 528) wurden zu einem einzigen Ereignis 4624 (=528 + 4096) zusammengefasst. Die fehlgeschlagenen Anmeldeereignisse (529-537, 539) wurden zu einem einzigen Ereignis 4625 (=529+4096) zusammengefasst.
Abgesehen davon gibt es Fälle, in denen alte Ereignisse veraltet sind (IPsec, wenn ich mich recht entsinne), und Fälle, in denen neue Ereignisse hinzugefügt wurden (DS Change). Dabei handelt es sich um neue Instrumente, und es ist keine „Zuordnung“ möglich. Beispielsweise ergänzen die neuen DS Change-Audit-Ereignisse die alten DS Access-Ereignisse. Sie zeichnen etwas anderes auf als die alten Ereignisse. Sie können also nicht sagen, dass das alte Ereignis xxx = das neue Ereignis yyy ist, da sie nicht gleichwertig sind. Das alte Ereignis bedeutet eine Sache und das neue Ereignis eine andere. Sie stellen unterschiedliche Instrumentierungspunkte im Betriebssystem dar und nicht nur Formatierungsänderungen in der Ereignisdarstellung im Protokoll.
Natürlich habe ich bereits früher erklärt, warum wir die Ereignisse neu nummeriert haben und (an derselben Stelle) warum der Unterschied „+4096“ ist und nicht etwas Benutzerfreundlicheres wie „+1000“. Unterm Strich ist das Ereignisschema anders. Indem wir also die Ereignis-IDs ändern (und keine wiederverwenden), erzwingen wir eine Aktualisierung der vorhandenen Automatisierung, anstatt Ereignisse einfach falsch zu interpretieren, wenn die Automatisierung die Windows-Version nicht kennt, die das Ereignis erzeugt hat. Wir wussten, dass dies mühsam wäre, aber es ist bei weitem nicht so mühsam, als wenn jeder Ereignisverbraucher Ereignisse vor und nach Vista mit denselben IDs, aber unterschiedlichem Schema kennen und eine spezielle Schreibweise dafür verwenden müsste.
Wenn Sie also zufällig die Sicherheitsereignisse vor Vista kennen, können Sie Ihr vorhandenes Wissen schnell auf Vista übertragen, indem Sie 4000 addieren, 100 addieren und 4 subtrahieren. Das können Sie im Kopf machen.
Wenn Sie jedoch eine Automatisierung implementieren möchten, sollten Sie es vermeiden, ein Diagramm mit „=Vista“-Spalten von Ereignis-ID-Nummern zu erstellen, da dies wahrscheinlich zu einer falschen Analyse eines Ereignissatzes führen wird und Sie es frustrierend finden werden, dass keine 1:1-Zuordnung vorhanden ist (und in manchen Fällen überhaupt keine Zuordnung vorliegt).
Eric