Ereignis-ID 4625 ohne Quell-IP

10

Wir verwenden insgesamt 7 Windows Server (2008/2012) R2 Standard Editions für Entwicklungs- und Produktionsumgebungen. Im letzten Monat wurden unsere Server kompromittiert und wir haben viele fehlgeschlagene Versuchsprotokolle in der Windows-Ereignisanzeige gefunden. Wir haben Cyberarms IDDS ausprobiert, aber es hat sich früher nicht als gut erwiesen.

Jetzt haben wir alle unsere Server neu abgebildet und die Administrator- / Gastkonten umbenannt. Und nachdem wir die Server erneut eingerichtet haben, verwenden wir diese IDs , um unerwünschte IP-Adressen zu erkennen und zu blockieren.

Das IDDS funktioniert gut, aber wir erhalten immer noch 4625 Ereignisse in der Ereignisanzeige ohne Quell-IP-Adresse. Wie kann ich diese Anfragen von anonymen IP-Adressen blockieren?

<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>

UPDATE: Nach dem Überprüfen meiner Firewall-Protokolle denke ich, dass diese 4625-Ereignisse ohnehin nicht mit Rdp zusammenhängen, sondern SSH oder andere Versuche sein können, mit denen ich nicht vertraut bin

windows-server-2008-r2 windows-server-2012-r2

— Alan
quelle

Warum benötigen Sie die IP-Adresse, wenn Sie den Namen der Workstation haben?

— Greg Askew

Dieser Workstation-Name ist keinem unserer Server / PCs zugewiesen. Ich glaube nicht, dass jemand eine IP-Adresse von WorkstationName erhalten kann?

— Alan

Anscheinend gibt / gab es eine Workstation mit diesem Namen - es sei denn, der Server ist mit dem Internet verbunden. Siehe diese Antwort: serverfault.com/a/403638/20701

— Greg Askew

Alle meine Server sind mit dem Internet verbunden, daher ist rdp, wie oben erwähnt, mit NTLMv2 gesichert. Außerdem werden IP-Adressen nach fehlgeschlagenen RDP-Angriffen blockiert, aber einige Protokolle in eventveiwer haben keine und die zugehörige IP-Adresse. Die IDDs, die wir verwenden, zeigen fehlgeschlagene Rdp-Angriffe getrennt von anderen 4625-Angriffen

— Alan

Die Antwort ist hier: serverfault.com/a/403638/242249

— Spongman

8

Die IP-Adresse für fehlgeschlagene RDP-Versuche wird hier auch bei aktiviertem NLA protokolliert (keine Optimierungen erforderlich) (auf Server 2012 R2 getestet, bei anderen Versionen nicht sicher).

Anwendungs- und Dienstprotokolle > Microsoft-Windows-RemoteDesktopServices-RdpCoreTS / Operational (Ereignis-ID 140)

Beispiel für protokollierten Text:

Eine Verbindung vom Clientcomputer mit der IP-Adresse 108.166.xxx.xxx ist fehlgeschlagen, da der Benutzername oder das Kennwort nicht korrekt sind.

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
quelle

Vielen Dank, und ich kann bestätigen, dass dasselbe Protokoll auch die IPs erfolgreicher Anmeldeereignisse über RDP unter Verwendung von NLA - Ereignis-ID 131 erfasst.

— Trix

Argh, kein Benutzername ???

— jjxtra

3

Dies ist eine bekannte Einschränkung bei 4625-Ereignis- und RDP-Verbindungen, die TLS / SSL verwenden. Sie müssen die RDP-Verschlüsselung für die Einstellungen des Remotedesktopservers verwenden oder ein besseres IDS-Produkt erhalten.

— Greg Askew
quelle

Wir verwenden Rdp bereits mit Verschlüsselung, wir haben bereits Cyberarms und Syspeace ausprobiert. Was gibt es sonst noch?

— Alan

2

Sie sollten die integrierte Windows-Firewall und ihre Protokollierungseinstellungen verwenden. In den Protokollen werden die IP-Adressen aller eingehenden Verbindungsversuche angezeigt. Da Sie erwähnt haben, dass alle Ihre Server mit dem Internet verbunden sind, gibt es wirklich keine Entschuldigung dafür, die Windows-Firewall nicht als Teil Ihrer umfassenden Verteidigungsstrategie zu verwenden. Ich würde ausdrücklich empfohlen wird nicht aus NLA Drehen (Netzebene Authentifizierung) , da viele der Angriffe auf RDP in der Vergangenheit hat in der Vergangenheit nur durch die Verwendung von NLA und nur betroffen RDP - Sitzung Hosts läuft klassische RDP - Verschlüsselung gemildert worden.

Windows-Firewall-Protokollierung

— Ryan Ries
quelle

Die Windows-Firewall ist mit der Protokollierung aktiviert. Das RDP ist nur für die Authentifizierung auf Netzwerkebene zulässig. Wir tun also bereits das, was Sie hier erwähnt haben. Dies ist überhaupt nicht hilfreich

— Alan,

In den Protokollen wird in 100% der Fälle angegeben, wer eine Verbindung zu Port 3389 herstellt und von welcher IP-Adresse sie stammen. Sie können diese IP-Adresse dann einer schwarzen Liste in der Windows-Firewall hinzufügen. Was möchten Sie sonst noch?

— Ryan Ries

Schauen Sie sich auch ts_block von @EvanAnderson an: github.com/EvanAnderson/ts_block

— Ryan Ries

Nachdem ich die Protokolle überprüft habe, habe ich bis jetzt keine IP am Port gefunden, die ich blockieren kann, aber wir haben IP-Adressen, die versuchen, auf unsere Server an anderen TCP-Ports zuzugreifen, wie diese IP: fe80 :: 586d: 5f1f: 165: ac2d, die ich gefunden habe mit Port Nr. 5355. Ich glaube nicht, dass diese 4625 Ereignisse aus einer Rdp-Anfrage generiert werden, möglicherweise SSH oder andere Versuche.

— Alan

Wir haben jetzt Standard-Ports geändert und unnötige Ports blockiert

— Alan

1

Dieses Ereignis wird normalerweise durch einen veralteten, versteckten Berechtigungsnachweis verursacht. Versuchen Sie dies vom System aus, das den Fehler ausgibt:

An einer Eingabeaufforderung ausführen: psexec -i -s -d cmd.exe
Aus dem neuen Cmd-Fenster ausführen: rundll32 keymgr.dll,KRShowKeyMgr

Entfernen Sie alle Elemente, die in der Liste der gespeicherten Benutzernamen und Kennwörter angezeigt werden. Starte den Computer neu.

— zea62
quelle