Comment trouver la source de l'ID d'événement 4625 dans Windows Server 2012

J'ai plusieurs échecs d'audit avec l'ID d'événement 4625 et le type d'ouverture de session 3 dans mon journal des événements.

Ce problème provient-il de mon serveur (services ou applications internes)? Ou c'est une attaque par force brute? Enfin, comment puis-je trouver la source de ces connexions et résoudre le problème?

Ce sont des informations détaillées dans l'onglet Général:

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 - 

J'ai eu le même type d'événements sur un serveur. Il y a eu des centaines de tentatives de connexion avec des noms d'utilisateur différents mais aucun ID de processus ou adresse IP visible.

Je suis presque sûr qu'il provenait de connexions RDP sur Internet sans authentification au niveau du réseau.

Solution de travail que j'ai trouvée ici: https://github.com/DigitalRuby/IPBan

Pour Windows Server 2008 ou équivalent, vous devez désactiver les connexions NTLM et autoriser uniquement les connexions NTLM2. Sur Windows Server 2008, il n'y a aucun moyen d'obtenir l'adresse IP des connexions NTLM. Utilisez secpol -> politiques locales -> options de sécurité -> sécurité du réseau restreindre le trafic ntlm entrant ntlm -> refuser tous les comptes.

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

Ce sont les attaques de piratage. Le but des attaquants est de forcer brutalement les comptes / mots de passe de votre serveur.

Je suggère d'installer un simple système de détection d'intrusion (IDS). Vous voudrez peut-être considérer RDPGuard (commercial), IPBan, evlWatcher. Moi-même, j'utilise les Cyberarm IDDS. Celui-ci est simple, possède une interface conviviale (nécessite cependant .NET Framework 4.0).

L'idée est simple: IDS surveille le journal de sécurité de votre serveur pour les événements d'échec de connexion suspects. Ensuite, il verrouille les adresses IP, d'où vient la tentative. Vous pouvez également configurer un verrouillage matériel lorsque les tentatives à partir des adresses IP verrouillées se poursuivent.

Y a-t-il eu un arrêt de contrôleur de domaine lorsque cela s'est produit? Cela ressemble remarquablement au scénario décrit dans cet article:

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

Lorsque Windows entre dans l'état d'arrêt, il doit indiquer aux nouveaux clients qui tentent de s'authentifier auprès du contrôleur de domaine qu'ils doivent contacter un autre contrôleur de domaine. Dans certains cas, cependant, le contrôleur de domaine répondra au client que l'utilisateur n'existe pas. Cela entraînera des échecs d'authentification répétés jusqu'à ce que le contrôleur de domaine finisse par s'arrêter et que le client soit obligé de changer de contrôleur de domaine.

La solution proposée dans cet article consiste à arrêter le service netlogon sur le contrôleur de domaine avant d'arrêter le serveur. Cela le rend indisponible pour les authentifications avant qu'il ne passe à l'état d'arrêt et force le client à trouver un nouveau contrôleur de domaine.

Cet événement est généralement provoqué par des informations d'identification cachées périmées. Essayez ceci à partir du système donnant l'erreur:

Depuis une invite de commande, exécutez: psexec -i -s -d cmd.exe
Depuis la nouvelle fenêtre cmd, exécutez: rundll32 keymgr.dll,KRShowKeyMgr

Supprimez tous les éléments qui apparaissent dans la liste des noms d'utilisateur et mots de passe stockés. Redémarrer le PC.