So finden Sie die Quelle der 4625-Ereignis-ID in Windows Server 2012

Ich habe viele Überwachungsfehler mit der Ereignis-ID 4625 und dem Anmeldetyp 3 in meinem Ereignisprotokoll.

Liegt dieses Problem auf meinem Server (interne Dienste oder Anwendungen)? Oder ist das ein Brute-Force-Angriff? Wie kann ich die Quelle dieser Anmeldungen finden und das Problem beheben?

Dies sind detaillierte Informationen auf der Registerkarte Allgemein:

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       aaman
    Account Domain:     

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xC000006D
    Sub Status:     0xC0000064

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   test2
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

**And this is detailed information in Detail Tab:**

+ System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 

   EventID 4625 

   Version 0 

   Level 0 

   Task 12544 

   Opcode 0 

   Keywords 0x8010000000000000 

  - TimeCreated 

   [ SystemTime]  2015-05-09T06:57:00.043746400Z 

   EventRecordID 2366430 

   Correlation 

  - Execution 

   [ ProcessID]  696 
   [ ThreadID]  716 

   Channel Security 

   Computer WIN-24E2M40BR7H 

   Security 


- EventData 

  SubjectUserSid S-1-0-0 
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName aaman 
  TargetDomainName  
  Status 0xc000006d 
  FailureReason %%2313 
  SubStatus 0xc0000064 
  LogonType 3 
  LogonProcessName NtLmSsp  
  AuthenticationPackageName NTLM 
  WorkstationName test2 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress - 
  IpPort - 

Ich hatte die gleiche Art von Ereignissen auf einem Server. Es gab Hunderte von Anmeldeversuchen mit unterschiedlichen Benutzernamen, aber ohne sichtbare Prozess-ID oder IP-Adresse.

Ich bin mir ziemlich sicher, dass es von RDP-Verbindungen über das Internet ohne Authentifizierung auf Netzwerkebene kam.

Arbeitslösung fand ich hier: https://github.com/DigitalRuby/IPBan

Für Windows Server 2008 oder gleichwertig sollten Sie NTLM-Anmeldungen deaktivieren und nur NTLM2-Anmeldungen zulassen. Unter Windows Server 2008 gibt es keine Möglichkeit, die IP-Adresse von NTLM-Anmeldungen abzurufen. Verwenden Sie secpol -> lokale Richtlinien -> Sicherheitsoptionen -> Netzwerksicherheit, um den eingehenden ntlm-Verkehr zu beschränken -> verweigern Sie alle Konten.

In RU-Version: Локальная политика безопасности -> Локальные политики -> Параметры безопасности -> Сетевая безопасность: ограничения NTLM: входящий трафик NTLM -> Запретить все учетные записи

Dies sind die Hack-Angriffe. Das Ziel der Angreifer ist es, die Konten / Passwörter Ihres Servers brutal zu erzwingen.

Ich würde vorschlagen, ein einfaches Intrusion Detection System (IDS) zu installieren. Möglicherweise möchten Sie RDPGuard (kommerziell), IPBan, evlWatcher in Betracht ziehen. Ich selbst benutze Cyberarms IDDS. Dieser ist einfach, hat eine benutzerfreundliche Oberfläche (erfordert jedoch .NET Framework 4.0).

Die Idee ist einfach: IDS überwacht das Sicherheitsprotokoll Ihres Servers auf verdächtige Anmeldefehler. Dann sperrt es die IP-Adresse (n), von der der Versuch kam. Sie können auch eine Festsperre konfigurieren, wenn die Versuche von den Soft-Locked-IPs fortgesetzt werden.

Wurde dabei zufällig ein Domänencontroller heruntergefahren? Dies sieht dem in diesem Artikel beschriebenen Szenario bemerkenswert ähnlich:

https://support.microsoft.com/en-us/kb/2683606

Wenn Windows in den Status "Herunterfahren" wechselt, sollte es neuen Clients, die versuchen, sich beim Domänencontroller zu authentifizieren, mitteilen, dass sie einen anderen Domänencontroller kontaktieren müssen. In einigen Fällen antwortet der DC dem Client jedoch, dass der Benutzer nicht vorhanden ist. Dies führt zu wiederholten Authentifizierungsfehlern, bis der Domänencontroller schließlich heruntergefahren wird und der Client gezwungen ist, die DCs zu wechseln.

Die in diesem Artikel vorgeschlagene Lösung besteht darin, den Netlogon-Dienst auf dem Domänencontroller zu stoppen, bevor der Server heruntergefahren wird. Dies macht es für Authentifizierungen nicht verfügbar, bevor es in den Shutdown-Status wechselt, und zwingt den Client, einen neuen DC zu finden.

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.