SMB1 vs SMB2/3 : quoi désactiver (et pourquoi cela importe)

Conclusion : quoi désactiver

Désactivez SMB1 partout. Côté serveur et côté client. Puis vérifiez qu’il a vraiment disparu.
Faites-le pour la sécurité, oui — mais aussi pour la fiabilité. Le design bavard de SMB1, sa négociation fragile et l’absence de protections modernes transforment de petits
problèmes réseau en pannes visibles par les utilisateurs.

À faire

• Désactiver SMB1 côté serveur sur les serveurs Windows et sur les appliances Samba.
• Désactiver SMB1 côté client sur les postes/VDI Windows sauf si vous avez une exception documentée et limitée dans le temps.
• Autoriser SMB2 et SMB3 (y compris SMB 3.1.1) et appliquer une sécurité raisonnable : signature où elle est requise, chiffrement seulement quand il se justifie.
• Suivre les derniers bastions SMB1 (scanners, vieilles imprimantes multifonctions, périphériques embarqués) et planifier leur retrait comme tout autre risque.

Une opinion franche de l’exploitation

La seule raison valable de garder SMB1 activé est « nous avons accepté le risque, nous l’avons isolé, nous l’avons consignés et nous avons une date de retrait. »
Tout le reste n’est que de la procrastination avec un câble réseau en plus.

Blague n°1 : SMB1, c’est comme garder une moustiquaire sur un sous-marin parce que votre arrière-grand-oncle aimait « l’air frais ».

Quelques faits et historique importants

Vous n’avez pas besoin de mémoriser l’archéologie des protocoles, mais quelques faits concrets changeront votre façon de dépanner et de vendre le changement en interne.

1. SMB1 précède les modèles de menace modernes. Ses racines remontent aux réseaux IBM PC et aux premières conceptions de Microsoft LAN Manager.
2. SMB2 est arrivé avec Windows Vista/Server 2008. Ce n’était pas une simple mise à jour mineure ; c’était une refonte visant à réduire la verbosité et à améliorer les performances.
3. SMB3 a été lancé avec Windows 8/Server 2012. Il a apporté des fonctionnalités pour les datacenters : chiffrement, multichannel et SMB Direct (RDMA).
4. La propagation de WannaCry a été accélérée par l’exposition SMB1. Cet incident a fait passer « désactiver SMB1 » de bonne pratique à hygiène minimale.
5. SMB 3.1.1 a amélioré la négociation de sécurité. Il a introduit de meilleures protections d’intégrité pré-authentification qui compliquent les attaques de type downgrade/mitm.
6. La signature SMB existait plus tôt mais devient plus pertinente. Elle est souvent exigée pour la sécurité et peut devenir une contrainte de performance sur des CPU modestes.
7. SMB est à état et sensible à la latence. Un peu de RTT passe ; la gigue et la perte de paquets sont ce qui le rend criant.
8. Les « dialectes » SMB se négocient par connexion. Vous pouvez désactiver SMB1 et voir quand même des clients échouer s’ils ne peuvent pas négocier SMB2+.
9. Samba n’est pas « SMB Windows », mais il parle le même langage. Samba peut implémenter les fonctionnalités SMB3 selon la version/options de compilation et le support noyau.

SMB1 vs SMB2 vs SMB3 : ce qui a réellement changé

SMB1 : bavard, fragile et trop confiant

SMB1 est l’ancien monde. Il effectue de nombreuses petites opérations requête/réponse. Cela signifie plus d’allers-retours, donc une amplification de la latence.
Cela signifie aussi plus d’endroits où des middleboxes peuvent interférer et davantage d’opportunités pour des bugs obscurs d’apparaître.

SMB1 manque aussi de défenses modernes. Même en le cantonnant au « réseau interne », vous pariez qu’aucun élément non fiable n’y aura jamais accès.
Vous perdez ce pari dès qu’un portable rapporte un logiciel malveillant sur le VPN, qu’un pare-feu est mal configuré, ou qu’un VLAN plat permet à une station de travail
de tout atteindre.

SMB2 : moins d’allers-retours, meilleures sémantiques

SMB2 a réduit substantiellement l’overhead du protocole. Il a amélioré le batch et le pipelining. Ce n’est pas « agréable » ; c’est la raison pour laquelle SMB2 est beaucoup plus performant
sur des liaisons WAN-ish, des noyaux occupés et des réseaux virtualisés.

Opérationnellement, SMB2+ améliore aussi l’observabilité. Vous pouvez souvent interroger les dialectes négociés, l’état de la signature et les détails de session plus clairement,
ce qui transforme « c’est lent » en quelque chose de mesurable.

SMB3 : sécurité et fonctionnalités datacenter (avec des angles vifs)

SMB3 ajoute des éléments utiles dans les environnements modernes : chiffrement (par partage ou par session), multichannel (plusieurs chemins réseau par session)
et SMB Direct (RDMA) si vous êtes dans l’écosystème Windows/HCI.

Mais les fonctionnalités SMB3 peuvent aussi créer de nouveaux modes de panne :
le multichannel peut révéler du routage asymétrique, de mauvais offloads NIC ou des erreurs de configuration de switch ;
le chiffrement peut devenir un goulot CPU ;
l’exigence de signature peut transformer un NAS ancien en radiateur consommant du CPU tout en servant des fichiers.

La citation essentielle

« idée paraphrasée » — Werner Vogels : on construit la fiabilité en supposant que les choses vont échouer et en concevant pour cela, pas en espérant que le chemin heureux tiendra.

Ce qu’il faut désactiver (et ce qu’il faut garder)

Désactiver le support du protocole SMB1

SMB1 doit être désactivé sur les serveurs et les clients. Point final. Ici, certains diront « mais l’imprimante… ».
D’accord. Mettez l’imprimante sur un VLAN mis en quarantaine, donnez-lui un partage dédié avec des ACL strictes et planifiez son remplacement.
Ne gardez pas SMB1 activé pour toute la flotte à cause d’un périphérique embarqué coincé en 2009.

Garder SMB2 et SMB3, mais être réfléchi sur la signature et le chiffrement

La signature SMB aide à prévenir la falsification et certains jeux de relais d’identifiants. Mais la signature coûte du CPU.
Sur des serveurs modernes, c’est généralement acceptable ; sur de vieux NAS ou des VM surchargées, cela peut faire la différence entre « rapide » et « pourquoi tout est à 12 Mo/s ? »

Le chiffrement SMB est fantastique quand vous en avez besoin (réseaux non fiables, segments multi-tenant, partages sensibles).
C’est aussi une façon facile de rendre un cluster de stockage lent pendant que les CPU montent en charge pour la cryptographie.
Utilisez-le là où il réduit un risque réel ; n’activez pas tout globalement puis ne soyez pas surpris quand les performances changent.

Désactiver l’authentification legacy quand vous le pouvez

SMB1 traîne souvent des comportements d’authentification anciens. Si vous autorisez encore NTLMv1 ou LM en 2026, vous n’êtes pas « compatible » ;
vous invitez l’abus d’identifiants. Avancez vers Kerberos et des politiques NTLM modernes, et gardez l’accès invité désactivé à moins d’apprécier les interventions IR.

Blague n°2 : « Exception temporaire SMB1 » est l’équivalent IT de « je prendrai juste un cookie ».

Tâches pratiques : commandes, sorties, décisions

Voici des tâches réelles que vous pouvez exécuter en production avec un minimum de drame. Chaque tâche inclut ce que la sortie signifie et la décision à en tirer.
Mixez selon que vous possédez des serveurs Windows, Samba ou un NAS.

Task 1: Check SMB dialect and features negotiated (Windows client)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,SigningRequired,Encrypted | Format-Table -Auto"
ServerName ShareName Dialect NumOpens SigningRequired Encrypted
---------- --------- ------ -------- ---------------- ---------
NAS01      data      3.1.1  24       True             False
FS01       profiles  3.0    6        True             True

Signification : Le Dialect indique ce qui a été réellement négocié. Si vous voyez 1.5 ou « 1.0 » (SMB1), vous avez une lacune de politique.
Décision : Si du SMB1 apparaît, identifiez la paire client/serveur et désactivez SMB1 là où c’est approprié. Si le chiffrement est activé de manière inattendue, attendez-vous à un impact CPU.

Task 2: Confirm SMB1 server is disabled (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol | Format-List"
EnableSMB1Protocol : False
EnableSMB2Protocol : True

Signification : Ceci est le réglage effectif côté serveur SMB.
Décision : Si EnableSMB1Protocol est True, désactivez-le pendant une fenêtre de changement et surveillez les plaintes des périphériques legacy (puis corrigez les périphériques).

Task 3: Disable SMB1 server (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force"

Signification : Le support serveur SMB1 est désactivé.
Décision : Planifiez un redémarrage seulement si votre build/stratégie OS l’exige ; validez que les nouvelles connexions négocient SMB2/3 ; surveillez les journaux d’événements pour des négociations échouées.

Task 4: Check whether SMB1 client feature is installed (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object FeatureName,State"
FeatureName  State
-----------  -----
SMB1Protocol Enabled

Signification : Les composants client SMB1 sont présents.
Décision : Désactivez/supprimez SMB1 sur les clients sauf exception isolée. Cela réduit les retombées d’un fallback et la surface d’attaque.

Task 5: Remove SMB1 client feature (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

Signification : La suppression de la fonctionnalité est en file ; un redémarrage est requis.
Décision : Coordonnez le redémarrage avec la gestion des endpoints. Après redémarrage, validez l’accès aux partages et assurez-vous qu’aucun dialecte SMB1 n’apparaît.

Task 6: Identify SMB server sessions and dialects (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Select-Object ClientComputerName,ClientUserName,Dialect,NumOpens | Sort-Object Dialect | Format-Table -Auto"
ClientComputerName ClientUserName     Dialect NumOpens
------------------ --------------     ------ --------
WS043              CORP\j.singh       3.1.1  18
WS019              CORP\finance.svc   3.0    4

Signification : Vous voyez quels clients utilisent réellement quel dialecte.
Décision : Si des sessions montrent SMB1, vous pouvez chasser le client immédiatement. Si le dialecte est SMB2/3 mais que les performances sont mauvaises, passez aux vérifications latence/crédits/chiffrement.

Task 7: Samba: check effective SMB protocol floor/ceiling

cr0x@server:~$ testparm -s 2>/dev/null | egrep -i "server min protocol|server max protocol|client min protocol|client max protocol"
server min protocol = SMB2_02
server max protocol = SMB3_11
client min protocol = SMB2_02
client max protocol = SMB3_11

Signification : Samba ne négociera pas en dessous de SMB2_02 et peut aller jusqu’à SMB3_11.
Décision : Si vous voyez NT1 (SMB1) quelque part, augmentez le minimum. Si le max est trop bas, mettez à jour Samba ou ajustez la config pour autoriser SMB3.

Task 8: Samba: actively see connected clients and negotiated dialect

cr0x@server:~$ smbstatus -S
Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         1842    10.40.12.77    Tue Feb  5 09:21:44 2026 UTC    -            SMB2
profiles     1920    10.40.10.31    Tue Feb  5 09:24:11 2026 UTC    AES-128-GCM  SMB3_11

Signification : Samba rapporte l’état de signature/chiffrement par session (varie selon la version).
Décision : Si le chiffrement apparaît de manière inattendue sur un partage lourd, mesurez le CPU. Si la signature indique SMB2 alors que vous attendiez SMB3_11, vous avez peut-être un problème de capacité client ou de politique.

Task 9: Samba: set minimum protocol to SMB2 (disable SMB1) and reload

cr0x@server:~$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
cr0x@server:~$ sudo bash -lc 'printf "\n[global]\n   server min protocol = SMB2_02\n   server max protocol = SMB3_11\n" >> /etc/samba/smb.conf'
cr0x@server:~$ sudo systemctl reload smbd

Signification : Samba refusera les négociations SMB1 après le reload.
Décision : Surveillez les logs pour clients rejetés ; si quelque chose casse, c’est qu’on vous indique quel appareil remplacer ou isoler.

Task 10: Check Samba logs for dialect negotiation failures

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "protocol|SMB1|NT1|negotiate|reject" | tail -n 20
Feb 05 09:44:10 nas01 smbd[2112]: negotiate_protocol: No compatible protocol. Client offered: NT1
Feb 05 09:44:10 nas01 smbd[2112]: Failed to negotiate protocol with client 10.40.50.19

Signification : Un client tente SMB1 (NT1) et est rejeté.
Décision : Identifiez le périphérique à cette IP et décidez : mettre à jour le firmware, remplacer le périphérique, ou l’isoler derrière un partage passerelle legacy avec contrôles stricts.

Task 11: Check if SMB encryption is enabled on a Windows share

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -Name data | Select-Object Name,EncryptData,CachingMode | Format-List"
Name        : data
EncryptData : False
CachingMode : Manual

Signification : Le chiffrement au niveau du partage est désactivé.
Décision : Si le partage traverse une frontière réseau non fiable, envisagez d’activer le chiffrement. Si les performances sont déjà tendues, faites un benchmark avant/après.

Task 12: Enable SMB encryption on a specific Windows share (surgical, not blanket)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbShare -Name data -EncryptData $true"

Signification : Les clients doivent utiliser le chiffrement SMB3 pour accéder à ce partage.
Décision : Déployez cela par partage, pas globalement. Validez le support côté client et surveillez le CPU et le débit serveur après activation.

Task 13: Verify SMB signing requirements on Windows Server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature | Format-List"
RequireSecuritySignature : True
EnableSecuritySignature  : True

Signification : La signature est activée et requise.
Décision : Si les performances sont mauvaises, vérifiez d’abord le CPU et le réseau. Si le serveur est sous-dimensionné, vous aurez besoin de meilleur matériel ou de stratégies d’offload — ne désactivez pas la signature à la légère.

Task 14: Linux client: show negotiated SMB dialect for a mounted share

cr0x@server:~$ mount | grep -i cifs
//nas01/data on /mnt/data type cifs (rw,relatime,vers=3.1.1,sec=krb5,cache=strict,username=CORP\\j.singh,uid=1000,gid=1000)

Signification : Le client Linux utilise SMB 3.1.1. Bien.
Décision : Si vous voyez vers=1.0 ou vers=2.0 de façon inattendue, ajustez les options de montage et assurez-vous que le serveur supporte des dialectes plus récents.

Task 15: Linux client: force SMB3 and fail fast if server can’t do it

cr0x@server:~$ sudo mount -t cifs //nas01/data /mnt/data -o vers=3.1.1,sec=krb5,seal,username=CORP\\j.singh
mount error(95): Operation not supported

Signification : Le serveur ou la pile client ne supporte pas l’ensemble de fonctionnalités demandé (ici : SMB3.1.1 + chiffrement).
Décision : Décidez de mettre à jour Samba/noyau, d’ajuster vers un dialecte supporté, ou de déplacer la charge. Ne « corrigez » pas en réactivant SMB1.

Task 16: Network reality check from the client (latency and loss hints)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.40.10.20) 56(84) bytes of data.
64 bytes from 10.40.10.20: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.40.10.20: icmp_seq=2 ttl=63 time=12.9 ms
64 bytes from 10.40.10.20: icmp_seq=3 ttl=63 time=1.05 ms
64 bytes from 10.40.10.20: icmp_seq=4 ttl=63 time=1.09 ms
64 bytes from 10.40.10.20: icmp_seq=5 ttl=63 time=1.08 ms

--- nas01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.05/3.45/12.9/4.73 ms

Signification : Pas de perte de paquets, mais la gigue monte à 12.9 ms.
Décision : SMB déteste la gigue. Cherchez la congestion, les offloads NIC défectueux, le Wi‑Fi mauvais ou des switches virtuels surchargés avant d’accuser « le NAS ».

Task 17: Quick throughput sanity check (storage vs network suspicion)

cr0x@server:~$ dd if=/dev/zero of=/mnt/data/smb-test.bin bs=16M count=64 conv=fdatasync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s
17179869184 bytes (17 GB, 16 GiB) copied, 292 s, 58.8 MB/s
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s

Signification : Les écritures sont à ~58 MB/s. Sur un 1 GbE sain, on peut attendre plutôt ~90–110 MB/s pour des écritures séquentielles, selon l’overhead et le chiffrement/signature.
Décision : Si c’est bien en dessous des attentes du lien, vérifiez le CPU client (chiffrement/signature), la négociation NIC et la latence disque serveur. Si c’est proche des attentes, regardez les motifs I/O applicatifs en petites IO.

Task 18: Windows: check NIC speed/duplex (yes, it still bites)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed | Format-Table -Auto"
Name        Status LinkSpeed
----        ------ ---------
Ethernet0   Up     1 Gbps
Ethernet1   Up     100 Mbps

Signification : Une NIC est à 100 Mbps. Ce n’est pas « un peu plus lent », c’est une autre décennie.
Décision : Corrigez le câblage/port switch/autonégociation. Si le multichannel SMB est activé, la NIC lente peut tirer les performances vers le bas ou provoquer des comportements étranges selon la politique.

Guide de diagnostic rapide

Les problèmes SMB ne sont rarement « juste SMB ». Ce sont généralement l’une des quatre choses : incompatibilité de négociation/politique, qualité réseau,
CPU serveur (crypto/signature), ou latence stockage. L’astuce est de trouver laquelle en minutes, pas en heures.

Première étape : confirmer le dialecte et le mode de sécurité

• Sur un client Windows : Get-SmbConnection et regardez Dialect, SigningRequired, Encrypted.
• Sur un serveur Windows : Get-SmbSession pour les dialectes clients.
• Sur Samba : smbstatus -S (dialecte/signature/chiffrement selon la version).

Si quelque chose négocie SMB1, arrêtez le diagnostic de performance. Vous diagnostiquez un échec de politique. Corrigez cela d’abord.

Deuxième étape : décider si ça sent le réseau, le CPU ou le disque

• Odeur réseau : ping instable, perte de paquets, clients Wi‑Fi, chemins VPN, routage asymétrique, comportements ECMP étranges.
• Odeur CPU : les performances chutent seulement quand le chiffrement/la signature est activé(e) ; le CPU serveur monte lors des copies.
• Odeur disque : SMB tient pour un client mais s’effondre avec plusieurs ; la latence stockage monte ; les charges riches en métadonnées (beaucoup de petits fichiers) rampent.

Troisième étape : mesurer une chose à la fois

1. RTT/gigue client‑serveur : un ping rapide suffit pour un indice, puis utilisez des outils OS pour des vérifications approfondies.
2. Débit monoflux : un test de lecture/écriture contrôlé pour isoler les plafonds bruts.
3. Comportement en concurrency : SMB2/3 utilise des crédits ; les problèmes apparaissent souvent sous opérations parallèles.
4. CPU vs latence disque : surveillez le CPU serveur et la latence stockage pendant la même fenêtre de test.

Règle pratique de triage

Si une grosse copie de fichier est rapide mais l’ouverture de dossiers contenant beaucoup de fichiers est lente, vous avez un comportement lié aux métadonnées/latence.
Si la copie de gros fichiers est lente et que le CPU est saturé, regardez la signature/le chiffrement.
Si les performances sont incohérentes et que les pics corrèlent avec la gigue réseau, c’est le réseau même si personne ne veut l’admettre.

Trois mini-récits d’entreprise

Mini-récit 1 : L’incident causé par une hypothèse erronée

Une entreprise de taille moyenne avait un « carve-out legacy » pour quelques appareils de production. L’hypothèse était simple : ces appareils étaient sur leur propre VLAN,
donc autoriser SMB1 « juste pour ce réseau » était sûr. L’équipe fichiers a activé SMB1 sur un serveur de fichiers central parce que c’était plus rapide que de construire une passerelle dédiée.

Des mois plus tard, un projet non lié a connecté temporairement une station de travail de test au VLAN de production pour exécuter des diagnostics. La station était
jointe au domaine, sous‑patchée et avait un large accès est‑ouest dont personne ne se souvenait. Elle a attrapé un malware via un téléchargement piégé.

Le malware n’avait pas besoin d’ingéniosité ; il avait juste besoin d’accès.
SMB1 était atteignable. Le serveur de fichiers avait des partages avec une héritage ACL permissif parce que « c’est comme ça que ça a toujours été. » L’attaque s’est propagée latéralement
et a commencé à chiffrer des dossiers partagés. L’équipe a d’abord chassé les permissions et les jobs de sauvegarde parce qu’ils ne voulaient pas croire qu’une fuite de VLAN importait.

La correction post‑incident n’était pas exotique. Ils ont désactivé SMB1 sur le serveur central, construit une petite passerelle SMB isolée pour les appareils de production,
et resserré le routage pour que toute connexion « temporaire » nécessite des approbations explicites. La vraie correction fut culturelle : les hypothèses d’isolation furent traitées comme
des hypothèses à tester, pas des vérités à répéter.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a déployé massivement le chiffrement SMB parce qu’un audit sécurité signalait « partages de fichiers non chiffrés ». L’équipe stockage a obtempéré rapidement :
activer le chiffrement côté partage pour tout et considérer la mission accomplie. L’audit fut validé. Cela changea aussi silencieusement la physique du système.

Deux semaines plus tard, le helpdesk a reçu des plaintes « lecteur réseau lent ». Puis l’équipe VDI a ajouté : les tempêtes de connexion prenaient plus de temps, les profils échouaient,
et le blâme rebondissait entre réseau, stockage et « Windows qui est Windows ».

La cause réelle était banale : les serveurs de fichiers étaient des machines virtuelles avec peu de marge CPU. Le chiffrement les a poussés en contention CPU pendant les pics.
SMB ne tombait pas en panne ; il ralentissait. C’est pire, car cela semble « à peu près fonctionner » tandis que la productivité se vide.

La solution n’a pas été « couper la sécurité ». Ils ont limité le chiffrement aux partages traversant des frontières moins fiables et aux données sensibles,
puis redimensionné quelques serveurs et réparti la charge. La leçon : les contrôles de sécurité ont un coût de performance, et ce coût apparaît là où l’entreprise le remarque — connexions et ouvertures de fichiers — à moins de planifier la capacité.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société globale avait une politique : avant toute dépréciation de protocole, inventorier l’utilisation réelle pendant 30 jours, implémenter un blocage avec journalisation,
puis supprimer l’option legacy. Ce n’est pas glamour. C’est le genre de chose dont on se moque jusqu’à ce que ça vous sauve.

Quand ils ont ciblé la suppression de SMB1, ils n’ont pas commencé par couper globalement. Ils ont d’abord activé la journalisation en périphérie et sur les serveurs de fichiers,
capturant quels clients tentaient la négociation SMB1. Quelques appareils sont apparus : un scanner d’entrepôt, une vieille imprimante multifonction,
et une box Linux oubliée montant des partages avec vers=1.0.

Ils ont corrigé les options de montage Linux, mis à jour les firmwares quand possible, et pour le scanner d’entrepôt ils ont construit un chemin de partage dédié et isolé.
Puis ils ont désactivé SMB1 largement et surveillé les logs. Rien n’a crié. Pas de pannes surprises. Pas de « demande d’exception exécutive » urgente.

Deux mois plus tard, un test d’intrusion a essayé des attaques basées sur SMB1 contre des segments internes. Il n’y avait rien d’à l’écoute. Le rapport fut court.
L’équipe avait fait le travail ennuyeux, et le travail ennuyeux est ce à quoi ressemble la fiabilité un bon jour.

Erreurs fréquentes : symptôme → cause → correction

1) « Nous avons désactivé SMB1, mais quelque chose le négocie encore »

Symptôme : Vous voyez encore SMB1/NT1 dans les journaux ou les sessions.

Cause : Désactivé sur le serveur mais encore activé sur un autre serveur ; ou le client a la fonctionnalité SMB1 installée et se connecte à un vieux NAS ne parlant que SMB1.

Correction : Inventoriez les dialectes négociés via Get-SmbSession/Get-SmbConnection ou smbstatus. Désactivez SMB1 sur les deux bouts. Remplacez ou isolez l’appareil uniquement SMB1.

2) « Les copies de fichiers sont lentes après activation du chiffrement »

Symptôme : Le débit chute ; le CPU serveur pique ; les utilisateurs se plaignent aux heures de pointe.

Cause : Le chiffrement SMB3 consomme beaucoup de CPU ; le dimensionnement VM ou le CPU NAS ne suit pas.

Correction : Activez le chiffrement uniquement sur les partages sensibles ou segments non fiables ; ajoutez du CPU ; envisagez du matériel avec accélération AES ; testez avant un déploiement large.

3) « Les opérations sur petits fichiers sont terriblement lentes, les gros fichiers vont bien »

Symptôme : L’ouverture de dossiers contenant beaucoup de fichiers est lente ; les applications scannant des répertoires rampent.

Cause : Les opérations metadata sont sensibles à la latence ; gigue réseau, contrôleurs de domaine surchargés (délais d’auth), ou latence stockage sur ensembles riches en métadonnées.

Correction : Réduisez la gigue ; vérifiez la réactivité DNS/DC ; contrôlez la latence stockage et les IOPS ; envisagez de tierer les métadonnées sur des médias plus rapides ; évitez SMB sur WAN sans accélération.

4) « Déconnexions aléatoires, invites d’authentification, ou ‘chemin réseau introuvable’ »

Symptôme : Les sessions tombent de façon intermittente ; les reconnexions demandent des identifiants ; les lecteurs mappés passent en rouge.

Cause : Middleboxes expirant les sessions stateful ; MTU/fragmentation ; offloads NIC instables ; Wi‑Fi mauvais ; routage asymétrique avec multichannel.

Correction : Validez MTU bout à bout ; testez avec les offloads ajustés ; assurez une connectivité câblée stable pour les systèmes critiques ; révisez la conception multichannel et la symétrie du routage.

5) « Nous avons exigé la signature et maintenant les performances sont terribles sur un serveur »

Symptôme : Un serveur de fichiers est lent, les autres vont bien ; le CPU serveur est élevé sous charge SMB.

Cause : Ce serveur est ancien, sous‑dimensionné ou exécute d’autres charges ; l’overhead de signature fait basculer la charge.

Correction : Déplacez les charges ; ajoutez du CPU ; séparez les rôles. Ne désactivez pas la signature globalement parce qu’une machine est faible.

6) « Les clients Linux peuvent monter, mais les clients Windows non (ou vice versa) »

Symptôme : Comportement mixte par OS ; erreurs comme « operation not supported » ou échecs d’authentification.

Cause : Mismatch de dialecte (vers=), mismatch du mode de sécurité (sec=), ou config Samba en conflit avec AD/Kerberos.

Correction : Alignez les dialectes (SMB3.1.1 quand possible), standardisez l’auth (Kerberos pour le domaine), et vérifiez server min protocol de Samba et le mapping d’identité.

Listes de vérification / plan étape par étape

Étape 1 : Trouver l’usage SMB1 sans tout casser (phase d’inventaire)

1. Sur les serveurs de fichiers Windows, listez les sessions et dialectes avec Get-SmbSession.
2. Sur des clients Windows (échantillon), listez les connexions avec Get-SmbConnection.
3. Sur Samba, vérifiez les logs pour des offres NT1 et utilisez smbstatus.
4. Construisez une liste : appareil/IP, propriétaire, fonction métier, chemin de remplacement/mise à niveau.

Étape 2 : Désactiver SMB1 dans une séquence contrôlée

1. Désactivez SMB1 côté serveur sur les serveurs de fichiers généralistes en premier.
2. Désactivez SMB1 côté client via la gestion des endpoints ensuite.
3. Pour les quelques rémanents vrais, fournissez une solution contenue : VLAN isolé + partage passerelle dédié + ACL minimales.

Étape 3 : Durcir SMB2/3 intentionnellement (ne pas faire du cargo-cult)

• Signature : exigez-la selon votre modèle de risque ; assurez-vous que les serveurs sont dimensionnés pour cela.
• Chiffrement : activez-le sur les partages sensibles et segments non fiables ; vérifiez la marge CPU.
• Auth : préférez Kerberos ; réduisez NTLM legacy quand possible ; supprimez l’accès invité.
• Audit : conservez des logs pour les échecs de négociation et les anomalies d’accès.

Étape 4 : Checklist de validation des performances

• Testez un transfert séquentiel important et un workload de nombreux petits fichiers.
• Validez que le dialecte négocié reste sur SMB3.x pour les clients modernes.
• Vérifiez le CPU serveur pendant les copies en pointe avec signature/chiffrement activés.
• Vérifiez la vitesse et la stabilité des NIC clients ; évitez le Wi‑Fi pour les workflows SMB lourds quand possible.
• Confirmez la latence stockage sous charge ; SMB transmet fidèlement vos problèmes de stockage aux utilisateurs.

Étape 5 : Gestion des exceptions (la partie que tout le monde tente de sauter)

• Chaque exception SMB1 nécessite : propriétaire, justification, isolation réseau, surveillance et date de retrait.
• Si vous ne pouvez pas l’isoler, vous n’avez pas d’exception — vous avez une vulnérabilité.

FAQ

1) SMB1 est‑il acceptable sur un réseau interne ?

Non, pas par défaut. « Interne » n’est pas une frontière de sécurité ; c’est une description de routage. Si vous devez garder SMB1 pour un appareil, isolez‑le et limitez dans le temps.

2) Si je désactive SMB1, les clients Windows utiliseront‑ils automatiquement SMB2/3 ?

Les Windows modernes négocieront SMB2/3 si le serveur le supporte. Si quelque chose casse, c’est généralement parce que le serveur (ou NAS) ne supporte que SMB1,
ou parce qu’un client est ancien ou mal configuré.

3) Quelle est la différence pratique entre SMB2 et SMB3 pour la plupart des organisations ?

SMB3 ajoute le chiffrement et des fonctionnalités performance avancées (multichannel, SMB Direct). Si vous n’en avez pas besoin, SMB2 reste une grande amélioration par rapport à SMB1.
En pratique, vous voudrez SMB3 pour des flottes Windows modernes et une posture de sécurité actuelle.

4) Le chiffrement SMB remplace‑t‑il le besoin de signature ?

Le chiffrement protège la confidentialité (et l’intégrité des payloads chiffrés), mais la signature fait toujours partie des mécanismes empêchant la falsification dans divers modes et politiques.
Considérez-les comme des contrôles liés, pas des substituts stricts.

5) Pourquoi SMB est parfois rapide pour un utilisateur et lent pour plusieurs ?

La concurrence expose les limites CPU serveur (signature/chiffrement), les limites IOPS/latence stockage et le comportement de crédits SMB. Les tests mono‑utilisateur peuvent tromper.
Testez toujours sous charge parallèle réaliste lors de la validation des changements.

6) Dois‑je activer SMB multichannel partout ?

Seulement si votre conception réseau le supporte proprement (plusieurs NIC, routage stable, MTU cohérent, pas de middleboxes bizarres).
Le multichannel peut augmenter le débit, mais aussi amplifier les mauvaises configurations en sessions instables.

7) Nous avons un appliance NAS. Les mêmes règles s’appliquent ?

Oui. Les réglages peuvent être dans une interface graphique, mais les risques et modes de panne sont identiques. Assurez‑vous que le firmware NAS supporte SMB3.x, désactivez SMB1,
et validez les dialectes négociés depuis les clients.

8) Et les clients Linux montant des partages SMB — que doit‑on standardiser ?

Standardisez sur SMB3.1.1 quand possible, utilisez Kerberos (sec=krb5) en environnement de domaine, et évitez les fallback permissifs.
Rendez les montages explicites plutôt que de compter sur des défauts qui varient selon la distro et le noyau.

9) Si je désactive SMB1, comment gérer les anciennes imprimantes/scanners qui ne font que SMB1 ?

Mettez‑les sur un segment réseau isolé, donnez‑leur un partage de dépôt dédié avec des permissions strictes, et planifiez leur remplacement.
Si le métier refuse le remplacement, documentez le risque et contenez‑le agressivement.

10) Comment prouver à la direction que désactiver SMB1 en vaut la peine ?

Montrez des preuves : quels appareils négocient encore SMB1, ce que cette exposition permet, et comment les exceptions peuvent être isolées.
Puis présentez un plan de retrait avec un impact métier minimal et des responsables clairs.

Conclusion : prochaines étapes sans perdre votre week-end

SMB1 n’est pas « support legacy ». C’est une responsabilité qui se manifeste par des incidents de sécurité et des problèmes de fiabilité étranges que vous ne réparerez jamais complètement.
SMB2/3 ne sont pas parfaits, mais ils sont conçus pour le monde dans lequel vous opérez vraiment : réseaux occupés, serveurs virtualisés et adversaires qui scannent tout.

Prochaines étapes pratiques :

1. Inventoriez les dialectes SMB négociés dans votre environnement (clients et serveurs). Trouvez les communicateurs SMB1.
2. Désactivez SMB1 côté serveur sur les serveurs de fichiers généraux. Ensuite retirez la fonctionnalité SMB1 côté client sur toute la flotte.
3. Pour les rémanents, isolez‑les et limitez dans le temps. Aucune exception sans containment et date de retrait.
4. Validez les performances SMB2/3 avec deux tests : copies séquentielles importantes et opérations nombreux‑petits‑fichiers.
5. Affinez la sécurité intentionnellement : signature selon politique, chiffrement par partage quand il réduit un risque réel, et prévoyez la capacité CPU.

L’objectif n’est pas de gagner un concours de pureté protocolaire. L’objectif est des partages de fichiers ennuyeux : assez rapides, assez sécurisés, et qui ne sont pas la raison pour laquelle vous ratez votre dîner.