Ereignisprotokollierung IPAddress löst nicht immer

Question

Ich hänge das Sicherheitsereignisprotokoll mit System.Diagnostics.Eventing.Reader.EventLogWatcher-Klasse, und ich beobachte Ereignis ID 4625 auf einem 2008 Server-Feld für eingehende fehlgeschlagene Anmeldungen (RDP, speziell).

Die Protokollerfassung funktioniert gut, und ich bin die Ergebnisse in eine Warteschlange für verwandte, spätere Verarbeitung Dumping. Manchmal enthalten die erfassten Protokolle jedoch das IPAddress-Datenfeld ausgefüllt (aufgelöst) und manchmal nicht.

Ich habe Windump während des Beobachtens des Servers ausgeführt, meine üblichen RDP-Logins von verschiedenen Servern und Betriebssystemaromen ausprobiert, und die einzige Schlussfolgerung, zu der ich kommen kann, ist ein Versionsunterschied, und keine schlechte Codierung. Obwohl ich mich irren könnte, LOL.

Das Problem ist in den Ereignisprotokollen selbst in Bezug auf diese Verbindungen. Alle fehlgeschlagenen RDP-Anmeldungen werden protokolliert und ordnungsgemäß verarbeitet. In einigen Protokollen wird jedoch die Quell-IP-Adresse der fehlgeschlagenen Verbindung nicht aufgezeichnet.

Bedeutet eine neuere Variante von mstsc, dass ein Remote-Ereignisprotokoll die Quell-IP-Adresse NICHT protokolliert? Dies scheint für jeden anderen 2008 Server zu gelten, den ich gegen diesen hooked Server betreibe. Jede 2003 oder XP-Maschine, die ich bisher ausprobiert habe, wird korrekt protokolliert.

Wenn Sie weitere Informationen benötigen, lassen Sie es mich wissen. Danke SO!

EDIT

Muss ich verrückt etwas tun müssen - wie implementieren SharpPcap und IPs korrelieren, so EventLogs? = /. Kann lsass vielleicht abgefragt werden (ist es nicht die einzige Sache, die normalerweise in das Sicherheitsprotokoll schreibt)?

Answer 1

Ich habe endlich funktioniert. Dies geschah, weil zwei Authentifizierungsmethoden für RDP-Verbindungen verwendet wurden: NTLM und User32. Ich habe die GPO-Einstellungen geändert, um die fremden NTLM-Verbindungen zu beenden.

Dies sind die GPO-Einstellungen, die ich gemacht habe, die die Magie getan haben. Bitte beachten Sie, dass dies eine Server 2008 R2-Box ist.

Required
Computerkonfiguration \ Windows-Einstellungen \ Sicherheitseinstellungen \ Sicherheitsoptionen

Netzwerksicherheit: LAN Manager-Authentifizierungsebene - Senden Sie nur NTLMv2-Antworten. LM verweigern & NTLM
Netzwerksicherheit: Beschränken NTLM: Audit Incoming NTLM Traffic - Aktivieren Sie die Überwachung für alle
Netzwerksicherheit Konten: NTLM einschränken: Ankommende NTLM-Verkehr - Verweigern alle

Empfohlen
Haben-Konten nicht Zulassen, dass Passwörter gespeichert werden - Aktiviert
Eingabeaufforderung auf dem Client-Computer anfordern - Aktiviert

Ich habe auch einige andere sicherheitsrelevante Schlüssel geändert, aber diese sollten die Kernwörter sein. Das Erzwingen des eingehenden Netzwerkverkehrs von der Verwendung von NTLM lässt zu, dass jedes einzelne 4625-Ereignis die IP-Adresse des ausgefallenen Computers enthält, da sie gezwungen sind, Benutzer32-Anmeldung zu verwenden.

Lassen Sie mich wissen, wenn dies völlig unsicher erscheint oder es eine bessere Möglichkeit gibt, dies zu tun, aber dies ermöglicht ordnungsgemäße Zählung und protokollierte fehlgeschlagene Versuche unter Beibehaltung einer Verschlüsselungsstufe für die Verbindung.

Answer 2

Die Antwort von Asteroids funktioniert, aber Sie MÜSSEN "Verbindungen von Computern mit einer beliebigen Version von Remotedesktop (weniger sicher) zulassen" anstelle von "Verbindungen nur von Computern mit Remotedesktop mit Authentifizierung auf Netzwerkebene (sicherer) zulassen" aktivieren.

NLA verwendet nicht User32, sondern verwendet NtLmSsp, das auf LM-Antworten basiert. Wenn das blockiert ist (wie es die obigen Anweisungen tun), werden Sie am Ende mit "Die lokale Sicherheitsbehörde kann nicht kontaktiert werden" enden.