Maîtriser le protocole SMB pour optimiser le partage de fichiers et la sécurité réseau

Le protocole SMB, pour Server Message Block, constitue l’un des piliers fondamentaux de la communication réseau dans les environnements informatiques modernes, en particulier au sein des infrastructures Windows. Depuis son origine en 1985, créé par IBM, ce protocole client-serveur s’est imposé comme le standard incontournable pour le partage de fichiers, de dossiers et de ressources réseau telles que les imprimantes ou les interfaces partagées. Aujourd’hui, avec des implémentations qui s’étendent au-delà de Windows vers Linux via Samba et l’ensemble des solutions de stockage réseau (NAS), SMB demeure un élément technique qu’il est essentiel de maîtriser pour toute personne travaillant dans le domaine informatique.

🔌 Qu’est-ce que le protocole SMB et comment fonctionne-t-il ?

Le protocole SMB établit une communication de type client-serveur permettant d’accéder à des ressources partagées sur un réseau local. Cette architecture fonctionne selon un modèle simple : un ordinateur (le client) demande l’accès à des fichiers ou des dossiers stockés sur un autre ordinateur (le serveur), et ce dernier répond en accordant ou refusant l’accès selon les permissions configurées. Lorsqu’un utilisateur sous Windows accède à un partage de fichiers depuis une autre machine, ou lorsqu’il monte un lecteur réseau, l’intégralité de la communication s’effectue par le biais de SMB.

Cette utilisation est particulièrement pertinente dans les environnements d’entreprise où plusieurs postes de travail doivent accéder à des données centralisées. Le protocole a été conçu initialement pour les réseaux locaux (LAN), d’où son optimisation pour une latence minimale et une bande passante efficace. Contrairement à certains protocoles universels, SMB s’appuie sur une architecture propre à Windows, bien que son adoption sur d’autres systèmes d’exploitation ait progressivement élargi son champ d’application.

Les couches techniques du protocole SMB

Sur le plan technique, SMB fonctionne en s’appuyant sur une pile de protocoles bien définie. Historiquement, le protocole utilisait NetBIOS (Network Basic Input/Output System) comme mécanisme de résolution de noms et de transport. Cette implémentation, dépendante du port 139, permettait aux machines de se découvrir mutuellement et d’établir des connexions basées sur des noms plutôt que sur des adresses IP. Cependant, cette approche s’est révélée limitée à mesure que les réseaux évoluaient.

La transition majeure s’est opérée avec SMB2, qui a introduit un fonctionnement nativement sur TCP/IP, utilisant le port 445 et s’appuyant sur le DNS pour la résolution de noms. Cette évolution a marqué un tournant décisif, libérant le protocole des contraintes de NetBIOS et lui permettant une meilleure intégration dans les architectures réseau contemporaines. Depuis Windows 2000, SMB s’appuie quasi exclusivement sur cette seconde approche, offrant une plus grande flexibilité et une compatibilité supérieure avec les infrastructures modernes.

Implémentations multi-plateformes du protocole SMB

Si SMB est nativement intégré à Windows, son importance s’étend bien au-delà de cet écosystème. Sur les systèmes Unix et Linux, l’implémentation du protocole SMB s’effectue via Samba, un projet open-source qui reproduit fidèlement les fonctionnalités de SMB. Cette portabilité a permis aux administrateurs de créer des serveurs de fichiers Linux capables de dialoguer de manière transparente avec les clients Windows.

Les solutions de stockage réseau (NAS) constituent un autre domaine où SMB s’est imposé comme standard de facto. Les constructeurs de renom—Synology, QNAP, ASUSTOR, TerraMaster—intègrent tous le protocole SMB dans leurs appliances. Des solutions open-source comme FreeNAS, TrueNAS et OpenMediaVault, reposant sur des bases Linux, supportent également SMB de manière native. Cette universalité explique pourquoi SMB demeure incontournable dans tout environnement où plusieurs systèmes d’exploitation coexistent.

📊 L’évolution technique du protocole SMB : des versions et leurs caractéristiques

Comprendre les différentes versions de SMB est crucial pour anticiper les problèmes de compatibilité et optimiser la sécurité d’une infrastructure réseau. Microsoft a régulièrement amélioré le protocole au fil des générations de Windows, chaque itération apportant des correctifs, des améliorations de performance et des renforts de sécurité. Cette évolution chronologique reflète les défis techniques et sécuritaires rencontrés au cours des quatre décennies d’existence du protocole.

La première version officielle nommée SMB a vu le jour avec Windows 2000, bien qu’elle soit restée relativement proche de son prédécesseur CIFS. SMB v2, arrivée avec Windows Vista en 2006, a marqué un tournant en introduisant des mécanismes de sécurité plus robustes et une réduction significative du nombre de paquets réseau nécessaires pour les opérations courantes. Cette optimisation a rendu SMB v2 particulièrement attractif pour les environnements hautement chargés.

Les sauts technologiques majeurs : SMB v3 et ses innovations

L’introduction de SMB v3 en 2012 a révolutionné le protocole en l’adaptant aux besoins des infrastructures cloud et des stockages haute performance. Deux innovations majeures ont marqué cette évolution : SMB Multichannel permet aux clients d’établir plusieurs connexions simultanées vers un serveur, augmentant considérablement le débit, tandis que SMB Direct s’appuie sur des technologies comme RDMA (Remote Direct Memory Access) pour contourner les limitations traditionnelles du TCP/IP.

Parallèlement, Microsoft a renforcé le chiffrement en implémentant des algorithmes cryptographiques de classe militaire. La version 3.1.1, disponible depuis Windows Server 2016 et Windows 10 version 1607, représente le sommet actuel avec le support du chiffrement AES-128-GCM, offrant une protection quasi inviolable contre les interceptions. Cette version demeure le standard sur Windows 11 (version 25H2) et Windows Server 2025.

⚠️ Le protocole SMB v1 : pourquoi cette version doit absolument être abandonnée

Le SMB v1 représente un cas d’école en matière de dépréciação technologique et de risque sécuritaire. Bien que techniquement opérationnel, cette version date de 1996 et n’a plus été maintenue officiellement par Microsoft depuis 2014. La décision de désactiver par défaut SMB v1 à partir de Windows 10 version 1709 et Windows Server 1709 n’est pas anodine : elle répond à une menace concrète et persistante.

L’événement qui a déclenché cette prise de conscience massive s’est produit en 2017 avec la découverte de la vulnérabilité critique EternalBlue (CVE-2017-0144). Cette faille, exploitée massivement par les ransomwares WannaCry et Petya, a permis une propagation extrêmement rapide à travers les réseaux d’entreprise. Des millions de machines ont été compromises, causant des dégâts économiques estimés à plusieurs milliards de dollars. Bien que Microsoft ait publié des correctifs, le problème fondamental persiste : SMB v1 ne peut pas être sécurisé de manière durable.

Vulnérabilités structurelles et scénarios de compromission

SMB v1 souffre de failles architecturales qui vont bien au-delà d’EternalBlue. Le protocole manque de mécanismes modernes de signature de paquets, rendant possible la manipulation des données en transit. L’absence de chiffrement natif signifie que les identifiants de session peuvent être capturés et réutilisés. Ces défauts structurels font de SMB v1 une porte d’entrée idéale pour les attaquants cherchant à établir un accès initial ou à effectuer des mouvements latéraux au sein d’un réseau.

Certains environnements maintiennent regrettablement SMB v1 actif pour supporter des équipements hérités : anciennes machines sous Windows XP, photocopieurs multifonctions datant de plusieurs années, ou systèmes de gestion de parc informatique obsolètes. Cette situation, bien que compréhensible pour des raisons de compatibilité, crée une vulnérabilité permanente. Les administrateurs qui réactivent SMB v1 pour ces cas spécifiques doivent mettre en place des compensations sécuritaires drastiques : isolation réseau stricte, contrôle d’accès granulaire, et surveillance intense du trafic.

Stratégies de migration pour éliminer SMB v1

L’abandon de SMB v1 doit s’inscrire dans une stratégie de remplacement progressive. Pour les photocopieurs et systèmes multifonctions, de nombreux constructeurs ont publié des mises à jour firmware compatible SMB v2/v3. Pour les machines Windows XP, l’unique solution consiste à effectuer une migration vers des systèmes d’exploitation actuels ou à isoler complètement ces machines en réseau. Microsoft fournit des outils PowerShell et des guides détaillés pour désactiver SMB v1 de manière structurée en environnement de production.

• 🚫 Désactiver SMB v1 à l’installation de Windows Server via les rôles et fonctionnalités
• 📋 Dresser un inventaire complet des clients SMB v1 encore actifs dans l’infrastructure
• 🔄 Planifier des migrations de systèmes hérités sur une période définie (12-18 mois)
• 📡 Mettre à jour les firmware des périphériques réseau (imprimantes, scanners)
• 🛡️ Implémenter une segmentation réseau pour isoler les machines legacy en cas de nécessité temporaire
• 🔍 Effectuer un contrôle régulier pour détecter toute réactivation non autorisée de SMB v1

🌐 Les ports réseau utilisés par SMB : port 139 et port 445

La question des ports utilisés par SMB revêt une importance capitale pour les administrateurs réseau qui doivent configurer les pare-feu, mettre en place des listes de contrôle d’accès, et diagnostiquer les problèmes de connectivité. SMB n’utilise pas un seul port : l’histoire du protocole explique cette dualité et ses implications pratiques pour les infrastructures modernes.

Port 139 : l’approche historique via NetBIOS

Le port TCP 139 représente le fonctionnement original de SMB tel qu’implémenté à l’époque de Windows NT 4.0 (1996). Dans ce modèle, SMB s’appuyait fortement sur NetBIOS (Network Basic Input/Output System), un protocole de couche session qui gérait la résolution de noms et l’établissement de sessions entre machines. L’utilisation du port 139 était donc inévitable : NetBIOS avait besoin d’un port spécifique pour établir ses connexions.

Cependant, cette architecture présentait des limitations significatives. NetBIOS était conçu pour les réseaux locaux fermés et ne s’adaptait pas bien au routage Internet. La résolution de noms s’effectuait via des broadcasts ou des serveurs WINS (Windows Internet Naming Service), mécanismes fastidieux à maintenir dans de grandes infrastructures. De plus, NetBIOS exposait des fonctionnalités supplémentaires (comme la résolution d’adresses) qui n’apportaient aucun bénéfice en environnement moderne et constituaient plutôt des vecteurs d’attaque.

Port 445 : la standardisation sur TCP/IP natif

À partir de Windows 2000, Microsoft a effectué une transition majeure : SMB fonctionne désormais nativement sur TCP/IP via le port 445, sans dépendre de NetBIOS. Cette évolution, bien que transparente pour les utilisateurs finaux, a transformé l’architecture fondamentale du protocole. La résolution de noms s’appuie maintenant sur le DNS, infrastructure bien établie et facilement scalable. Le port 445 est devenu le standard incontournable pour toutes les versions modernes de SMB.

Depuis Windows 2000 jusqu’aux versions actuelles (Windows 11, Windows Server 2025), la communication SMB s’effectue exclusivement via le port 445. Bien que certains textes techniques mentionnent toujours le port 139, son utilisation ne survient que si NetBIOS est explicitement activé—ce qui n’est pratiquement jamais le cas dans les infrastructures contemporaines. Pour les administrateurs configurant des pare-feu, cela signifie que seul le port 445 mérite attention dans les configurations de réseau modernes.

Une distinction importante : si une machine doit communiquer en SMB via le port 139, cela indique généralement une architecture rétrocompatible spécifiquement configurée ou une problématique de compatibilité avec des équipements très anciens. L’analyse du trafic réseau révèle rapidement quel port est utilisé : les connexions légitimes en environnement moderne transitent presque exclusivement par le port 445.

🛠️ Créer et accéder à un partage SMB : guide pratique d’implémentation

La théorie doit inévitablement céder la place à la pratique. Créer un partage SMB et y accéder depuis un autre ordinateur illustre concrètement le fonctionnement du protocole. Cet exercice demeure l’une des opérations les plus courantes en administration réseau Windows, et sa maîtrise conditionne la gestion efficace d’une infrastructure.

Configuration du serveur : création d’un partage SMB

La première étape consiste à créer un dossier destiné au partage. Supposons qu’il s’agisse de C:Partage sur une machine Windows Server 2025. Après avoir créé ce répertoire physiquement, l’administrateur doit accéder à ses propriétés en effectuant un clic droit, puis en sélectionnant « Propriétés ». Le processus de création du partage lui-même s’effectue via l’onglet « Partage ».

La méthode la plus efficace consiste à utiliser « Partage avancé », qui offre un contrôle granulaire sur les permissions de partage. Après avoir coché « Partager ce dossier », un nom doit être attribué (par exemple, « Partage »). À ce stade, un détail important : si le nom du partage se termine par un dollar ($), par exemple « Partage$ », le partage ne s’affichera pas dans les énumérations réseau standard, restant invisible mais toujours accessible via le chemin UNC explicite.

Gestion des permissions : deux niveaux d’autorisation

Windows gère deux niveaux distincts de permissions pour les partages SMB : les permissions de partage et les permissions du système de fichiers (NTFS). Cette dichotomie crée souvent une confusion chez les administrateurs novices. Les permissions de partage contrôlent qui peut accéder à la ressource réseau, tandis que les permissions NTFS gouvernent ce que chaque utilisateur peut faire une fois l’accès obtenu.

Supposons que les permissions de partage accordent l’accès en lecture-écriture à tout le monde : cela ne signifie pas que tous les utilisateurs peuvent réellement modifier les fichiers. Si les permissions NTFS du dossier réservent l’accès en modification à un groupe spécifique, seuls les membres de ce groupe pourront effectivement modifier les fichiers. L’intersection des deux systèmes de permissions détermine les droits réels. Pour éviter les surprises, il est recommandé de configurer des permissions restrictives au niveau du partage (par exemple, « Tout le monde » en lecture seule) et de gérer les droits d’accès précis au niveau NTFS.

Le chemin UNC qui en résulte suit la convention NomServeurNomPartage (par exemple, SRV-ADDS-01Partage). Pour une meilleure portabilité et robustesse, préférer le format FQDN : SRV-ADDS-01.domaine.localPartage. Ce format s’appuie sur la résolution DNS au lieu de la résolution NetBIOS, offrant une fiabilité supérieure dans les réseaux étendus.

Connexion client : accéder au partage

Depuis un ordinateur client (Windows 10, Windows 11 ou toute autre machine SMB-compatible), l’accès au partage s’effectue de plusieurs manières. La méthode la plus directe consiste à ouvrir l’Explorateur de fichiers et à saisir le chemin UNC dans la barre d’adresse. Après validation, l’ordinateur établit une connexion SMB avec le serveur, demande une authentification (sauf s’il utilise des identifiants de session présents), et affiche le contenu du partage.

Une seconde approche, plus scriptable et adaptée aux environnements automatisés, passe par PowerShell. La cmdlet Get-ChildItem permet d’énumérer le contenu d’un partage SMB distant :

Get-ChildItem "SRV-ADDS-01.domaine.localPartage"

Cette commande établit une connexion SMB de manière implicite, récupère la liste des fichiers, puis ferme la session. Pour les administrateurs souhaitant conserver une session ouverte pour plusieurs opérations consécutives, les cmdlets New-SmbMapping et Remove-SmbMapping offrent un contrôle explicite des sessions SMB.

Diagnostic et vérification de la version SMB utilisée

Une question récurrente chez les administrateurs : « Quelle version de SMB est actuellement négociée pour cette connexion ? » La réponse s’obtient facilement via PowerShell avec la cmdlet Get-SmbConnection. Après avoir accédé au partage, l’exécution de cette commande affiche toutes les connexions SMB actives, incluant le dialecte (version) utilisé pour chacune.

Par exemple, une session utilisant SMB v3.1.1 affichera « 3.1.1 » dans la colonne « Dialect ». Si la version affichée est antérieure à v2, cela indique une problématique de configuration ou de compatibilité nécessitant une investigation immédiate. Pour vérifier la version SMB supportée localement par une machine (sans dépendre d’une connexion réseau), il est possible d’interroger le partage administratif local C$ :

dir localhostc$

Relancer Get-SmbConnection révèle la version SMB de la machine locale elle-même.

Capture et analyse du trafic SMB

Pour les administrateurs souhaitant observer le protocole SMB en action au niveau du réseau, la capture de paquets offre une visibilité techniquement directe. Windows intègre Packet Monitor (pktmon), outil permettant de capturer et d’analyser le trafic réseau sans installer d’outils tiers comme Wireshark. La procédure est simple : définir des filtres sur les ports SMB (445 et optionnellement 139), lancer la capture, générer du trafic via une connexion SMB, puis observer les paquets affichés.

La commande pktmon filter add -p 445 ajoute un filtre, tandis que pktmon start –etw -m real-time lance la capture en temps réel. Lors de l’accès à un partage SMB, les paquets affichés montreront explicitement le port 445, confirmant que le protocole moderne est en usage. Cette analyse constitue un outil pédagogique excellent pour comprendre visuellement comment SMB fonctionne sur le fil réseau.

L’importance de ces diagnostics ne doit pas être sous-estimée : ils constituent la fondation sur laquelle reposent les dépannages avancés et la validation des configurations en environnement de production. Un administrateur qui maîtrise ces outils dispose d’une capacité de résolution de problèmes considérablement supérieure.

Le protocole SMB, des ses origines en 1985 jusqu’à ses implementations les plus contemporaines, demeure une composante critique de toute infrastructure Windows et des systèmes d’exploitation modernes. Sa compréhension approfondie—des versions disponibles aux ports réseau, des vulnérabilités historiques aux techniques d’implémentation pratique—constitue un savoir incontournable pour les administrateurs systèmes, les techniciens réseau et les architectes IT. Maîtriser SMB signifie non seulement comprendre comment les données circulent en réseau, mais aussi identifier et corriger les failles sécuritaires, optimiser les performances d’infrastructure, et anticiper les incompatibilités entre systèmes hétérogènes.