Adieu NTLMv1 - Partie 2 - Consolidation

项目
08/24/2016

Vous venez d'activer l'audit comme indiqué dans la partie : Adieu NTLMv1 - Partie 1 - Détection. On est maintenant capable de détecter que NTLMv1 est utilisé sur vos serveurs ainsi que sur vos contrôleurs de domaine. Par contre, à moins que vous ayez un SIEM sur tous vos serveurs, consolider l'information afin de déterminer facilement où est utilisé NTLMv1 ne paraît pas une simple affaire... Ce billet vous indique comment collecter l'information de façon centralisée sans déployer aucun agent, sans même utiliser un SIEM, juste en utilisant les fonctionnalités par défaut de Windows: Event Forwarding (transfert d'évènements).

Le transfert d'évènements, c'est quoi ?

Depuis Windows Server 2003 R2, Windows dispose d'une fonctionnalité qui permet d'envoyer des évènements correspondant à un filtre que vous aurez prédéfini vers un serveur qui les collecte. Ceci utilise en fait deux composants de Windows, l'Event Forwarding Plug-in (qui écoute les journaux et compare ce qui est généré avec le filtre défini) et un service Windows : Event Collection Service (Service de collecte d'événements). Notez que le transfert d'évènements en Windows Server 2003 fonctionne un tout petit peu différemment, mais bon, 2003 c'est de l'histoire ancienne :) Voilà à quoi cela va ressembler au final :

Les serveurs à gauche sont tous les serveurs hébergeant des ressources pour lesquelles des utilisateurs et des systèmes peuvent utiliser NTLM afin de s'authentifier, donc encore une fois tous vos contrôleurs de domaine et tous vos serveurs membres. En gros, les serveurs sur lesquels les évènements 4624 vont être générés. À droite, juste un serveur membre qui va recevoir une copie des évènements 4624 correspondant à une authentification ayant utilisé NTLMv1 sur les serveurs de gauche.

Magie ?

Comment les serveurs de gauche savent-ils ce qu'il faut transférer, à quelle fréquence, et comment savent-ils que le tout doit aller vers le serveur de droite? Cela se gère grâce à des abonnements. Les abonnements sont des configurations qui sont stockées sur le serveur de droite. Les serveurs de gauche doivent être configurés pour retirer la liste d'abonnements disponibles, les analyser afin de déterminer s'ils doivent s'y abonner et commencer le travail de surveillance et de transfert le cas échéant. Comment dire aux serveurs de gauche d'aller retirer les abonnements du serveur de droite ? Tout simplement par stratégie de groupe. On crée une GPO qui dicte aux serveurs de gauche d'aller vérifier s'ils ont des abonnements avec l'intervalle que l'on choisit.

Préparer le serveur qui va recevoir les évènements

Ce serveur peut être un Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 ou Windows Server 2012 R2 (ou leurs équivalents clients, oui le transfert et la collecte d'évènements fonctionnent aussi sur les OS clients). Les manipulations nécessitent d'être membre du groupe des administrateurs locaux du serveur.

S'il n'est pas déjà configuré pour écouter sur le réseau, configurer le service WinRM (Windows Remote Management). Il est déjà activé et configuré pour écouter par défaut avec Windows Server 2012 et Windows Server 2012 R2. Si ce n'est pas le cas, ou si vous souhaitez vérifier, vous pouvez exécuter les commandes suivantes (notez que si c'est déjà configuré sur votre système et que vous re-exécutez les commandes, cela ne cassera rien et vous dira juste que c'est en fait déjà configuré). Pour configurer le service, ouvrez une console en mode administrateur et tapez :
```
 winrm qc
```
Le message suivant va s'afficher :

Tapez Y puis [Enter]. Le message suivant va s'afficher :

Cela va automatiquement activer les règles de pare feux pour autoriser les connections entrantes pour WinRM.
Activez le service de transfert et de collection des évènements. Ouvrez l'observateur d'évènements et cliquez sur la section Abonnements (Subscriptions).

Cliquez sur Oui (Yes). Cela va activer le service Windows Event Collector. Notez que dorénavant, lorsque vous allez dans la partie Abonnements, on ne vous demandera plus d'activer le service. Notez aussi que le service est configuré en Delayed Start. Donc si la machine vient juste de démarrer et que vous accédez à la partie Abonnements de l'Observateur d'évènements tout de suite, il se peut que le service ne soit pas encore démarré et dans ce cas vous verrez de nouveau le pop-up (cela n'efface rien des éventuelles configurations que vous auriez pu faire auparavant).

C'est tout pour la partie infrastructure. Notez que nous allons utiliser HTTP pour le transport et non HTTPS. Si vous souhaitez utiliser HTTPS, n'hésitez pas à poster un commentaire (en gros cela utilise un autre port et nécessite d'importer et de spécifier un certificat en ligne de commande). Bien que nous utilisions HTTP, le contenu des évènements ne transite pas en clair sur le réseau et les clients vont utiliser Kerberos pour l'authentification. Qui dit Kerberos dit SPN (servicePrincipalName). Assurez-vous que le compte machine de notre serveur de collection a le SPN suivant: WSMAN\hostname et WSMAN\FQDN (exemples : WSMAN\serveur1 et WSMAN\serveur1.contoso.com).

Préparer l'abonnement

On peut maintenant créer un nouvel abonnement. Clic droit Créer un abonnement.

On l'appelle Transférer les authentifications NTLMv1 :

On laisse la destination Forwarded Events. Cela signifie que les évènements arrivant des autres serveurs seront stockés localement dans le journal des évènements transférés.
On choisit Source computer initiated (la deuxième option, dans notre cas, les serveurs vont devoir s'abonner). Cliquez sur Select Computer Groups. On va y ajouter Ordinateurs du domaine (Domain Computers) et Contrôleurs de domaine (Domain Controllers). Ce sont des groupes par défaut donc on cible tous les serveurs et tous les contrôleurs de domaine. Cela ne veut pas dire que par magie tous les ordinateurs et contrôleurs de domaine vont s'abonner. Encore faut-il sur ces serveurs et contrôleurs de domaine, les configurer pour aller vérifier leurs abonnements.

Cliquez ensuite sur Select events et cliquez sur l'onglet XML puis Edit query manually. On va y saisir le filtre vu dans le billet précédent :

 <QueryList>
 <Query Id="0" Path="Security">
  <Select Path="Security">
  Event[
   System[
    EventID=4624
   ] and EventData[
      Data[@Name="LmPackageName"]="NTLM V1" and Data[@Name="TargetUserSid"]!="S-1-5-7"
   ]
  ]
  </Select>
 </Query>
</QueryList>

Voici le résultat dans la fenêtre :

On ne change rien dans la partie Advanced. Ceci doit ressembler à :

On doit voir l'abonnement crée avec le nombre d'abonné égal à 0.

On a un serveur prêt à recevoir les évènements, on a un abonnement qui décrit quels évènements transférer et où les stocker. Maintenant, il faut que les serveurs et les contrôleurs de domaine s'y abonnent.

Préparer et abonner les serveurs

Afin de s'assurer que tous les serveurs et contrôleurs de domaine vont aller chercher leurs abonnements, on va créer une stratégie de groupe. Cela dit, rien ne vous empêche de créer plusieurs stratégies de groupe liées à différentes unités d'organisation. Bref, dans notre exemple, notre GPO on va faire 2 choses :

Configurer l'adresse à laquelle le serveur va aller vérifier s'il a des abonnements.
S'assurer que le plug-in responsable de scruter les évènements 4624 a bien la permission de lire le journal de sécurité.

Pour le premier, on va créer une GPO (encore une fois, libre à vous de créer plusieurs GPO et d'y appliquer des filtres WMI différents ou d'y ajouter du filtrage d'application par groupe de sécurité). On prend ici l'exemple d'une GPO qui s'applique au niveau du domaine, qui s'applique à Authenticated Users (donc potentiellement tous les machines) mais avec un filtre WMI pour que cela ne s'applique en fait qu'aux serveurs membres et contrôleurs de domaine (et non aux stations de travail). Voici le filtre WMI utilise pour l'exemple :

Et voici, on configure dans la GPO sur quel serveur (à quelle adresse) les machines appliquant la GPO vont aller chercher leurs abonnements :

Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager. Activez le paramètre et entrez l'URL suivante : Server=https://<serveur configure pour la collection>:5985/wsman/SubscriptionManager/WEC (le port sera ouvert et vous avez exécuté WimRM qc sur la machine de destination et cela a aussi activé la règle de pare feu). N'oubliez pas le début Server= . Cela fait bien partie du paramètre comme vous pouvez le voir dans la capture suivante :

Pour le second point (les permissions du plug-in du transfert d'évènements) il va falloir modifier la sécurité du système. Le plug-in scrutant les évènements le fait avec le contexte de sécurité NETWORK SERVICE. Et NETWORK SERVICE n'a pas le droit de lire le journal de sécurité où les évènements 4624 vont arriver. Du coup, il va falloir donner la permission à NETWORK SERVICE de lire le journal de sécurité. On peut le faire en ajouter le compte dans le groupe Eventlog Readers ou bien en modifiant le DACL du journal de sécurité. Dans notre exemple, on va le faire en modifiant la sécurité du journal de sécurité. Cela peut aussi se faire par stratégie de groupe dans la section suivante :

Computer Configuration > Policies > Administrative Templates > Windows Components > Event Log Service > Security. Dans la partie Log Access, entrez la valeur suivante: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) La partie (A;;0x1;;;S-1-5-20) est celle qui ajoute NETWORK SERVICE la permission de lire le journal (si cette notation vous parait mystérieuse, je vous invite à vous documenter sur le format SDDL (en anglais). Voici à quoi cela ressemble dans la stratégie de groupe :

Notez que cela ne s'applique pas tout de suite... Il va falloir que la machine redémarre. Mais bon, on utilise NTLMv1 depuis des années, on n'est pas à un cycle de patch management près. Donc soyons patients, petit à petit les machines vont redémarrer (j'espère que vos patchs, au moins une fois par mois) les serveurs vont être configurés correctement. Lorsque la machine applique la stratégie de groupe, on va voir l'évènement suivant dans le journal Eventlog-ForwardingPlugin (notez que si vous optez pour ajouter NETWORK SERVICE dans le groupe Eventlog Readers, il faut également attendre que le serveur redémarre pour que cela prenne effet) :

Et sur le serveur qui reçoit les évènements, vous devez voir le nombre d'abonnés s'incrémenter. Si vous cliquez droit sur l'abonnement et sélectionnez Runtime Status, vous pouvez voir la liste d'abonnés :

Voilà !

Lentement, au fur et à mesure que les serveurs appliquent la stratégie de groupe (et ont redémarré au moins une fois) on va voir les évènements 4624 arriver dans notre journal Forwarded Events :

On peut voir que la colonne Computer nous dit d'où l'événement provient.

Maintenant qu'on a la liste, consultez le prochain billet pour savoir quoi en faire ! (en cours d'écriture, soyez patients)

通过