Preuves de dependance SMBv1 : tentatives et dialectes

Les preuves de dépendance à SMBv1 doivent relier une tentative observée d'un client à un serveur, à un processus métier et à un responsable. Une ancienne désignation du système d'exploitation dans Active Directory peut aider à prioriser l'investigation, mais elle ne permet pas d'établir quel dialecte SMB un appareil utilise aujourd'hui. Avant de supprimer SMBv1, constituez un dossier qui distingue la configuration, les tentatives d'utilisation, les connexions établies et les lacunes d'observation.

Ce guide décrit une démarche de vérification et de remédiation pour les environnements AD. Les commandes ci-dessous sont des exemples documentés qu'un administrateur Windows autorisé peut exécuter sur les systèmes concernés ; elles n'ont pas été exécutées sur un domaine réel pour cet article. Aucun exemple de sortie n'est présenté comme un résultat mesuré.

Que sont les preuves de dépendance à SMBv1 ?

Une dépendance est une affirmation opérationnelle : un processus métier identifié a encore besoin de SMBv1 pour aboutir. Cette affirmation exige des éléments plus solides qu'un attribut d'annuaire, un composant installé sur disque ou le constat qu'un appareil est ancien. Traitez chacun de ces éléments comme une donnée d'investigation et consignez l'observation qui confirmerait ou affaiblirait l'affirmation.

La revue doit répondre à trois questions. Quels serveur et client sont concernés ? Quelle opération doit réussir ? Quelles preuves relient l'observation du protocole à cette opération ? Si le responsable ne peut pas y répondre, la dépendance reste non vérifiée. Cela ne signifie pas que la suppression est sans risque ; cela signifie que la décision exige un pilote au périmètre défini et une collecte complémentaire.

Utilisez un dossier de preuves avec des entrées distinctes pour la configuration, les tentatives côté serveur, les instantanés côté client et les résultats des processus métier. Les séparer évite une erreur courante : utiliser une connexion moderne capturée sur un poste pour clore un constat concernant un autre appareil, une autre identité ou un traitement nocturne.

Comment articuler les preuves

Partez du processus métier plutôt que d'une bascule à l'échelle de tout le parc. Demandez au responsable du service d'énumérer ses destinations et ses appelants, y compris les tâches périodiques susceptibles de ne pas s'exécuter pendant un test interactif. Consignez les systèmes Windows pouvant fournir un audit serveur ou des observations client, et les appareils nécessitant une autre méthode de collecte. Un équipement qui ne peut pas exécuter les commandes proposées reste dans la population non résolue jusqu'à ce que son responsable fournisse des preuves adaptées.

Choisissez une fenêtre de collecte couvrant le cycle opérationnel pertinent. Un test quotidien au premier plan ne sollicite pas un export mensuel. Aucune durée universelle n'est prescrite ici : le responsable doit justifier la fenêtre à partir du calendrier réel et des opérations inhabituelles ou de reprise qui comptent. Consignez les heures de début et de fin, les processus exclus, les hôtes manquants et les interruptions de collecte.

Pour chaque observation, conservez l'hôte source et le contexte avant de conclure. Un horodatage seul ne suffit pas si les enregistrements serveur et client ne peuvent pas être rattachés à la même destination et à la même opération. Si ce lien ne peut pas être établi, marquez la corrélation comme non résolue au lieu de considérer la proximité temporelle comme une preuve.

Détection : vérifier la configuration, les tentatives et les connexions

Étape 1 : inspecter le composant Windows et le paramètre serveur

Microsoft documente ces contrôles dans son guide de gestion des protocoles SMB. Utilisez les commandes adaptées au système Windows examiné et conservez leurs sorties comme des éléments de preuve distincts. Exécutez les commandes de fonctionnalité optionnelle dans une session PowerShell élevée, comme l'exige le guide Learn.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Get-SmbServerConfiguration | Select EnableSMB1Protocol

La première indique l'état de la fonctionnalité optionnelle ; la seconde indique le paramètre du serveur SMB. Consignez l'état retourné et le rôle de l'hôte inspecté. Un paramètre serveur ne décrit pas toutes les connexions sortantes de cet hôte, et l'état d'une fonctionnalité n'établit pas si une opération métier l'a utilisée. Si une commande est indisponible ou échoue sur la cible, conservez l'échec et choisissez une méthode d'inspection applicable avant de déclarer l'hôte couvert.

N'utilisez pas une valeur par défaut historique pour combler une observation manquante. Le dossier de décision doit contenir le résultat réel du système inspecté, l'heure de collecte et le nom de la personne qui l'a interprété. Conservez les résultats antérieurs au changement pour les comparer après remédiation.

Étape 2 : activer l'audit serveur et conserver Event 3000

Pour le périmètre serveur approuvé, Microsoft documente ce paramètre d'audit :

Set-SmbServerConfiguration -AuditSmb1Access $true

Vérifiez le paramètre :

Get-SmbServerConfiguration | Select AuditSmb1Access

Le même guide Learn identifie l'événement 3000 dans Microsoft-Windows-SMBServer/Audit comme une tentative d'un client de se connecter avec SMBv1 après activation de l'audit. Conservez l'événement avec les preuves de l'état de l'audit. Un Event 3000 ne prouve ni un accès réussi à un partage, ni une exploitation, ni un inventaire complet des dépendances.

Rattachez chaque tentative à un dossier d'investigation. Utilisez les informations client réellement disponibles dans l'événement et l'inventaire associé pour identifier un responsable ; n'inventez pas une identité client lorsque la corrélation manque. Demandez au responsable quelle opération était en cours et obtenez son résultat. Classez le dossier comme une tentative rattachée, une tentative non résolue ou un processus nécessitant davantage d'observations.

Une tentative infructueuse mérite tout de même une explication, mais elle n'établit pas que le processus exige SMBv1 pour réussir. Inversement, un processus qui n'a jamais été exécuté ne peut pas être validé simplement parce que le journal serveur ne contient aucune entrée pertinente.

Étape 3 : capturer les connexions du client actif

Exécutez le contrôle client documenté pendant que l'opération identifiée est active :

Get-SmbConnection

La référence Get-SmbConnection de Microsoft décrit les connexions établies du client vers le serveur et expose le champ Dialect dans ses exemples. Les lignes se distinguent par le partage, la session utilisateur et les identifiants utilisés. Conservez ce contexte au lieu de réduire toutes les lignes à une réponse unique pour la machine.

Joignez l'instantané au dossier du processus métier avec l'heure de collecte et les valeurs réellement retournées. Un dialecte moderne sur une connexion correspondante étaye le chemin observé à cet instant. Il ne valide pas les autres partages, identités, appareils ou exécutions planifiées. Une ligne absente n'est pas un historique de toute l'activité SMBv1 ; une autre méthode d'observation peut être nécessaire pour le chemin non résolu.

Étape 4 : rapprocher les preuves avant de décider

Comparez l'événement, l'instantané client et le résultat du processus métier. S'ils concernent des appelants ou des opérations différents, conservez des dossiers distincts. Si une tentative est visible sur le serveur mais qu'aucune connexion établie correspondante n'est capturée, conservez les deux observations sans fabriquer une réussite ou un dialecte.

Remplacer la dépendance et revalider SMB2/3 (Remediation)

Étape 1 : rendre la décision sur la dépendance vérifiable

Pour chaque processus affecté, consignez s'il sera retiré, mis à niveau ou transféré vers un appareil ou un service de remplacement. Identifiez le responsable, la date d'achèvement prévue, le périmètre pilote approuvé et le plan de reprise. Si la dépendance n'est pas résolue, précisez exactement quelle observation manque et qui l'obtiendra.

Le pilote doit inclure les chemins client et serveur découverts pendant la collecte. Ne fondez pas un changement à l'échelle du parc sur une seule connexion réussie. Incluez les opérations périodiques identifiées lors de la planification ou documentez que leur validation reste en attente.

Étape 2 : appliquer le changement SMBv1 approuvé

Microsoft documente la commande suivante pour désactiver SMBv1 sur le composant serveur :

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Pour la fonctionnalité optionnelle Windows applicable, la commande documentée est :

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Choisissez la méthode adaptée à la cible et au périmètre visé. Ces changements ne sont pas des preuves interchangeables : désactiver le protocole serveur et désactiver une fonctionnalité optionnelle concerne des couches de configuration différentes. Le guide Learn décrit un redémarrage pour le changement de fonctionnalité optionnelle, tandis que Set-SmbServerConfiguration n'exige pas de redémarrage. Planifiez l'impact de tout redémarrage avec le responsable et conservez le résultat retourné au lieu de supposer que le changement est terminé.

Si la compatibilité échoue, revenez au dossier du processus et au remplacement prévu. Une décision de reprise doit identifier le service affecté et son responsable ; elle ne doit pas redéfinir silencieusement la configuration de référence d'hôtes sans rapport.

Étape 3 : répéter les observations sur le périmètre modifié

Répétez les contrôles applicables de fonctionnalité et de serveur, puis exécutez les opérations prévues. Capturez les connexions client pendant ces opérations et conservez la couverture d'audit serveur sur la fenêtre justifiée. Comparez les dossiers avant et après changement avec les mêmes identifiants d'hôte, de partage et de processus.

Ne clôturez un dossier de dépendance que lorsque le responsable peut expliquer ce qui a changé et fournir des preuves que le processus requis fonctionne encore sur le chemin SMB2/3 prévu. Gardez ouverts les cas d'opérations périodiques non testées et d'appareils indisponibles. Un résultat de configuration, un test métier réussi et un instantané de connexion répondent à des questions différentes ; le dossier de clôture exige la combinaison pertinente.

Consignez les tentatives résiduelles après le changement et examinez leurs appelants. Leur présence ne signifie pas automatiquement qu'un processus métier a échoué, et leur absence n'établit pas une couverture complète. Rattachez l'interprétation au périmètre et à la fenêtre d'audit d'origine.

Comment EtcSec détecte ce problème

Dans l'implémentation d'etc-collector examinée, COMPUTER_LEGACY_PROTOCOL est un signal de triage fondé sur l'annuaire. Sa méthode Detect examine les comptes d'ordinateur activés. Elle recherche d'abord cinq motifs OS sans tenir compte de la casse : Windows XP, Windows 2000, Windows NT, Server 2003 et Windows Vista. Une correspondance ajoute l'ordinateur à la liste affectée et passe à l'ordinateur suivant.

Pour les ordinateurs qui ne correspondent pas à cette branche, le détecteur vérifie si SupportedEncryptionTypes est non nul et ne contient aucun des deux bits AES du masque 0x18. La branche OS a priorité : un ordinateur retenu par cette branche ne contribue pas aussi au décompte du motif de chiffrement faible. La méthode retourne un constat agrégé unique, y compris lorsque le nombre d'ordinateurs affectés est nul.

Le fournisseur LDAP lit operatingSystem et msDS-SupportedEncryptionTypes dans le modèle d'ordinateur. Ce sont des attributs d'annuaire, pas des mesures du trafic SMB réel. L'analyseur d'entiers retourne zéro pour une valeur absente et ignore les erreurs de conversion ; son résultat ne conserve donc pas ces cas comme des résultats de collecte distincts. Le détecteur ignore une valeur de chiffrement nulle ; cela n'établit pas l'utilisation de protocoles modernes.

Le contrôle n'observe ni dialecte SMB, ni version NTLM, ni utilisation réelle de DES/RC4, ni Event 3000, ni réussite d'un processus métier. Un ordinateur affecté exige une investigation complémentaire, et un décompte nul ne peut pas clore la revue des dépendances à SMBv1. Utilisez le constat pour prioriser la démarche de collecte de preuves décrite ci-dessus.

Si le motif est l'attribut de chiffrement, suivez le guide du fallback Kerberos RC4 pour distinguer les paramètres d'annuaire des preuves issues des tickets. Si la revue soulève une question de signature, utilisez le guide de signature SMB sur les exigences de signature et l'exposition au relais. Aucune de ces revues ne remplace les preuves de tentatives et de dépendances à SMBv1 recueillies ici.

Dossier de décision et références primaires

Avant de clore la revue, conservez des réponses explicites à ces questions :

1. Quels serveurs et processus ont été audités, et la fenêtre couvrait-elle leurs tâches périodiques ?
2. Quelles tentatives Event 3000 ont été rattachées à un client et à un responsable, et quel résultat a été vérifié pour chaque opération ?
3. Quelle dépendance a été supprimée ou remplacée, et quelles preuves revalident les processus SMB2/3 requis ?

Joignez les résultats de configuration d'origine, la fenêtre d'audit, les événements, les instantanés client, les décisions des responsables et la validation après changement. Si des preuves manquent encore, précisez la lacune et l'action suivante. Il s'agit d'une méthode de revue proposée, pas d'une affirmation qu'un domaine a réussi ces contrôles.

• Microsoft Learn: Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft Learn: Get-SmbConnection