ROFI_1969 0 Geschrieben 7. April 2022 Melden Teilen Geschrieben 7. April 2022 (bearbeitet) Sehr geehrte Kollegen, ich habe da mal eine Frage, die ich zwar schon zig-fach im Internet gelesen habe, aber bislang habe ich noch keine befriedigende Antwort gefunden, die mir auch wirklich erklärt, warum das so ist: Es geht um das Ereignis im Windows Event Log, wenn jemand versucht, sich mit falschem Login und Passwort anzumelden. Protokolliert wird dies mit der EventID 4625. Die Failure Reason ist mit 2313 protokolliert (Unknown user name or bad password). Im TargetUserName wird auch der böse Benutzer protokolliert (in meinem Fall ROGERS). Die ProcessId, welche hierfür verantwortlich war, hat aktuell die Id 616. Dies ist bei mir die LSASS.EXE (Local Security Authority Subsystem Service). Nun meine Frage: In sehr vielen Fällen wird die IP-Adresse des Angreifers unter z. Bsp. <Data Name="IpAddress">44.33.22.11</Data> protokolliert. Dies hilft, eine Firewall Regel einzurichten, um den Banausen zu blocken. In sehr vielen Fällen aber, wie auch im unten beschriebenen Fall, wird leider nur ein Minus-Zeichen protokolliert. Weshalb ist das so? Warum wird manchmal die IP-Adresse des Angreifers protokolliert und warum manchmal nicht? <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4625</EventID> <Version>0</Version> <Level>0</Level> <Task>12544</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2022-04-07T07:28:46.747178700Z" /> <EventRecordID>122520213</EventRecordID> <Correlation /> <Execution ProcessID="616" ThreadID="9276" /> <!-- lsass.exe --> <Channel>Security</Channel> <Computer>subdomain.mydomain.de</Computer> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-0-0</Data> <Data Name="SubjectUserName">-</Data> <Data Name="SubjectDomainName">-</Data> <Data Name="SubjectLogonId">0x0</Data> <Data Name="TargetUserSid">S-1-0-0</Data> <Data Name="TargetUserName">ROGERS</Data> <Data Name="TargetDomainName" /> <Data Name="Status">0xc000006d</Data> <Data Name="FailureReason">%%2313</Data> <Data Name="SubStatus">0xc0000064</Data> <Data Name="LogonType">3</Data> <Data Name="LogonProcessName">NtLmSsp</Data> <Data Name="AuthenticationPackageName">NTLM</Data> <Data Name="WorkstationName">-</Data> <Data Name="TransmittedServices">-</Data> <Data Name="LmPackageName">-</Data> <Data Name="KeyLength">0</Data> <Data Name="ProcessId">0x0</Data> <Data Name="ProcessName">-</Data> <Data Name="IpAddress">-</Data> <!-- Warum fehlt hier die IP-Adresse? --> <Data Name="IpPort">-</Data> </EventData> </Event> bearbeitet 7. April 2022 von ROFI_1969 Zitieren Link zu diesem Kommentar
NorbertFe 2.013 Geschrieben 7. April 2022 Melden Teilen Geschrieben 7. April 2022 vor 32 Minuten schrieb ROFI_1969: Nun meine Frage: In sehr vielen Fällen wird die IP-Adresse des Angreifers unter z. Bsp. <Data Name="IpAddress">44.33.22.11</Data> protokolliert. Dies hilft, eine Firewall Regel einzurichten, um den Banausen zu blocken. Wenn man von extern so bis zu deinem Server kommt, dann hilft das "Banausen blocken" auch nicht mehr. ;) Ich würd mir eher den Kopf machen, warum du solche Einträge überhaupt im Log hast. Zitieren Link zu diesem Kommentar
daabm 1.334 Geschrieben 7. April 2022 Melden Teilen Geschrieben 7. April 2022 Aktivier mal das Netlogon Debug Logging (Nltest /DBFlag:2080FFFF - Neustart von irgendwas nicht erforderlich), dann findest die Quelle normalerweise in %Windir%\Debug\Netlogon.Log. Ursache sind transitive Logons, wir haben das z.B. bei VPN-Einwahlen oder Proxy-Authentifizierungen. Die RAS-Server stehen in einer trusted Domain, in der eigentlichen User-Domäne fehlt dann die Client-IP. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.