SMB (Server Message Block) est le protocole derrière les partages de fichiers Windows, les lecteurs réseau et les dossiers où vivent les documents, les fichiers d'ingénierie et les programmes d'automates. Il fonctionne sur le port TCP 445 (139 pour l'héritage) et est omniprésent dans l'IT, et de plus en plus relié à l'OT pour le transfert de recettes, de programmes et de rapports. C'est aussi l'un des chemins les plus courants pour la propagation des rançongiciels et pour la fuite de données hors d'un site, ce qui fait du contrôle de qui peut atteindre un partage un contrôle de sécurité à forte valeur.
Sécuriser SMB se comprend mieux en couches : qui peut atteindre le partage, comment les octets sont protégés en transit, et ce qu'un utilisateur peut faire une fois connecté. Access Gate prend en charge la première couche et complète les deux autres.
Les versions de SMB décident de ce qui est possible
La version du protocole négociée sur un partage fixe le plancher de sécurité, et les anciennes versions sont un véritable risque :
- SMBv1. Obsolète et dangereux. C'est le vecteur derrière EternalBlue et la plupart des rançongiciels véhiculés par SMB (
T1021.002), il n'a aucun chiffrement significatif et une signature faible. Il devrait être désactivé partout ; si un équipement hérité ne parle que SMBv1, l'isoler derrière le gate est la priorité. - SMB 2.x. Prend en charge la signature (intégrité et anti-altération) mais pas le chiffrement.
- SMB 3.x. Ajoute le chiffrement (AES-CCM, et AES-GCM en 3.1.1) et une signature plus robuste. C'est la confidentialité propre à SMB sur le fil, négociée entre le client et le serveur, indépendante de tout tunnel.
La conséquence pratique : sur un client et un serveur modernes, vous pouvez obtenir la confidentialité sur le fil grâce à SMB3 lui-même. Sur un équipement hérité, vous ne le pouvez pas, et le contrôle de l'accessibilité par le gate devient la protection porteuse.
Trois couches pour sécuriser un partage
Couche 1 : contrôler qui atteint le partage (Access Gate)
C'est la couche fournie par Access Gate, et la plus précieuse face au risque de rançongiciel et d'exfiltration.
Pour commencer, ajoutez le serveur de fichiers en tant qu'actif, définissez son service SMB et placez-le dans une enclave avec une règle allow accordant l'accès. Voir Protéger un actif avec les enclaves et Listes de contrôle d'accès.
Pointez le client vers le partage en utilisant l'IP overlay d'Access Gate plutôt que l'adresse brute du serveur de fichiers. La session est médiée par le gate.
La connexion est établie et les paquets transitent par le gate.
Jusqu'ici, l'accès est accordé par une politique réseau. Ajoutez un écran d'accès pour exiger que l'utilisateur s'authentifie avant que le partage ne soit accessible, transformant l'accessibilité en une autorisation à identité vérifiée. Voir Authentifier les utilisateurs avec les écrans d'accès.
L'utilisateur doit désormais s'authentifier via l'écran d'accès avant que l'accès ne soit accordé. Tant qu'il ne le fait pas, le partage reste inaccessible.
Le gate détecte et journalise chaque session SMB qu'il médie :
Couche 2 : protéger les octets sur le fil (SMB3)
Lorsque le client et le serveur parlent tous deux SMB 3.x, activez le chiffrement et exigez la signature sur le partage. La signature stoppe les attaques par relais SMB et par altération ; le chiffrement apporte la confidentialité sans aucun tunnel. C'est l'équivalent natif de SMB pour la sécurité au niveau du message : il est négocié mutuellement et ne nécessite aucun terminateur. Sous Windows, cela se règle par partage ou à l'échelle du serveur (Set-SmbServerConfiguration -EncryptData $true, et exiger la signature). Traitez-le comme la valeur par défaut pour tout partage moderne transportant des fichiers sensibles.
Pour un client ou un serveur hérité qui ne peut pas faire de chiffrement SMB3, le fil n'est pas protégé par lui-même, et l'isolation de la couche 1 plus un chemin réseau de confiance deviennent le récit de la confidentialité. Dites-le honnêtement plutôt que de supposer que les octets sont chiffrés.
Couche 3 : ce que l'utilisateur peut faire (permissions côté serveur)
Le gate décide qui atteint le partage ; le serveur de fichiers décide encore ce que l'utilisateur peut faire une fois arrivé. Gardez les permissions de partage et NTFS comme une couche distincte, au moindre privilège. Le gate ne les remplace pas, il place une porte d'entrée à identité vérifiée devant elles.
Notes et points de vigilance
- Désactivez d'abord SMBv1. Avant tout autre réglage, confirmez que SMBv1 est désactivé sur l'ensemble du parc ; isoler derrière le gate tout équipement qui l'exige encore est la priorité.
- Des couches, pas des alternatives. L'accessibilité par le gate, le chiffrement SMB3 et les permissions serveur défendent chacun une défaillance différente. Utilisez les trois.
Récapitulatif
Vous avez sécurisé un partage en couches : une enclave Access Gate et un écran d'accès pour que l'accessibilité sur le port 445 devienne une autorisation à identité vérifiée, la signature et le chiffrement SMB3 pour que les octets soient protégés sur le fil, et des permissions côté serveur pour qu'un utilisateur connecté ne puisse toujours faire que ce à quoi il a droit.
Optez pour cette approche pour contrôler qui peut atteindre un partage de fichiers Windows sur le port 445, un chemin courant pour la propagation des rançongiciels et la fuite de données, tout en gardant la protection native SMB3 et les permissions côté serveur comme couches derrière lui.