ID d'événement 4625 sans IP source

10

Nous utilisons un total de 7 éditions standard de Windows Server (2008/2012) R2 pour les environnements de développement et de production. Le mois dernier, nos serveurs ont été compromis et nous avons trouvé de nombreux journaux de tentatives ayant échoué dans l'Observateur d'événements Windows. Nous avons essayé les cyber-armes IDDS mais cela ne s'est pas avéré bon plus tôt.

Maintenant, nous avons réimagé tous nos serveurs et renommé les comptes Administrateur / Invité. Et après avoir à nouveau configuré les serveurs, nous utilisons ces identifiants pour détecter et bloquer les adresses IP indésirables.

L'IDDS fonctionne bien mais nous obtenons toujours 4625 événements dans l'Observateur d'événements sans aucune adresse IP source. Comment puis-je bloquer ces demandes à partir d'adresses IP anonymes?

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

MISE À JOUR: Après avoir vérifié mes journaux de pare-feu, je pense que ces événements 4625 ne sont pas liés à Rdp de toute façon, mais peuvent être SSH ou toute autre tentative que je ne connais pas

windows-server-2008-r2 windows-server-2012-r2 Alan
la source
Pourquoi avez-vous besoin de l'adresse IP si vous avez le nom du poste de travail?
Greg Askew
Ce nom de poste de travail n'est attribué à aucun de nos serveurs / ordinateurs. Je ne pense pas que quelqu'un puisse obtenir l'adresse IP de WorkstationName?
Alan
Apparemment, il existe / était un poste de travail portant ce nom - sauf si le serveur est connecté à Internet. Voir cette réponse: serverfault.com/a/403638/20701
Greg Askew
Tous mes serveurs sont accessibles sur Internet, donc comme mentionné ci-dessus, rdp est sécurisé avec NTLMv2. Nous voyons également des adresses IP bloquées après l'échec des attaques rdp, mais quelques journaux dans eventveiwer ne possèdent pas d'adresse IP associée. Les identifiants que nous utilisons montrent les attaques Rdp ayant échoué séparément des autres attaques 4625
Alan
la réponse est ici: serverfault.com/a/403638/242249
Spongman

Réponses:

8

L'adresse IP pour les tentatives RDP ayant échoué est enregistrée ici même avec NLA activé (aucun ajustement requis) (testé sur Server 2012 R2, je ne suis pas sûr des autres versions)

Journaux des applications et des services> Microsoft-Windows-RemoteDesktopServices-RdpCoreTS / Operational (ID d'événement 140)

Exemple de texte enregistré:

Une connexion à partir de l'ordinateur client avec une adresse IP de 108.166.xxx.xxx a échoué car le nom d'utilisateur ou le mot de passe n'est pas correct.

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>
shérif6241
la source
Merci, et je peux confirmer que le même journal capture également les adresses IP des événements de connexion réussis via RDP en utilisant NLA - ID d'événement 131.
Trix
Argh, pas de nom d'utilisateur ???
jjxtra
3

Il s'agit d'une limitation connue avec l'événement 4625 et les connexions RDP utilisant TLS / SSL. Vous devrez utiliser le cryptage RDP pour les paramètres du serveur de bureau à distance, ou obtenir un meilleur produit IDS.

Greg Askew
la source
Nous utilisons déjà Rdp avec cryptage, nous avons déjà essayé les cyberarmes et syspeace, quoi d'autre?
Alan
2

Vous devez utiliser le pare-feu Windows intégré et ses paramètres de journalisation. Les journaux vous indiqueront les adresses IP de toutes les tentatives de connexion entrantes. Puisque vous avez mentionné que tous vos serveurs sont accessibles sur Internet, il n'y a vraiment aucune excuse pour ne pas utiliser le pare-feu Windows dans le cadre de votre stratégie de défense en profondeur. Je recommanderais spécifiquement ne pas désactiver NLA (authentification au niveau du réseau), car de nombreuses attaques sur RDP dans le passé ont été historiquement atténuées par l'utilisation de NLA et ne concernaient que les hôtes de session RDP exécutant uniquement le cryptage RDP classique.

Journalisation du pare-feu Windows

Ryan Ries
la source
Le pare-feu Windows est activé avec la journalisation, le RDP n'est autorisé que sur l'authentification au niveau du réseau, donc nous faisons déjà ce que vous avez mentionné ici, ce n'est pas du tout utile
Alan
Les journaux vous indiquent qui se connecte au port 3389 et de quelle adresse IP ils proviennent, 100% du temps. Vous pouvez ensuite ajouter cette adresse IP à une liste noire dans le pare-feu Windows. Que voulez-vous de plus?
Ryan Ries
Jetez également un œil à ts_block de @EvanAnderson: github.com/EvanAnderson/ts_block
Ryan Ries
Après avoir vérifié les journaux, je n'ai trouvé aucune adresse IP sur le port que je puisse bloquer, mais nous avons des adresses IP qui tentent d'accéder à nos serveurs sur d'autres ports TCP, comme cette IP: fe80 :: 586d: 5f1f: 165: ac2d que j'ai trouvée avec le port n ° 5355. Je ne pense pas que ces événements 4625 sont générés à partir d'une demande Rdp, peuvent être SSH ou d'autres tentatives.
Alan
Nous avons maintenant changé les ports par défaut et bloqué les ports inutiles
Alan
1

Cet événement est généralement causé 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.

zea62
la source