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 cyberarms 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 this idds 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 4625 événements ne sont pas liés à Rdp de toute façon, mais peuvent être SSH ou toute autre tentative que je suis pas familier avec
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>
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.
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 y a vraiment non 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 pas de 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 RDP classique chiffrement uniquement.
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:
À partir d'une invite de commandes, 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.