Używamy łącznie 7 standardowych wersji systemu Windows Server (2008/2012) R2 dla środowisk programistycznych i produkcyjnych. W zeszłym miesiącu nasze serwery zostały przejęte i znaleźliśmy wiele dzienników nieudanych prób w przeglądarce zdarzeń Windows. Próbowaliśmy IDDS cyberbroni, ale wcześniej nie okazało się to dobre.
Teraz ponownie zobrazowaliśmy wszystkie nasze serwery i zmieniliśmy nazwy kont administratora / gości. Po ponownym skonfigurowaniu serwerów używamy tego identyfikatora do wykrywania i blokowania niepożądanych adresów IP.
IDDS działa dobrze, ale wciąż otrzymujemy 4625 zdarzeń w podglądzie zdarzeń bez źródłowego adresu IP. Jak mogę zablokować te żądania z anonimowych adresów IP?
<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='2015-04-18T15:18:10.818780700Z'/>
<EventRecordID>187035</EventRecordID>
<Correlation/>
<Execution ProcessID='24876' ThreadID='133888'/>
<Channel>Security</Channel>
<Computer>s17751123</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'>aaron</Data>
<Data Name='TargetDomainName'>\aaron</Data>
<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'>SSAWSTS01</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>
<Data Name='IpPort'>-</Data>
</EventData>
</Event>
AKTUALIZACJA: Po sprawdzeniu moich dzienników zapory sieciowej wydaje mi się, że te 4625 zdarzeń nie są powiązane z Rdp, ale mogą być SSH lub innymi próbami, których nie znam
Odpowiedzi:
Adres IP dla nieudanych prób RDP jest rejestrowany tutaj nawet przy włączonej NLA (nie wymaga żadnych poprawek) (testowane na Server 2012 R2, niepewność co do innych wersji)
Dzienniki aplikacji i usług> Microsoft-Windows-RemoteDesktopServices-RdpCoreTS / Operational (identyfikator zdarzenia 140)
Przykład zarejestrowanego tekstu:
XML:
źródło
Jest to znane ograniczenie w przypadku zdarzenia 4625 i połączeń RDP korzystających z TLS / SSL. Będziesz musiał użyć szyfrowania RDP dla ustawień serwera zdalnego pulpitu lub uzyskać lepszy produkt IDS.
źródło
Należy użyć wbudowanej Zapory systemu Windows i jej ustawień rejestrowania. Dzienniki podają adresy IP wszystkich prób połączenia przychodzącego. Ponieważ wspomniałeś, że wszystkie twoje serwery są połączone z Internetem, naprawdę nie ma usprawiedliwienia dla nieużywania Zapory systemu Windows jako części strategii dogłębnej obrony. Szczególnie polecałbym nie wyłączać NLA (uwierzytelnianie na poziomie sieci), ponieważ wiele ataków na RDP w przeszłości było w przeszłości ograniczanych przez użycie NLA i dotyczyło tylko hostów sesji RDP z klasycznym szyfrowaniem RDP.
źródło
To zdarzenie jest zwykle spowodowane przez nieaktualne ukryte dane uwierzytelniające. Wypróbuj to w systemie, podając błąd:
Z poziomu wiersza poleceń:
psexec -i -s -d cmd.exe
Z nowego okna cmd uruchom:
rundll32 keymgr.dll,KRShowKeyMgr
Usuń wszystkie elementy, które pojawiają się na liście Przechowywanych nazw użytkowników i haseł. Zrestartuj komputer.
źródło