RDP fonctionne, partage de fichiers non : corriger correctement les règles de pare‑feu

Ce que RDP prouve (et ce qu’il ne prouve pas)

Quand RDP fonctionne et que le partage de fichiers échoue, la cause racine est généralement l’une des suivantes :

• Décalage de périmètre du pare‑feu : RDP autorisé depuis « Any », SMB autorisé uniquement depuis « Local subnet », ou seulement sur le profil « Domain » alors que le serveur est en « Public ».
• Incohérence de ports : Vous avez ouvert 139, mais SMB utilise en réalité 445 (ou inversement dans certains contextes anciens), ou le client insiste pour SMB sur 445 alors que vous n’avez autorisé que des endpoints RPC pour autre chose.
• Mauvaise résolution de noms : RDP utilise une IP enregistrée ou un enregistrement DNS ; SMB tente NetBIOS, LLMNR ou un suffixe DNS incorrect ; vous vous connectez à un hôte différent de celui que vous croyez.
• Chemin d’authentification incohérent : RDP fonctionne avec des identifiants en cache ou comptes locaux ; SMB requiert Kerberos/LDAP vers un contrôleur de domaine inaccessible depuis ce réseau, donc l’authentification échoue après la poignée de main TCP.
• Incompatibilité de signature/chiffrement SMB : La connexion est autorisée mais la négociation échoue à cause de politiques incompatibles.
• Problèmes de filtrage stateful : Certains pare‑feux « intelligents » ou IDS perturbent les sessions SMB, particulièrement à travers VPN/NAT.

RDP et SMB sont des bêtes différentes. RDP est typiquement un seul flux TCP vers un port unique. SMB est une négociation bavarde avec des attentes strictes sur la continuité de session, et il implique souvent les services d’annuaire. Vos règles de pare‑feu doivent refléter cette réalité.

Blague n°1 (courte, pertinente) : Les pare‑feux sont comme des videurs : ils se souviennent du VIP qu’ils ont laissé entrer (RDP) et sont ensuite choqués quand tout le groupe arrive (SMB).

Carte du trafic SMB : ports, protocoles, et pourquoi « 445 » ne fait pas tout

Les ports minimaux qui comptent

Si vous utilisez SMB moderne (Windows 7+ / Server 2008+ et plus récent), le cœur est :

• TCP/445 — hébergement SMB direct. C’est celui dont vous avez presque toujours besoin.

La réalité héritée et « en entreprise » ajoute d’autres éléments :

• TCP/139 — SMB via NetBIOS session service (plus ancien ; parfois encore utilisé dans des environnements mixtes).
• UDP/137, UDP/138 — service de noms NetBIOS et datagramme (découverte/résolution de noms héritée).
• TCP/135 et une plage de ports RPC dynamiques — non requis pour le partage de fichiers basique, mais nécessaires pour de nombreuses actions de gestion (MMC, certains partages d’imprimantes, administration distante, gestion DFS, etc.).
• Kerberos/LDAP/DNS vers les contrôleurs de domaine — pas des « ports SMB », mais souvent requis pour l’authentification et la résolution d’appartenance aux groupes :
  • TCP/88 (Kerberos), TCP/389 (LDAP), TCP/636 (LDAPS), TCP/53 et UDP/53 (DNS)

Pourquoi ouvrir 445 ne suffit parfois pas

Parce que l’échec du partage peut survenir après la connexion TCP. Couches typiques :

1. Routage/ACL : Le client peut‑il atteindre le serveur du tout (sur le port 445) depuis la bonne IP source ?
2. Pare‑feu stateful : Le SYN/SYN‑ACK/ACK se complète‑t‑il, et le trafic de retour est‑il autorisé ?
3. Négociation SMB : Le client et le serveur s’accordent‑ils sur les dialectes (SMB2/SMB3), la signature, le chiffrement ?
4. Authentification : Le serveur peut‑il valider les identifiants (SAM local vs AD), et peut‑il atteindre un DC si nécessaire ?
5. Autorisation : Permissions de partage et permissions NTFS.
6. Stabilité : Problèmes de MTU, middleboxes qui réinitialisent les sessions longue durée, verrous opportunistes, ou délais d’expiration SMB.

Mode opératoire de diagnostic rapide : trouvez le goulot d’étranglement avant de modifier les règles

Ceci est la manière la plus rapide d’arrêter de tâtonner dans le noir.

Première étape : prouvez que vous atteignez le bon hôte

1. Résolvez le nom de la même manière que le fait SMB. Testez le nom d’hôte que vous tapez réellement dans l’Explorateur ou dans votre commande de montage.
2. Comparez la réponse DNS à la cible RDP. Les gens font un RDP vers une IP et naviguent vers un nom. C’est ainsi qu’on se met à déboguer la mauvaise machine.

Deuxième étape : testez TCP/445 depuis le client

1. Exécutez un test de port (Windows : Test-NetConnection ; Linux : nc).
2. Si c’est bloqué, stoppez. Corrigez le routage/ACL/pare‑feu avant de toucher aux configs SMB.

Troisième étape : testez explicitement la négociation et l’authentification SMB

1. Windows : essayez net use ou Get-SmbConnection ; Linux : smbclient.
2. Différenciez : « impossible de se connecter » vs « mauvais nom d’utilisateur/mot de passe » vs « accès refusé ». Ce sont des équipes et des correctifs différents.

Quatrième étape : inspectez les profils du pare‑feu et le périmètre des règles

1. Serveur Windows : confirmez le profil réseau actif (Domain/Private/Public).
2. Confirmez que la règle « File and Printer Sharing (SMB-In) » est activée pour le bon profil et restreinte aux bonnes IP distantes.

Cinquième étape : capturez les paquets sur les deux extrémités (uniquement si nécessaire)

1. Capture client : voyez‑vous les SYN partir ? Recevez‑vous des SYN‑ACK en retour ?
2. Capture serveur : voyez‑vous les SYN arriver ? Voyez‑vous des RST partir ? Cela vous indique si c’est le pare‑feu serveur qui frappe le marteau.

Faits intéressants et contexte historique (ce qui explique les bizarreries actuelles)

• Fait 1 : SMB est né dans les années 1980 chez IBM puis a été fortement étendu par Microsoft ; ce protocole « simple » porte des décennies de dette technique.
• Fait 2 : TCP/445 est devenu le défaut pour l’hébergement SMB direct lorsque Windows a réduit sa dépendance à NetBIOS ; c’est pourquoi 139 ressemble à un port fantôme qui hante encore les audits.
• Fait 3 : Les vers tristement célèbres du début des années 2000 (qui exploitaient les services réseau Windows) expliquent pourquoi les équipes de sécurité traitent 445 comme radioactif hors des réseaux de confiance.
• Fait 4 : La signature SMB existe pour empêcher les attaques MITM ; elle améliore l’intégrité mais peut révéler des surprises de performances et de compatibilité si elle est configurée de manière incohérente.
• Fait 5 : SMB3 a introduit le chiffrement au niveau du protocole (pas seulement via IPsec), ce qui a modifié le comportement de certains systèmes de surveillance et middleboxes.
• Fait 6 : Les profils du pare‑feu Windows (Domain/Private/Public) ont été conçus pour la mobilité des portables, pas pour des serveurs avec plusieurs NIC ; les serveurs sont encore souvent mal profilés de manière surprenante.
• Fait 7 : La résolution NetBIOS et la découverte par broadcast étaient pratiques sur des LAN plats ; elles sont fragiles sur des réseaux routés et sont fréquemment bloquées par conception.
• Fait 8 : « File and Printer Sharing » est un ensemble de règles, pas un simple interrupteur ; activer le mauvais sous‑ensemble est une moitié de correction fréquente.
• Fait 9 : Beaucoup d’organisations bloquent volontairement SMB à travers WAN/VPN et fournissent l’accès aux fichiers via des passerelles (DFS, SFTP, portails HTTPS). Votre « ça devrait fonctionner » peut être une politique, pas un bug.

Une citation, parce que ça reste vrai : Paraphrasé : « L’espoir n’est pas une stratégie. » — souvent attribué dans les cercles opérationnels ; traitez‑le comme une devise SRE, pas comme un dogme.

Tâches pratiques : commandes, sorties et la décision à prendre

Voici des vérifications réelles que vous pouvez exécuter. Chacune indique ce que la sortie signifie et ce que vous faites ensuite. Choisissez le chemin qui correspond à votre environnement.

Tâche 1 : Confirmez que vous utilisez la même cible pour RDP et SMB (client Windows)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName filesrv01.corp.example -Type A | Select-Object -ExpandProperty IPAddress"
10.20.30.40

Signification : Le nom SMB résout vers 10.20.30.40. Si vous avez fait un RDP vers 10.20.30.41, vous déboguez deux machines différentes.

Décision : En cas de divergence, corrigez le DNS/le fichier hosts, ou utilisez le nom/IP correct de manière cohérente. Arrêtez‑vous ici jusqu’à ce que les cibles correspondent.

Tâche 2 : Vérifiez la route du client vers le serveur SMB (client Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.20.1.1 dev eth0 src 10.20.1.55 uid 1000

Signification : Vos paquets passent par 10.20.1.1 depuis la source 10.20.1.55. Les pare‑feux évalueront cette IP source, pas vos sentiments.

Décision : Si la route est inattendue (mauvaise interface, mauvaise source), corrigez le routage/les politiques VPN split‑tunnel avant de toucher au pare‑feu.

Tâche 3 : Testez le port 445 depuis Windows (le révélateur le plus rapide)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.30.40 -Port 445 | Select-Object ComputerName,RemoteAddress,RemotePort,TcpTestSucceeded"
filesrv01
10.20.30.40
445
False

Signification : La connexion TCP vers le port 445 a échoué. Ce n’est pas un problème de permissions SMB ; c’est un problème de chemin réseau.

Décision : Remontez vers l’extérieur : pare‑feu client ? ACL réseau ? pare‑feu serveur ? groupe de sécurité ? Ne perdez pas de temps sur les permissions de partage pour l’instant.

Tâche 4 : Testez le port 445 depuis Linux (même idée, moins de mots)

cr0x@server:~$ nc -vz 10.20.30.40 445
nc: connect to 10.20.30.40 port 445 (tcp) failed: Connection timed out

Signification : Le timeout implique souvent un drop (pare‑feu/ACL) plutôt qu’un rejet. Un rejet renverrait généralement rapidement « refused ».

Décision : En cas de timeout, vérifiez les dispositifs de sécurité intermédiaires. En cas de « refused », confirmez que le service SMB écoute réellement.

Tâche 5 : Confirmez que le serveur écoute sur le 445 (serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 3 LocalAddress,LocalPort,OwningProcess"
0.0.0.0
445
4

Signification : Le port 445 écoute sur toutes les interfaces. Le PID 4 est le processus System sous Windows, normal pour SMB.

Décision : Si rien n’écoute, assurez‑vous que le service « Server » fonctionne et que les fonctionnalités serveur SMB sont installées. Les changements de pare‑feu ne répareront pas un port fermé.

Tâche 6 : Confirmez que le service « Server » est en cours d’exécution (serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer | Select-Object Status,Name,DisplayName"
Running
LanmanServer
Server

Signification : Le service serveur SMB est en cours d’exécution.

Décision : S’il est arrêté/désactivé, corrigez cela d’abord. S’il fonctionne, passez à l’examen du profil du pare‑feu et du périmètre des règles.

Tâche 7 : Vérifiez le profil actif du pare‑feu Windows (serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory,IPv4Connectivity"
Ethernet0
Public
Internet

Signification : Le serveur pense être sur un réseau Public. Beaucoup de règles « File and Printer Sharing » sont désactivées sur Public par défaut.

Décision : Corrigez le profil réseau (souvent en assurant la connectivité au domaine et le bon binding NIC) ou activez explicitement les règles SMB pour Public avec un périmètre distant strict.

Tâche 8 : Inspectez les règles du pare‑feu liées à SMB (serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile,Direction | Format-Table -AutoSize"
File and Printer Sharing (SMB-In)                 True  Domain,Private  Inbound
File and Printer Sharing (NB-Session-In)          False Domain,Private  Inbound
File and Printer Sharing (NB-Name-In)             False Domain,Private  Inbound
File and Printer Sharing (NB-Datagram-In)         False Domain,Private  Inbound

Signification : SMB‑In est activé, mais seulement pour Domain/Private. Si le serveur est en Public, cela ne correspondra pas.

Décision : Soit corriger le profil en Domain/Private, soit activer SMB‑In sur Public avec un périmètre distant étroit.

Tâche 9 : Confirmez le périmètre distant de la règle du pare‑feu (serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
Any

Signification : Elle autorise depuis n’importe quelle IP distante (dans les profils activés). Cela peut être inacceptable ou acceptable dans un VLAN de confiance.

Décision : En production, restreignez aux subnets connus. « Any » est la voie qui vous mène à une réunion d’audit sans amuse‑bouche.

Tâche 10 : Testez SMB au niveau protocole (client Linux)

cr0x@server:~$ smbclient -L //10.20.30.40 -U 'CORP\alice'
Password for [CORP\alice]:
Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       Remote IPC
Shares          Disk
SMB1 disabled -- no workgroup available

Signification : La connectivité et l’authentification ont réussi. « SMB1 disabled » est une bonne nouvelle, pas un problème.

Décision : Si la liste fonctionne mais que le montage échoue, concentrez‑vous sur les permissions, les politiques de signature/chiffrement SMB ou les options de montage client.

Tâche 11 : Testez le mappage SMB depuis un client Windows (clarté d’authentification)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use * \\10.20.30.40\Shares /user:CORP\alice'"
The command completed successfully.

Signification : Vous pouvez vous authentifier et mapper le partage. Si l’Explorateur échoue encore par nom, c’est un problème de résolution de nom ou de SPN/Kerberos.

Décision : Si l’IP fonctionne et que le nom échoue, corrigez le DNS, les SPN, et évitez la dépendance à NetBIOS/LLMNR.

Tâche 12 : Vérifiez les connexions SMB actuelles (client Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,Encrypted,SigningRequired | Format-Table -AutoSize"
10.20.30.40 Shares 3.1.1  2 False True

Signification : Vous avez négocié SMB 3.1.1 ; la signature est requise ; le chiffrement est désactivé.

Décision : Si vous voyez un ancien dialecte ou une négociation échouée, vérifiez les incompatibilités de politique (client/serveur) avant d’accuser le pare‑feu.

Tâche 13 : Confirmez la configuration du serveur SMB Windows (serveur Windows)

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

Signification : SMB1 désactivé ; SMB2 activé ; accès non chiffré rejeté ; signature requise.

Décision : Si des clients anciens ne peuvent pas se connecter, ne réactivez pas SMB1 à la légère. Corrigez le client. Si vous devez, isolez le legacy via un serveur de partage séparé et un pare‑feu strict.

Tâche 14 : Identifiez si le pare‑feu serveur supprime le trafic (capture de paquets sur serveur Windows)

cr0x@server:~$ powershell -NoProfile -Command "pktmon filter remove; pktmon filter add -p 445; pktmon start --etw -m real-time"
PktMon started.

Signification : Vous capturez le trafic du port 445 en temps réel (basé ETW). Reproduisez maintenant la tentative client.

Décision : Si des SYN arrivent mais aucun SYN‑ACK ne part, ou si des RST sont émis, vous êtes dans le domaine du pare‑feu/service côté serveur. Si rien n’arrive, le blocage est en amont.

Tâche 15 : Vérifiez les règles du pare‑feu Linux (exemple nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
  }
}

Signification : Politique par défaut drop, autoriser SSH seulement. SMB échouera à moins d’ajouter TCP/445 (et peut‑être 139) depuis des sources approuvées.

Décision : Ajoutez une règle acceptée et ciblée pour SMB depuis les bons subnets, pas un allow global.

Tâche 16 : Confirmez que SELinux n’est pas le coupable surprise (serveur Samba Linux)

cr0x@server:~$ getenforce
Enforcing

Signification : SELinux est en mode enforcing. C’est normal, mais des labels incorrects peuvent ressembler à un « problème réseau » quand le daemon ne peut pas accéder au système de fichiers.

Décision : Si les connexions fonctionnent mais l’accès aux partages échoue sur Samba Linux, consultez les logs d’audit et les contexts plutôt que de toucher au pare‑feu.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Le ticket disait « Serveur de fichiers en panne ». L’ingénieur d’astreinte a fait le classique : RDP sur le serveur, vu un bureau sain, CPU calme, disque ok. Il a répondu « Le serveur est up ; ça doit être un problème de permissions. » Cette réponse lui a acheté exactement quinze minutes de paix.

Puis le support a commencé à coller des captures d’écran : tous les utilisateurs, tous les partages, tous les sites. « Network path not found. » Si vous avez vu cette phrase à grande échelle, vous pouvez presque sentir le problème : pas les ACL NTFS, pas une GPO, pas un profil corrompu. C’est le transport.

Il s’est avéré que quelqu’un avait resserré les règles entrantes sur le pare‑feu hôte lors d’un sprint de durcissement. Ils ont activé la règle RDP pour tous les profils parce que « nous avons toujours besoin du RDP », mais ont laissé « File and Printer Sharing (SMB-In) » activé seulement pour Domain et Private. Le profil NIC du serveur avait basculé en Public après un problème transitoire de connectivité au domaine au démarrage.

L’hypothèse erronée était subtile : « Si RDP fonctionne, le pare‑feu est bon. » Non. Le pare‑feu faisait son travail pour un port. Le correctif a été de corriger la cause du profil réseau (détection de domaine) et d’appliquer explicitement SMB‑In aux subnets attendus pour tous les profils pertinents, afin qu’un basculement de profil ne coupe pas l’accès aux fichiers globalement.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe réseau voulait réduire le risque de mouvement latéral. Objectif louable. Ils ont introduit un nouvel ensemble de politiques pare‑feu : « n’autoriser que les ports requis par tier. » Aussi louable. Puis ils ont voulu minimiser le nombre de règles en autorisant SMB uniquement depuis un petit ensemble de « jump hosts », supposant que les utilisateurs accéderaient aux partages via des sessions RDP.

Pendant une semaine, tout semblait réussi. Moins de ports ouverts. Diagrammes plus propres. Puis la finance a clos le mois, et des jobs batch ont commencé à échouer. Ces jobs n’étaient pas des utilisateurs interactifs pouvant faire un RDP vers une jump box. C’étaient des serveurs applicatifs tirant des rapports depuis un partage SMB avec des comptes de service. L’optimisation a discrètement cassé des workflows machine‑à‑machine en place depuis des années.

Pire, les symptômes étaient bruyants et trompeurs : certains jobs échouaient rapidement, d’autres restaient bloqués. Certains serveurs avaient des connexions en cache et continuaient de fonctionner tant bien que mal. Le monitoring indiquait le serveur de fichiers « up », et tout le monde se disputait pour savoir s’il s’agissait d’un problème de performance stockage.

Le correctif n’a pas été « ouvrir SMB partout ». Le correctif a été d’identifier les subnets clients légitimes (couche app, VDI, segment admin) et d’autoriser TCP/445 depuis ces sources uniquement, avec journalisation. Puis ils ont documenté la dépendance dans le processus de changement. L’optimisation n’a pas échoué parce que la sécurité est mauvaise ; elle a échoué parce que l’équipe a optimisé pour le nombre de ports plutôt que pour les flux de trafic connus.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre entreprise avait une habitude que j’aimerais voir copiée : chaque changement de pare‑feu pouvant impacter le trafic est‑ouest nécessitait une « check‑list de port‑probe » depuis au moins deux réseaux clients représentatifs. Pas une réunion. Une liste de commandes avec sorties sauvegardées.

Un vendredi, ils ont déployé une nouvelle politique baseline Windows. Elle touchait les règles de Windows Defender Firewall, y compris le groupe « File and Printer Sharing ». Sur le papier c’était sûr : seul le scoping « RemoteAddress » était resserré et les règles NetBIOS legacy étaient désactivées. Sensé en 2026.

Avant d’approuver, l’ingénieur a exécuté sa check‑list : Test-NetConnection vers 445 depuis le subnet VDI, depuis le subnet app, et depuis le subnet admin. Un subnet a échoué. La raison n’était pas la règle — c’était que le scoping de la règle utilisait le mauvais CIDR pour une plage VDI récemment étendue.

Aucune panne n’a eu lieu. Pas parce qu’ils étaient brillants. Parce qu’ils étaient ennuyeux et constants, et qu’ils ont testé depuis les endroits qui comptent plutôt que depuis l’endroit pratique.

Blague n°2 (courte, pertinente) : La règle de pare‑feu la plus fiable est celle que vous avez testée depuis le subnet où vivent réellement vos utilisateurs, pas depuis le subnet où votre portable est en vacances.

Corriger proprement : règles du pare‑feu Windows qui tiennent en audit

Commencez par le bon état d’esprit : « activer et restreindre », pas « désactiver »

Désactiver Windows Defender Firewall pour « voir si ça marche » est l’équivalent opérationnel de retirer les freins d’une voiture pour diagnostiquer un grincement. Oui, quelque chose change. Et maintenant vous avez créé un incident à part.

Faites plutôt ceci :

1. Assurez‑vous que le serveur écoute sur le 445 et que le service Server est en cours d’exécution.
2. Confirmez quel profil du pare‑feu est actif.
3. Activez la ou les règles entrantes appropriées pour ce profil.
4. Restreignez la règle par plages IP distantes qui représentent les clients légitimes.
5. Activez la journalisation des paquets bloqués temporairement si vous avez besoin de preuves.

Activer SMB‑In avec périmètre distant (PowerShell)

Exemple : autoriser SMB depuis votre subnet VDI et depuis votre subnet app seulement.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Enabled True"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -Profile Domain,Private,Public"

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' -RemoteAddress 10.20.0.0/16,10.50.10.0/24"

Ce que ça fait : Assure que la règle est activée, s’applique sur tous les profils (important lorsque les profils mentent), et restreint SMB entrant aux réseaux connus.

Appel opérationnel : Appliquer sur Public est acceptable seulement avec un périmètre distant strict. Si vous ne pouvez pas restreindre, corrigez le problème de profil à la place.

Vérifiez que les modifications de règle se sont réellement appliquées

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Select-Object Enabled,Profile"
True
Domain, Private, Public

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayName 'File and Printer Sharing (SMB-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
10.20.0.0/16, 10.50.10.0/24

Décision : Si RemoteAddress affiche encore Any, vous avez modifié la mauvaise règle (fréquent avec des noms localisés) ou une GPO réapplique les paramètres.

Quand la stratégie de groupe est impliquée (et c’est souvent le cas)

Si une GPO contrôle les règles du pare‑feu, les modifications locales sont du théâtre temporaire. Vous devez :

• Identifier la source de la stratégie gagnante.
• Corriger la règle au niveau de la GPO.
• Confirmer avec gpresult et les règles effectives.

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects'"
Applied Group Policy Objects
-----------------------------
Default Domain Policy
Server Firewall Baseline

Signification : « Server Firewall Baseline » impose probablement la configuration du pare‑feu.

Décision : Modifiez la GPO de baseline. Si vous appliquez un correctif local, documentez‑le comme exception temporaire et planifiez la correction de la GPO, sinon il reviendra.

Activez la journalisation du pare‑feu (de manière ciblée et temporaire)

Quand vous avez besoin de preuves, la journalisation aide. Ne la laissez pas activée en haute volumétrie indéfiniment, surtout sur des serveurs de fichiers chargés.

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed True -LogBlocked True -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 16384"

cr0x@server:~$ powershell -NoProfile -Command "Get-Content $env:systemroot\system32\LogFiles\Firewall\pfirewall.log -Tail 5"
2026-02-05 10:14:33 DROP TCP 10.20.1.55 10.20.30.40 51834 445 ...

Signification : Les drops confirment l’implication du pare‑feu ; l’IP source vous indique quel subnet doit être inclus dans le périmètre.

Décision : Si vous voyez des drops depuis des sources légitimes, mettez à jour RemoteAddress ou les ACL en amont. Si les drops proviennent de sources fantaisistes, votre pare‑feu fait son travail ; laissez‑le.

Ne « réparez » pas SMB en activant NetBIOS legacy par erreur

Si vous activez UDP/137‑138 et TCP/139 pour faire fonctionner la navigation, vous risquez de masquer un problème DNS. De plus, vous augmentez la surface d’attaque et ramenez un comportement basé sur le broadcast dans des réseaux qui n’en ont pas besoin.

Préférez : un DNS fiable, l’hébergement direct SMB sur 445, et des chemins UNC explicites.

Corriger proprement : règles du pare‑feu Linux (nftables/iptables/ufw/firewalld)

Les serveurs SMB Linux sont généralement Samba. Les clients SMB Linux sont souvent cifs‑utils, smbclient, ou des bibliothèques applicatives. Les principes de pare‑feu sont les mêmes : autoriser TCP/445 depuis les bonnes sources, garder des règles stateful correctes, et n’ouvrez pas le monde parce que quelqu’un a crié dans Slack.

nftables : autoriser SMB depuis des subnets spécifiques

L’exemple suppose une table inet filter avec une chaîne input en drop par défaut.

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft add rule inet filter input ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept

cr0x@server:~$ sudo nft list chain inet filter input
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    ip saddr 10.20.0.0/16 tcp dport 445 ct state new accept
    ip saddr 10.50.10.0/24 tcp dport 445 ct state new accept
  }
}

Signification : Les nouvelles connexions SMB sont acceptées uniquement depuis les réseaux source autorisés. Le trafic établi est autorisé par la première règle.

Décision : Si les clients timeout encore, le blocage est en amont. Si les clients se connectent mais que l’auth échoue, passez à la config Samba et aux services d’annuaire.

iptables (legacy) : même principe, syntaxe moins lisible

cr0x@server:~$ sudo iptables -A INPUT -p tcp -s 10.20.0.0/16 --dport 445 -m conntrack --ctstate NEW -j ACCEPT

cr0x@server:~$ sudo iptables -S INPUT | sed -n '1,40p'
-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -s 10.20.0.0/16 -m tcp --dport 445 -m conntrack --ctstate NEW -j ACCEPT

Signification : Drop par défaut avec accept explicite. C’est correct si vous assurez aussi l’autorisation du trafic de retour (la règle RELATED,ESTABLISHED).

Décision : Si vous avez oublié RELATED,ESTABLISHED, vous aurez un comportement étrange à sens unique qui ressemble à « SMB instable ». Corrigez‑ça d’abord.

ufw : rapide et lisible (quand vous pouvez l’utiliser)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 445 proto tcp
Rule added

cr0x@server:~$ sudo ufw status verbose
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
445/tcp                    ALLOW IN    10.20.0.0/16
22/tcp                     ALLOW IN    Anywhere

Signification : SMB autorisé depuis ce subnet seulement.

Décision : Si vous avez besoin de plusieurs subnets, ajoutez‑les explicitement. N’utilisez pas « ufw allow 445/tcp » sauf si vous entendez « depuis n’importe où ».

firewalld (RHEL‑like) : utilisez les services quand c’est sensé, les ports quand il faut être précis

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: eth0

cr0x@server:~$ sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port protocol="tcp" port="445" accept' --permanent
success

cr0x@server:~$ sudo firewall-cmd --reload
success

cr0x@server:~$ sudo firewall-cmd --zone=public --list-rich-rules
rule family="ipv4" source address="10.20.0.0/16" port port="445" protocol="tcp" accept

Signification : Autorisation scellée et ciblée dans la zone active.

Décision : Si vous ajoutez des règles dans la mauvaise zone, rien ne change. Vérifiez toujours les zones et interfaces actives d’abord.

Le réseau que vous avez oublié : NAT, VPN, proxies, IDS et middleboxes « utiles »

Pourquoi SMB est sensible aux bizarreries de chemin

SMB est stateful et attend des sessions stables. Ajoutez un VPN, un IDS agressif, ou un pare‑feu qui normalise TCP, et vous obtenez des échecs apparemment aléatoires : déconnexions intermittentes, « Le nom de réseau spécifié n’est plus disponible », ou des montages qui se bloquent sous charge.

NAT et SMB : possible, mais souvent une mauvaise idée

SMB via NAT peut fonctionner au niveau TCP, mais est couramment bloqué par politique. Le problème opérationnel majeur est que lorsque plusieurs clients semblent provenir d’une même IP NAT, le scoping serveur et l’audit deviennent moins utiles. L’authentification peut fonctionner, mais la réponse à incident devient de la danse interprétative.

Split tunneling VPN : la rupture silencieuse

Un schéma fréquent :

• RDP fonctionne car il est forcé via le VPN (ou autorisé sur Internet via une passerelle).
• SMB échoue car le split tunneling route 445 directement vers Internet, où il est bloqué (à juste titre), ou vers un point d’e‑gress différent qui n’a pas les bonnes ACL.

Corrigez les politiques de split tunneling ou publiez l’accès aux fichiers via une méthode approuvée. Ne vous opposez pas à l’équipe réseau en « ouvrant 445 vers l’extérieur ». Ce chemin mène à un rapport d’incident.

IDS/IPS et inspection SMB

Certains appliances de sécurité inspectent SMB et peuvent couper les sessions si elles détectent des violations de politique ou des anomalies. Cela peut se manifester par :

• Connexion établie, puis reset immédiat pendant la négociation.
• Copies de gros fichiers qui échouent à des tailles constantes (limites de tampon d’inspection).
• Le chiffrement SMB3 casse les hypothèses de visibilité et déclenche des blocages étranges.

Si vous suspectez cela, capturez des paquets de chaque côté de l’appliance et comparez. Ne devinez pas.

MTU et fragmentation : le cas « ça marche pour les petits fichiers »

Si vous pouvez parcourir des répertoires mais que la copie de gros fichiers échoue, suspectez des problèmes MTU/PMTUD sur VPN ou tunnels. Ce n’est pas strictement des « règles de pare‑feu », mais c’est un problème de réseau qui apparaît souvent juste après un changement de pare‑feu car les chemins ont changé.

cr0x@server:~$ ping -c 3 -M do -s 1372 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=125 time=12.3 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=125 time=12.1 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=125 time=12.2 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Signification : Le chemin supporte des paquets de 1400 octets sans fragmentation. Si cela échoue, ajustez le MTU sur les tunnels/interfaces ou autorisez l’ICMP nécessaire pour PMTUD.

Décision : Si PMTUD est cassé, vous poursuivrez la « flakiness » SMB indéfiniment. Corrigez le chemin.

Erreurs courantes : symptômes → cause profonde → correctif

1) Symptom : RDP fonctionne, SMB timeout (pas d’invite, juste en attente)

Cause profonde : TCP/445 est droppé par un pare‑feu/ACL/groupe de sécurité, souvent parce que seul RDP (3389) a été autorisé.

Correctif : Autorisez TCP/445 entrant vers le serveur de fichiers depuis les subnets approuvés. Vérifiez avec Test-NetConnection -Port 445 ou nc. Gardez le périmètre.

2) Symptom : SMB échoue seulement en utilisant le nom d’hôte ; marche via IP

Cause profonde : Problème de suffixe/ordre de recherche DNS, enregistrement DNS obsolète, ou résolution par NetBIOS/LLMNR qui ne traverse pas routeurs/VPN.

Correctif : Corrigez les enregistrements DNS et les paramètres DNS clients. Privilégiez les FQDN. Désactivez la dépendance à la découverte par broadcast entre segments.

3) Symptom : « Accès refusé » instantanément

Cause profonde : Permissions de partage/NTFS ou l’utilisateur est dirigé vers un autre serveur via DFS/alias ; parfois des identifiants en cache correspondent à un mauvais compte.

Correctif : Confirmez que vous êtes sur le serveur prévu, puis vérifiez les permissions de partage + ACL NTFS ; videz les sessions SMB en cache (net use * /delete).

4) Symptom : « Le nom de réseau spécifié n’est plus disponible » pendant la copie

Cause profonde : Middlebox qui reset, timeout d’inactivité, problèmes MTU/PMTUD, ou incompatibilité de signature/chiffrement SMB sous certaines opérations.

Correctif : Capture de paquets ; vérifiez les politiques VPN/IDS ; validez le MTU ; confirmez des politiques SMB cohérentes client/serveur.

5) Symptom : Ça marche depuis un subnet, échoue depuis un autre

Cause profonde : Périmètre distant du pare‑feu trop étroit, routes manquantes, ou routage asymétrique provoquant le drop du trafic de retour par des dispositifs stateful.

Correctif : Comparez l’IP source et le chemin. Élargissez la portée de la règle vers les subnets corrects. Corrigez la symétrie de routage ou la position du dispositif stateful.

6) Symptom : Le serveur Windows affiche le profil Public de manière inattendue

Cause profonde : Détection de domaine en échec (connectivité DNS/DC), ordre/bind des NIC, ou plusieurs NIC avec catégories réseau différentes.

Correctif : Restaurez la reachabilité DC/DNS ; assurez‑vous que la NIC correcte est utilisée pour le domaine ; appliquez des règles de pare‑feu qui ne dépendent pas uniquement du profil (avec un périmètre distant strict).

7) Symptom : Montage CIFS Linux bloqué, mais ping fonctionne

Cause profonde : Port 445 bloqué ou négociation/authentification SMB échouant ; ping est ICMP et vous dit presque rien sur la joignabilité SMB.

Correctif : Testez avec nc -vz host 445 et smbclient. Puis ajustez les règles de pare‑feu ou les options d’auth.

8) Symptom : Vous avez ouvert 445, mais ça échoue encore pour les utilisateurs du domaine

Cause profonde : Chemin d’authentification bloqué : le serveur ne peut pas atteindre un contrôleur de domaine pour Kerberos/LDAP/DNS depuis ce réseau.

Correctif : Assurez‑vous que le serveur de fichiers peut joindre les DCs sur les ports requis depuis cette interface/subnet, ou utilisez un design site/subnet approprié pour que l’authentification reste locale.

Listes de contrôle / plan pas à pas

Pas à pas : quand RDP fonctionne mais que le partage de fichiers ne fonctionne pas

1. Confirmer l’identité : Assurez‑vous que le nom que vous parcourez résout vers la même IP vers laquelle vous avez fait le RDP.
2. Tester le transport : Depuis le réseau client, testez TCP/445 vers l’IP du serveur.
3. Confirmer le service : Sur le serveur, confirmez que le port 445 écoute et que le service SMB est en cours d’exécution.
4. Confirmer le profil et la correspondance de règle : Sur Windows, vérifiez le profil actif et assurez‑vous que la règle SMB‑In est activée pour celui‑ci.
5. Restreindre l’autorisation : Définissez RemoteAddress vers les subnets clients approuvés. Évitez « Any » sauf si le serveur est déjà derrière une frontière réseau de confiance et que c’est volontaire.
6. Retester le port 445 : S’il est désormais joignable, testez la liste/le mappage SMB.
7. Tester l’auth SMB explicitement : Utilisez net use ou smbclient -L pour séparer les erreurs d’auth des erreurs de connectivité.
8. Vérifier la reachabilité DC (en environnement domaine) : Si l’auth échoue, testez DNS/Kerberos/LDAP depuis le serveur vers les DCs.
9. Ensuite seulement : Corrigez les permissions de partage et les ACL NTFS, car vous êtes maintenant au bon niveau.
10. Capturez des paquets si le comportement est incohérent : Surtout si des resets/timeouts se produisent en cours de transfert.

Checklist : qualité d’une règle de pare‑feu (la liste « ne vous humiliez pas plus tard »)

• La règle a un nom clair et un but (« Autoriser SMB depuis les subnets VDI »).
• L’autorisation entrante est restreinte par RemoteAddress (ou équivalent CIDR source).
• Seuls les ports requis sont ouverts (généralement TCP/445 ; ajoutez 139/137/138 seulement avec justification).
• La journalisation est activée temporairement lors du déploiement ou du dépannage, puis réduite.
• Les règles sont appliquées via votre système de configuration réel (GPO, Ansible, DSC), pas par des « clics » de savoir tribal.
• Les cas de test couvrent au moins deux réseaux clients réels (VDI + app subnet, ou bureau + VPN).
• Un plan de rollback existe (restaurer la politique/règle précédente) et est testé au moins en non‑prod.

Checklist : quand vous devez ouvrir SMB entre segments

• Confirmez que le segment est de confiance et monitoré.
• Utilisez le moindre privilège : seulement les serveurs de fichiers, seulement TCP/445, seulement depuis des sources spécifiques.
• Privilégiez SMB3 avec signature (et chiffrement si requis).
• Mettez en place la détection : logs pour connexions refusées et alertes pour comportement de scan.
• Documentez la dépendance (quelles applis, quels subnets, quels responsables).

FAQ

1) Si RDP fonctionne, cela ne signifie‑t‑il pas que le pare‑feu autorise le trafic ?

Cela signifie que le pare‑feu autorise une chose : TCP/3389 (ou le port utilisé par votre gateway RDP). SMB est TCP/445 et se trouve souvent sous des groupes de règles, profils et périmètres différents.

2) Quel port unique dois‑je ouvrir pour le partage de fichiers Windows ?

Souvent TCP/445. Si vous traitez du SMB NetBIOS legacy, vous pourriez aussi avoir TCP/139 et UDP/137‑138, mais traitez ceux‑ci comme des exceptions à justifier, pas comme des défauts à activer.

3) Pourquoi ça marche par IP mais pas par nom d’hôte ?

Résolution de noms. SMB peut utiliser un chemin de résolution différent de votre client RDP. Corrigez le DNS, utilisez des FQDN, et arrêtez de réactiver NetBIOS comme palliatif.

4) Dois‑je activer « File and Printer Sharing » sur le profil Public ?

Seulement si vous restreignez aussi les adresses distantes de la règle à des subnets connus et de confiance. « Public + Any » est une constatation d’audit qui vous attend.

5) J’ai ouvert 445 sur le serveur, mais les clients ne peuvent toujours pas se connecter. Et maintenant ?

Prouvez où c’est bloqué. Si le serveur ne voit jamais le SYN, c’est en amont (ACL réseau, groupe de sécurité, routage). Si le serveur voit le SYN mais ne répond pas, c’est le pare‑feu local ou le binding du service.

6) Un antivirus ou une sécurité endpoint peut‑il bloquer SMB même si le pare‑feu l’autorise ?

Oui. Certains produits endpoint incluent une inspection réseau ou des règles de « réduction de la surface d’attaque réseau » qui peuvent bloquer ou interférer avec SMB. Testez avec des captures et consultez les logs du produit.

7) Pourquoi je vois « SMB1 disabled » et dois‑je m’en inquiéter ?

Vous devriez être soulagé. SMB1 est legacy et dangereux. Le message vient généralement des outils et est informatif. Si un ancien équipement nécessite SMB1, isolez‑le et bridez‑le via le pare‑feu plutôt que de rétrograder tout votre environnement.

8) Dois‑je ouvrir des ports vers les contrôleurs de domaine pour que SMB fonctionne ?

Pas toujours, mais fréquemment. L’accès SMB authentifié en domaine dépend de Kerberos/LDAP/DNS. Si le serveur de fichiers ne peut pas joindre les DCs depuis cette interface, vous pouvez avoir des échecs d’authentification même si TCP/445 est ouvert.

9) Quelle est la manière la plus sûre d’autoriser SMB pour des utilisateurs distants ?

N’exposez pas SMB directement sur Internet. Utilisez un VPN avec un routage et des ACL appropriés, ou une passerelle d’accès aux fichiers conçue pour l’accès distant. Ensuite, limitez SMB au subnet des clients VPN et aux serveurs de fichiers.

10) Mon montage CIFS Linux échoue, mais les clients Windows fonctionnent. Est‑ce lié au pare‑feu ?

Parfois. Souvent il s’agit d’options de dialecte/signature/chiffrement SMB ou du format des identifiants. Vérifiez d’abord la connectivité TCP/445 depuis l’hôte Linux, testez avec smbclient, puis ajustez les options de montage.

Prochaines étapes que vous pouvez faire aujourd’hui

Cessez de traiter « RDP fonctionne » comme un feu vert pour tout le reste. C’est un seul point de données, et il est fréquemment le plus trompeur parce qu’il vous rend confiant.

Faites ceci ensuite :

1. Depuis un réseau client affecté, testez TCP/445 vers l’IP du serveur. Pas de passe, pas de SMB.
2. Sur le serveur, confirmez que le port 445 écoute et que le service SMB est en cours d’exécution.
3. Vérifiez le profil du pare‑feu Windows et la règle effective « File and Printer Sharing (SMB-In) ». Activez‑la si nécessaire et restreignez RemoteAddress aux subnets clients réels.
4. Si la connexion fonctionne par IP mais pas par nom, corrigez le DNS. Ne réactivez pas NetBIOS pour faire plaisir.
5. Si le transport fonctionne mais que l’auth échoue, confirmez que le serveur peut joindre les contrôleurs de domaine (DNS/Kerberos/LDAP) depuis cette interface.
6. Consignez la modification finale dans votre système de configuration (GPO/DSC/Ansible) et ajoutez un simple test de port à votre check‑list de changement.

Voilà comment corriger proprement : pas en ouvrant des ports au hasard, mais en prouvant la couche qui échoue et en ajustant la plus petite règle qui restaure le flux prévu.