CIFS TCP port : le 445 et le 139 pour des partages de fichiers qui tiennent la route

Le CIFS TCP port revient tout le temps sur la table quand on conçoit ou qu’on sécurise un réseau informatique avec du partage de fichiers. Que ce soit pour relier des postes Windows à un serveur de fichiers, faire cohabiter des environnements mixtes ou simplement autoriser un accès propre entre machines, il faut savoir exactement quels ports TCP sont concernés. Aujourd’hui le 445 s’est imposé comme la référence, mais le 139 n’a pas disparu du jour au lendemain. La différence entre les deux change pas mal la façon dont on configure pare-feu, résolution de noms et sécurité globale.

Comment on est passé du NetBIOS au port 445 direct

Au départ, le SMB – dont le CIFS n’est qu’une appellation historique ou un dialecte ancien selon les contextes – s’appuyait sur NetBIOS over TCP/IP. Ça voulait dire plusieurs ports en jeu : l’UDP 137 pour les noms, l’UDP 138 pour les datagrammes et surtout le TCP 139 pour les sessions de partage proprement dites. Le système marchait, mais il traînait des diffusions NetBIOS, parfois un WINS à maintenir, et une couche supplémentaire qui compliquait tout.

Microsoft a fait évoluer les choses dès Windows 2000 en permettant au SMB de tourner directement sur TCP/IP sans passer par NetBIOS. Le port 445 est né de ce choix. À partir de Windows Vista et Server 2008 avec SMB 2, l’hébergement direct est devenu la norme. Un en-tête tout simple de quatre octets (0x00 suivi de la longueur) précède les données SMB, et le reste circule sans la surcharge ancienne. Résultat : moins de trafic broadcast, résolution de noms via DNS classique, et une architecture globalement plus propre.

Windows garde quand même les deux mécanismes en parallèle pour la compatibilité. Il tente les deux et garde la première réponse qui arrive. C’est pratique pour ne pas casser les vieux systèmes, mais ça veut aussi dire qu’il faut parfois forcer la main si on veut du 445 pur.

Pourquoi le port TCP 445 est devenu le standard pour CIFS

Dans la plupart des réseaux d’entreprise actuels, le CIFS TCP port à ouvrir en priorité est le 445. C’est sur ce port que les serveurs Windows récents écoutent pour les connexions SMB directes. Les clients modernes font de même. Si tes machines résolvent correctement via DNS et que tu accèdes par nom FQDN ou par IP, le 445 suffit dans l’immense majorité des cas.

L’avantage est concret : configuration de pare-feu plus simple, moins de dépendances, et de meilleures performances globales avec les versions récentes de SMB. Quand on désactive NetBIOS sur TCP/IP dans les propriétés de la carte réseau (onglet WINS), on force cette voie directe et on gagne en lisibilité. Microsoft le recommande depuis des années pour simplifier et durcir les environnements.

Évidemment, tout n’est pas parfait. Si un client très ancien essaie de se connecter, il peut tomber en échec si le 139 n’est pas disponible. Mais dans un parc raisonnablement maintenu, ce cas devient rare.

Le port 139 : relique ou encore nécessaire pour certains CIFS TCP port ?

Le port 139 reste le port historique des sessions SMB via NetBIOS. Il est encore utile quand on doit garder la compatibilité avec des systèmes pré-Windows 2000, certains vieux NAS ou des applications qui n’ont jamais migré vers l’hébergement direct. Dans ces situations précises, ouvrir le TCP 139 en plus du 445 permet aux partages de fonctionner sans surprise.

Cela dit, dans un réseau neuf ou bien entretenu, je préfère clairement le fermer quand c’est possible. Ça réduit la surface d’attaque et évite d’avoir deux chemins pour le même service. Le test est simple : on désactive NetBIOS sur les interfaces serveurs et clientes, on vérifie que les partages répondent toujours via le 445, et on mesure si tout le monde est content. La plupart du temps, oui.

Configurer les pare-feu pour le trafic CIFS sans se prendre la tête

Que ce soit le pare-feu Windows Defender ou un équipement tiers, la règle reste la même : autoriser le TCP 445 entrant vers les serveurs de partage depuis les plages d’adresses internes de confiance. Si la compatibilité legacy l’exige vraiment, on ajoute le 139 en TCP. Rien de plus, rien de moins pour du partage de fichiers et d’imprimantes basique.

Le port 135 TCP pour RPC traîne souvent dans le décor quand on est en domaine Active Directory, mais pour du pur CIFS/SMB file share il n’est pas systématiquement requis. L’important reste de bloquer tout ça depuis l’extérieur. Ouvrir le 445 sur internet, c’est rarement une bonne idée.

Sécurité : ce que le port 445 nous a appris sur les risques réels

Le port 445 est devenu un point d’entrée très surveillé, et pour cause. L’épisode WannaCry a montré comment une faille dans une vieille version de SMB pouvait se propager rapidement à travers des ports ouverts. La leçon reste valable : on désactive SMBv1 partout où c’est encore activé, on applique les correctifs sans attendre, et on segmente le réseau pour que seules les machines qui ont vraiment besoin de parler à un serveur de fichiers puissent le faire.

Dans la pratique, je croise encore trop souvent des règles trop larges qui autorisent le 445 depuis n’importe où dans le VLAN. Le principe du moindre privilège s’applique ici comme ailleurs : on limite par IP ou par groupe, on surveille ce qui écoute réellement avec netstat ou des outils équivalents, et on privilégie un VPN pour tout accès distant plutôt que d’exposer le port directement.

Cas concrets : Windows, Samba et environnements mixtes

Sur un Windows Server récent, le service Partage de fichiers et d’imprimantes active principalement l’écoute sur le 445. Une commande rapide comme net config server permet de vérifier les liaisons actives. Côté Linux avec Samba, c’est identique par défaut : le démon smbd écoute sur 445, et les clients mount.cifs ou smbclient ciblent ce port sauf configuration explicite.

Dans un environnement hybride, la stratégie la plus robuste reste de standardiser sur l’hébergement direct TCP 445 et de désactiver NetBIOS là où c’est supporté. On gagne en prévisibilité, en facilité de dépannage et en surface d’attaque réduite. Les vieux cas qui exigent encore le 139 deviennent l’exception qu’on traite au cas par cas plutôt que la règle par défaut.

Au bout du compte, pour des réseaux informatiques qui doivent rester fiables, performants et sécurisés, le CIFS TCP port à privilégier est le 445. Le 139 reste une option de compatibilité legacy qu’on garde sous le coude, pas le choix par défaut. En appliquant cette logique simple, on évite bien des maux de tête tout en gardant les partages qui tournent sans accroc.