Identyfikator zdarzenia 4625 bez źródłowego adresu IP

10

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

Alan
źródło
Dlaczego potrzebujesz adresu IP, jeśli masz nazwę stacji roboczej?
Greg Askew
Ta nazwa stacji roboczej nie jest przypisana do żadnego z naszych serwerów / komputerów. Nie sądzę, żeby ktoś mógł uzyskać adres IP z WorkstationName?
Alan
Najwyraźniej istnieje / była stacja robocza o tej nazwie - chyba że serwer jest podłączony do Internetu. Zobacz tę odpowiedź: serverfault.com/a/403638/20701
Greg Askew
Wszystkie moje serwery są połączone z Internetem, więc jak wspomniano powyżej, rdp jest zabezpieczony za pomocą NTLMv2. Widzimy również, że adresy IP są blokowane po nieudanych atakach rdp, ale kilka dzienników w eventveiwer nie ma powiązanego adresu IP. Identyfikatory, których używamy, pokazują nieudane ataki Rdp oddzielnie niż inne ataki 4625
Alan
odpowiedź jest tutaj: serverfault.com/a/403638/242249
Spongman

Odpowiedzi:

8

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:

Połączenie z komputerem klienckim o adresie IP 108.166.xxx.xxx nie powiodło się, ponieważ nazwa użytkownika lub hasło są nieprawidłowe.

XML:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" /> 
  <EventID>140</EventID> 
  <Version>0</Version> 
  <Level>3</Level> 
  <Task>4</Task> 
  <Opcode>14</Opcode> 
  <Keywords>0x4000000000000000</Keywords> 
  <TimeCreated SystemTime="2016-11-13T11:52:25.314996400Z" /> 
  <EventRecordID>1683867</EventRecordID> 
  <Correlation ActivityID="{F4204608-FB58-4924-A3D9-B8A1B0870000}" /> 
  <Execution ProcessID="2920" ThreadID="4104" /> 
  <Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel> 
  <Computer>SERVER</Computer> 
  <Security UserID="S-1-5-20" /> 
  </System>
- <EventData>
  <Data Name="IPString">108.166.xxx.xxx</Data> 
  </EventData>
  </Event>
sheriff6241
źródło
Dziękuję i mogę potwierdzić, że ten sam dziennik przechwytuje również adresy IP udanych zdarzeń logowania przez RDP przy użyciu NLA - Identyfikator zdarzenia 131.
Trix
Argh, brak nazwy użytkownika ???
jjxtra
3

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.

Greg Askew
źródło
Już używamy Rdp z szyfrowaniem, próbowaliśmy już cyberarms i syspeace, co jeszcze jest?
Alan
2

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.

Logowanie do Zapory systemu Windows

Ryan Ries
źródło
Zapora systemu Windows jest włączona z logowaniem, protokół RDP jest dozwolony tylko w przypadku uwierzytelniania na poziomie sieci, więc już robimy to, o czym tu wspomniałeś, to wcale nie jest pomocne
Alan
Dzienniki informują, kto łączy się z portem 3389 i z jakiego adresu IP pochodzi, w 100% przypadków. Następnie możesz dodać ten adres IP do czarnej listy w Zaporze systemu Windows. Czego jeszcze chcesz?
Ryan Ries
Zobacz także ts_block z @EvanAnderson: github.com/EvanAnderson/ts_block
Ryan Ries
Po sprawdzeniu logów nie znalazłem do tej pory żadnego adresu IP na porcie, który mogę zablokować, ale mamy adresy IP próbujące uzyskać dostęp do naszych serwerów na innych portach TCP, takich jak ten ip: fe80 :: 586d: 5f1f: 165: ac2d Znalazłem z portem nr 5355. Nie sądzę, że te 4625 zdarzeń jest generowanych z żądania Rdp, może to być SSH lub inne próby.
Alan
Zmieniliśmy teraz domyślne porty i zablokowaliśmy niepotrzebne porty
Alan
1

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.

zea62
źródło