Discussion :

[Artemus24]

Salut à tous.

Actuellement, je me focalise sur plusieurs Ports, entre autre : 135, 137, 138, 139 et 445.
Je demande une confirmation si j'interprète bien les protocoles suivants :
1) NetBios pour les ports 137, 138 et 139.
2) Serveur message Block pour le port 445.
3) RPC (remote procedure call) pour le port 135.

J'utilise mon ordinateur pour regarder des vidéos sur ma télé Samsung.
D'après ce que j'ai pu comprendre, il s'agit du protocole DLNA (Digital Living Network Alliance).
Cela se fait au travers du "lecteur windows media", mais je n'ai pas compris quels ports sont utilisés pour cela ?
J'ai un bouton "lire sur l'appareil" qui me permet de sélectionner la vidéo à envoyer.
J'ai fait une recherche sur le net, et je n'ai pas pu découvrir le programme qui gère cela.
Dois-je comprendre qu'il s'agit du "lecteur windows media" ?

Et quel est le rapport avec SMB ?

@+

[JML19]

Bonjour

C'est une application client/serveur qui peut utiliser les ports libres au dessus de 1024.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Tu as tapé en tant qu'administrateur pour savoir

netstat -a -b

[Artemus24]

Salut JML19.

Pouvez-vous traduire vos propos car je ne comprends pas ce que vous essayez de me dire ?
A quoi ce rapporte votre commande par rapport à mon premier message ?

Au passage, j'utilise "netstat -ano" qui est plus complet.

@+

[JML19]

Salut JML19.

Pouvez-vous traduire vos propos car je ne comprends pas ce que vous essayez de me dire ?
A quoi ce rapporte votre commande par rapport à mon premier message ?

Au passage, j'utilise "netstat -ano" qui est plus complet.

@+

Cette commande sert à connaitre les ports utilisés par les applications.

[Artemus24]

Salut JML19.

Je le sais, mais ce n'est pas ma question.
Je demande plus d'explication sur les protocoles cités, ainsi que le lien qui peut exister avec SMB et par voie de conséquence WannaCry.

@+

[CTJayce]

SMB c'est en gros un protocole destiné à permettre des échanges entre les
systèmes d'exploitation sur un réseau LAN ou VPN. Les échanges se font par des
petits blocs de messages. Accessoirement, NetBios fait aussi partie de SMB
(c'est le netbios over tcp/ip dans la configuration de tcp/ip sur Windows), et
accessoirement aussi il y a plusieurs versions de SMB.

Une machine avec un SMB activé (qui utilise toujours le port 445) écoute
de manière continue le réseau en attente d'un message qui lui serait adressé.

Le problème de l'infection de Wannacry et de sa large diffusion est dû à une
double faille. Une faille client qui avait un port 445 accessible depuis
l'extérieur, donc un problème de pare-feu. En gros, l'attaquant (logiciel)
balaye des plages d'adresses IP WAN à la recherche de ports 445 en écoute, et
dès qu'il en trouve un, il envoie automatiquement un message smb particulier
(un shellcode dans le jargon) qui va générer chez le client un dépassement de
tampon, et faire exécuter le code qui va télécharger et lancer wanatruc.
Et, c'est là qu'est la deuxième faille. Un bug, une vulnérabilité dans smb qui
permettait ce dépassement de tampon et donc l'exécution de code arbitraire. Et
là, c'est la cata, une fois wanatruc dans le LAN, ben c'est comme un loup dans
un poulailler qui en plus "pond" d'autres loups. Mais je ne sais plus si les
réplications faisaient à leur tour des scans sur le WAN. Mais bon, ce genre
d'histoire, c'est répétitif dans le temps, c'est juste que là c'était, on va
dire, fulgurant.

Maintenant, qu'elle est le rapport entre SMB et DLNA ? J'ai fait une petite
recherche. Vite fait hein. Ben, je n’en vois aucun. À moins que DNLA puisse
être configuré pour utiliser SMB si uPnP n'est pas dispo, mais en temps
normal, c'est uPnP, qui est utilisé.

-> https://fr.wikipedia.org/wiki/Protocole_UPnP

Le fonctionnement semble assez simple. Le serveur logiciel Y annonce sa
présence sur le LAN un peu près de la même manière et avec les mêmes
protocoles (arp...) que ce que fait la carte réseau pour se faire enregistrer
sur le LAN. C'est pris en charge par un point de contrôle uPnP, un truc qui
centraliserait les échanges upnp dans l'enregistrement ou la demande de
recherche de services. Disons l'équivalent d'un shampoing tout-en-un (Head &
Shoulders ? Conf Évolution avec Mulder), mais à base de DHCP, DNS et HTTP. Le
logiciel client, lui, il demande où se trouve le service dont il a besoin, et
il reçoit en réponse l'adresse IP, les ports d'échanges (type: udp/tcp ,
numéros: arbitraires vraisemblablement), le protocole (http, ftp,
streaming...) et l'URL (s'il y a lieu) du serveur qui propose le service.
Ensuite, le client fait sa requête comme le ferait un navigateur à un site web
ou un client à un serveur. Apparemment, la passerelle ou le routeur, ou encore
le système qui héberge le serveur DHCP hébergerait aussi le plus souvent le
point de contrôle UPnP. Pour UPnP, voilà, j'ai fait qu'une lecture en
diagonale du lien précédent, donc c'est dans les grandes lignes quoi. Ce qui
est intéressant, c'est la flexibilité que ça semble donner, mais je n'ai pas
regardé à quel prix, dans le sens contrepartie.

[Artemus24]

Salut CTJayce.

SMB c'est en gros un protocole destiné à permettre des échanges entre les systèmes d'exploitation sur un réseau LAN ou VPN.

Les échanges de fichiers ou d'imprimantes dans un réseau local, se font au travers du protocole NetBios.
--> https://fr.wikipedia.org/wiki/NetBIOS

En ce qui concerne le VPN, cela n'a aucun rapport avec SMB et NetBios.
Le protocole utilisé est GRE. Les ports dépendent de l'utilitaire que tu utilises.
J'ai utilisé OpenVPN et les ports sont : 1194 TCP & UDP. Mais on peut en mettre un autre.

Pour le protocole SMB, c'est plus flou pour moi. J'ai parfois l'impression que cela fait double emploi avec NetBios.
Car SMB fait aussi le partage de ressources (fichiers et imprimantes) sur un réseau local.
--> https://fr.wikipedia.org/wiki/Server_Message_Block

Est-ce que je dois compendre que l'un SMB serait remplacé par NetBios ou vice-versa ?

La relation entre SMB et "SaMBa" est évidente.
C'est un serveur de fichier sous linux qui permet à des ordinateurs Windows d'y accéder.
--> https://fr.wikipedia.org/wiki/Samba_(informatique)

Il se trouve aussi qu'il existe une version de NetBios qui est encapsulée sous TCP/IP.
C'est le cas avec le serveur SAMBA qui se trouve sur ma SFR BOX NB6v2, où quand je désactive "NetBios sur TCP/IP" dans l'ordi, je n'ai plus accès à SAMBA.
Or, je me trouve dans mon réseau local, et je ne comprends pas pourquoi je suis obligé de passer par TCP/IP.

J'ai trouve ce lien :
https://superuser.com/questions/6944...etbios-and-smb
Mais je m'y perds entre tous ces protocoles !

Accessoirement, NetBios fait aussi partie de SMB (c'est le netbios over tcp/ip dans la configuration de tcp/ip sur Windows), et accessoirement aussi il y a plusieurs versions de SMB.

Il y a plusieurs versions de SMB : smbv1, smbv2 et smbv3.
Il y a plusieurs versions de NetBios, NetBui, netbios over tcp/ip

Le problème de l'infection de Wannacry et de sa large diffusion est dû à une double faille.

J'ai lu quelques articles à ce sujet, et tout ce que j'ai compris de Wanacrypt, c'est le protocole SMB : port 445.

Une faille client qui avait un port 445 accessible depuis l'extérieur, donc un problème de pare-feu.

En regardant mon pare-feu, j'ai remarqué que le port 445 était ouvert pour le flux entrant.
Heureusement pour moi, ma BOX SFR bloquait ce port.

Inversement, tous les ports sont autorisés pour le flux sortants, avec le paramétrage par défaut du pare-feu Windows.
Bonjour la sécurité !

J'ai verrouiller en entrée et en sortie dans mon pare-feu, les ports 135, 137, 138, 139 et 445 pour le réseau internet. Ils ne le sont pas pour le réseau local.
Et après test de l'ouverture des ports, je constate qu'ils sont tous fermés.

En gros, l'attaquant (logiciel) balaye des plages d'adresses IP WAN à la recherche de ports 445 en écoute, et dès qu'il en trouve un, il envoie automatiquement un message smb particulier (un shellcode dans le jargon) qui va générer chez le client un dépassement de tampon, et faire exécuter le code qui va télécharger et lancer wanatruc.

C'est quoi ce "shell code" et ce "wanatruc" ? Ce sont des outils de hackers ?

Et, c'est là qu'est la deuxième faille. Un bug, une vulnérabilité dans smb qui permettait ce dépassement de tampon et donc l'exécution de code arbitraire. Et là, c'est la cata, une fois wanatruc dans le LAN, ben c'est comme un loup dans un poulailler qui en plus "pond" d'autres loups.

Mais NetBios & SMB, sont des utilitaires développés par Windows. Ne sont-ils pas devenus obsolètes ?

Existe-t-il d'autres utilitaires bien plus sécuriés, permettant de se connecter à une imprimante ou de faire du transfert de fichiers. FTP ? SSH ?

Maintenant, qu'elle est le rapport entre SMB et DLNA ? J'ai fait une petite recherche. Vite fait hein. Ben, je n’en vois aucun.

Comme je l'ai dit, ce n'est pas clair dans ma tête.

DLNA utilise le port 7676 pour transférer des images, vidéo et musiques vers ma télé samsung. Cela se passe avec "Windows Media Player", enfin je crois.
Au départ, j'ai cru que cela se faisait avec NetBios. Et puis, je me suis dit ce que venait faire la-dedans SMB.

En gros, j'ai le voisinage réseau de Windows pour le réseau local, et j'ai cru que le transfert de données au sens le plus large, se faisait toujours avec le même protocole.
Et là, j'ai découvert qu'il y avait autant de protocole que de type de transfert : multimédia, fichiers, imprimante ...

J'ai désactivé UPnP dans ma BOX SFR, mais je peux quand même envoyer des vidéos vers ma télé samsung.
Ne serait-ce pas plutôt le service "découverte SSDP" qui gère cela ? Je parle de l'identification du périphérique.

Revenons à ma question d'origine de ce sujet.
Est-ce largement suffisant de désactiver SMBv1 pour être protégé par WannaCrypt ?
--> http://www.thewindowsclub.com/disable-smb1-windows
--> http://www.easy-pc.org/2017/05/prote...ws-10-8-7.html

Je suis allez dans le panneau de configuration, puis sous "programmes et fonctionnalités" et cliquez sur "activer ou désactiver des fonctionnalités windows".
J'ai décoché "support de partage de fichier SMB 1.0/CIFS", ainsi que "SMB Direct".

Et ensuite, désactiver tout ce qui pourrait prendre le contrôle à distance de mon ordinateur.
Bien sûr, sans que cela me gène dans l'accès à mes périphériques.

Et donc cela concerne les points suivants :
--> netbios
--> RPC
--> UpnP

Pour l'instant, je conserve DLNA au travers de "Windows Media Player".

@+

[CTJayce]

En ce qui concerne le VPN, cela n'a aucun rapport avec SMB et NetBios.
Le protocole utilisé est GRE. Les ports dépendent de l'utilitaire que tu utilises.
J'ai utilisé OpenVPN et les ports sont : 1194 TCP & UDP. Mais on peut en mettre un autre.

Pourquoi tu me parles d'un protocole VPN ? Autant me parler aussi d'un
protocole LAN. Dans mon message, il est question du réseau VPN,
qui n'est d'ailleurs qu'une autre forme de LAN. La prise en charge de smb se
fait dans les options du client vpn ou de la carte réseau virtuelle.



Pour NetBios, de mémoire, c'est encore là pour des problèmes de
rétrocompatibilités et surtout pour avoir la plus grande interopérabilité
possible. Un système ancien va tenter d'utiliser NetBios, s'il n'est pas
dispo, la communication ne pourra pas être établi. Un système récent, lui, il
va tenter d'utiliser NetBios via SMB d'abord, si pas dispo, il va tenter
NetBios (ou pas).

Samba, c'est l'implémentation SMB de Microsoft pour les Unix-like.

Dans NetBios over TCP/IP, TCP/IP c'est le camion (ou la navette) qui
transporte le colis. Le colis, c'est le message NetBios. Donc oui, si tu veux
avoir des échanges smb, tcp/ip est requis.

Dans la même veine, par exemple, juste au-dessus, là, on a parlé de vpn. Et
bien, par exemple, on peut faire du VPN over HTTP, le contenant c'est HTTP, le
contenu, c'est du VPN. Je ne monte pas jusqu'au contenant du contenant, mais
tu comprends le truc.

D'ailleurs, truc, dans Wannatruc, ça veut dire truc; et truc ça veut dire
quelque chose. Donc, on aurait un truc comme WannaQuelqueChose, autrement dit,
Wanna.*, ou encore Wanna???????. Un truc qui désigne Wannacry et ses dérivés
quoi. Ce serait comme dire je vais me schtroumpfer un café, tu vois le truc ?

Pour ssdp, c'est un composant de upnp vraisemblablement. J'ai regardé, mais
vraiment vite fait, et apparemment ça fonctionne chez toi parce que ton ton
windows media player utilise windows media connect (wmc) qui n'est autre qu'un
point de contrôle upnp et qui est disponible nativement dans windows à partir
de vista.

Qu’est ce qu'il y a encore ?

Ah, oui, la protection.

Ben là faut pas chercher midi à quatorze heures. Wannatruc (et oui), c'est pas
la première attaque sur le port 445, et ce ne sera pas la dernière. On peut
aussi imaginer des attaques sur le port ntp (network time protocol:
synchronisation de l'heure) ou un autre. En fait, une bonne protection, ce
serait de désactiver tout ce qui n'est pas utilisé ou qui n'est pas
indispensable. Les ports, les services, les programmes qui se lancent
automatiquement au démarrage, etc. Ah oui, et aussi remplacer le pare-feu de
windows par un vrai pare-feu. Un bon antivirus, c'est chiant, mais ça aide. Le
partitionnement du réseau local, au besoin.
Et cætera, et cetera, et caetera... et... etcétéra...

[Artemus24]

Salut CTJayce.

Pourquoi tu me parles d'un protocole VPN ?

Je n'ai pas associé le mot protocole au "VPN", mais à "GRE".
--> https://fr.wikipedia.org/wiki/Generi..._Encapsulation

Dans mon message, il est question du réseau VPN,

C'est comme ça que je l'ai compris aussi.
D'ailleurs VPN signifie "Virtual Private Network", soit en français "réseau privé virtuel".
--> https://fr.wikipedia.org/wiki/R%C3%A...%C3%A9_virtuel

Je ne comprends pas pourquoi vous avez cru que j'avais dit "protocole VPN" ???

La prise en charge de smb se fait dans les options du client vpn ou de la carte réseau virtuelle.

A vrai dire, vous m'apprenez quelque chose. Je ne le savais pas.

Un système récent, lui, il va tenter d'utiliser NetBios via SMB d'abord, si pas dispo, il va tenter NetBios (ou pas).

En paramétrant mon pare-feu, je suis tombé sur un cas que je n'ai pas compris.
J'ai installé une clef USB sur ma BOX SFR. J'ai configuré ma BOX dans l'onglet "Partage de fichier Windows". J'ai créé un nom de service et un nom de partage.

J'ai configuré ensuite mon ordinateur afin d'avoir accès à cet espace de partage. Cela s'écrit sous la forme "\\nom_service\nom_partage". C'est là que j'ai vu s'afficher le nom du serveur "samba 3.6.5". En temps normal, l'accès se fait bien et je peux consulter et exécuter les fichiers depuis cette clef USB.

Pour moi, il s'agit d'un accès au réseau local et non à internet. Donc toutes les déclaratives ont été faites pour le réseau local. Entre autre TCP et UDP pour les ports NETBIOS (137, 138 et 139) et le port SMB (445) qui sont ouverts pour le réseau local. A ce niveau j'accède encore à ma clef usb.

Maintenant, je crée une règle interdisant l'accès à UDP/139 mais sur le réseau internet, et je n'accède plus à ma clef usb. Dois-je comprendre que l'accès se fait obligatoirement par "netbios sur TCP/IP" ??? Or j'aimerai que l'accès se fasse obligatoirement en réseau local.

Or le problème, c'est que je croyais que l'absence de règles était bloquante pour le flux sortant. Il a donc fallu que je fasse cette interdiction pour m'apercevoir de ce problème. Et non, je n'avais pas une règle plus général englobant UDP/139.

Dans NetBios over TCP/IP, TCP/IP c'est le camion (ou la navette) qui transporte le colis. Le colis, c'est le message NetBios. Donc oui, si tu veux avoir des échanges smb, tcp/ip est requis.

A bon. C'est donc obligatoire pour accéder au serveur SAMBA de ma BOX SFR. Et je suis obligé de passer par internet et non par le réseau local. Et on ne peut pas faire autrement ?

Ce serait comme dire je vais me schtroumpfer un café, tu vois le truc ?

Je comprends mieux car j'avais pris ça au pied de la lettre.

Ah oui, et aussi remplacer le pare-feu de windows par un vrai pare-feu.

J'ai essayé COMODO et je ne l'ai pas du tout aimé. Paramétrage compliqué, impossible d'installer seulement le pare-feu, installation d'autres utilitaires dont je n'ai pas besoin ...
Des règles qui changent toutes seules, impossible d'afficher correctement les flux entrants et sortants, des blocages de traitements en local sur mon ordinateur, sans aucune raison, ...
Il y a deux niveaux de règles, dont l'une concerne les programmes et l'autre les adresses IP. Je ne suis pas arrivé à comprendre comment les configurer afin qu'ils puissent fonctionner en harmonie.

Je préfère le pare-feu Windows qui est plus simple, et fonctionne comme je l'attends.

@+

[CTJayce]

Non, non, par "d'un" je faisais bien allusion à GRE, puisque tu en as parlé.
Pour faire simple, quand tu as écrit "que VPN n'avait aucun rapport avec SMB"
tu semblais admettre que "SMB avait un rapport avec LAN", vraisemblablement,
dans les processus de connexion au réseau. D'où ma réponse.

Au passage, dans le cadre de VPN, à mon sens, GRE n'est pas représentatif et
je me demande d'ailleurs s'il n'est pas obsolète, à vérifier.

La suite de ton message n'est pas très clair, mais je vais essayer.

TCP/IP n'est pas synonyme d'internet, c'est synonyme de réseau. Pour faire
simple, on va dire, Internet, c'est le réseau WAN, et derrière ton
modem/routeur, c'est ton réseau LAN.

Toutes les adresses IP de tes machines, c'est des adresses IP privées (genre
192.168.x.x, 172.?.x.x et 10.x.x.x). Ces adresses-là ne peuvent pas sortir de
ton LAN et ne peuvent pas circuler sur le WAN. Quand tu fais une requête d'une
machine du LAN vers une autre machine du LAN, tu utilises certes TCP/IP, mais
ça ne passe pas par internet, ça reste dans le réseau LAN. Si tu débranches
ton modem de sa prise télécom, ça continuera à fonctionner.

Bon, je ne connais pas ton modem/routeur. Cela dit, normalement, et en
comportement par défaut, ta clef usb n'est pas accessible depuis l'extérieur,
depuis le WAN, car si c'était le cas ce serait une très mauvaise conception.
En fait, ton "service de partage de fichiers" là, il est hébergé sur une
machine du réseau LAN, une machine avec une adresse IP LAN, donc sauf à
mettre une règle de redirection précise au niveau des options du routeur, ou
d'une option spécifique, ta clef usb n'est accessible qu'au niveau du LAN.
Normalement, tu n'as pas besoin de bloquer ce port 139 dans les options de
filtrage des flux sortant, puisque logiquement, comme y'a pas de requête
possible depuis le WAN, y'a pas de réponse à faire de ce côté là, donc en
théorie pas de flux sortant possible vers le WAN.

Maintenant pourquoi ça te bloque au niveau du LAN ? Ben c'est juste bizarre.

J'ai fait un petit test vite fait, j'ai bloqué sur le routeur le port HTTP (80) en
sortie, voici les résultats :
. Les adresses internet HTTP ne sont pas accessibles.
. Les adresses internet en HTTPS sont accessibles.
. L’adresse HTTP de configuration du routeur est accessible.
. Les serveurs HTTP du réseau LAN sont accessibles (tout ce qu'il y a de plus
normal, quoi).
Donc, tout est normal.

Par contre lorsque j'essaye de filtrer un port en sortie, mais en l'associant
juste à l'adresse IP LAN du routeur ou de la passerelle, la règle ne passe
pas, elle n’est pas acceptée. Le Gandalf qui est dans le routeur lui dit :
«Vouuuuuuuuus nE PAsserezzzzzz PAS!!!!».

Enfin, voilà.

[Artemus24]

Salut CTJayce.

Non, non, par "d'un" je faisais bien allusion à GRE, puisque tu en as parlé.

Oui, j'ai bien parlé du protocole "GRE" pour le réseau VPN.
Et quel est le rapport entre le protocole "GRE" et le protocole "SMB" ?

Pour faire simple, quand tu as écrit "que VPN n'avait aucun rapport avec SMB" ...

Je comprends mieux le quiproquo.

Vous me parlez d'encapsulation du protocole SMB, dans le réseau VPN, ce que je ne conteste pas. Mais je ne me trouve pas dans ce contexte là !

... tu semblais admettre que "SMB avait un rapport avec LAN", vraisemblablement, dans les processus de connexion au réseau. D'où ma réponse.

Oui, enfin j'ai compris que SMB s'utilise dans un réseau Microsoft, qui lui même est le réseau local, et ne doit pas, en principe, franchir le routeur.
Je cherche à isoler les protocoles afin de mieux les gérer et aussi de mieux comprendre comment ils fonctionnent.
Comme je l'ai dit précédent, je ne suis pas certain de ce que j'affirme, mais c'est la vision que j'ai. D'où mes questions et les problèmes que je rencontre.

Au passage, dans le cadre de VPN, à mon sens, GRE n'est pas représentatif et je me demande d'ailleurs s'il n'est pas obsolète, à vérifier.

Je n'en sais rien, mais c'est une fonctionnalité présente dans ma BOX SFR.
Il semble d'après ce que je viens de lire sur le net que ce protocole soit ni sécurisé (aucun chiffrement) ni d'authentification de bout en bout.

TCP/IP n'est pas synonyme d'internet, c'est synonyme de réseau. Pour faire simple, on va dire, Internet, c'est le réseau WAN, et derrière ton modem/routeur, c'est ton réseau LAN.

Ca, je le sais, mais ce n'est pas de cela dont je parle.

C'est dans le cadre du pare-feu Windows. Que signifie dans la règle que je crée, sous l'onglet "étendue", ans la partie "adresse IP distante", la signification de "internet" ainsi que celle de "sous-réseau local" ?
Ou si vous préférez, dois-je comprendre que "sous-réseau local" correspond aux adresses :
--> 10.0.0.0/8
--> 172.16.0.0/12
--> 192.168.0.0/16
et tout ce qui est internet, c'est le reste ?
--> https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9

Avec peut-être un bémol pour l'adresse IP de la BOX SFR (192.168.1.1) ???

Quand tu fais une requête d'une machine du LAN vers une autre machine du LAN, tu utilises certes TCP/IP, mais ça ne passe pas par internet, ça reste dans le réseau LAN.

C'est ce que j'ai cru. Sauf que je tente d'accéder à ma clef USB qui se trouve dans ma BOX SFR.
Comme je l'ai dit précédemment, je tape sur mon ordinateur "\\nom_service\nom_partage". Et je pense qu'il utilise le protocole SMB.
Pourquoi ? Car dans ma BOX SFR, il s'agit du serveur SAMBA qui gère le partage des fichiers.
Or dans le pare-feu si je crée une règle d'interdiction ayant UDP (137 & 138) pour l'adresse IP distante "internet", cela ne fonctionne plus.
Et ça, je ne le comprends pas car je devrais quand même pouvoir accéder aux fichiers qui sont présents dans ma clef usb.

Si tu débranches ton modem de sa prise télécom, ça continuera à fonctionner.

Oui, j'ai fait le test et je peux continuer à accéder aux périphériques de mon réseau local, même à ma clef usb !

Bon, je ne connais pas ton modem/routeur.

Normalement toutes les box devraient fonctionner de la même façon, non ?
--> http://assistance.sfr.fr/internet-et...isque-dur.html

Cela dit, normalement, et en comportement par défaut, ta clef usb n'est pas accessible depuis l'extérieur, depuis le WAN, car si c'était le cas ce serait une très mauvaise conception.

Je ne peux pas répondre à cette question car je n'ai pas fait le test, mais je pense que vous avez raison.

Actuellement, ma clef usb n'est pas accessible depuis ma télé samsung car j'ai désactivé le serveur multimédia de ma BOX SFR.
Mais j'ai déjà testé l'accès à cette clef usb depuis ma télé samsung sans problème.

En fait, ton "service de partage de fichiers" là, il est hébergé sur une machine du réseau LAN, une machine avec une adresse IP LAN, donc sauf à mettre une règle de redirection précise au niveau des options du routeur, ou d'une option spécifique, ta clef usb n'est accessible qu'au niveau du LAN.

Non, pas sur une machine du réseau LAN, mais dans la BOX SFR. Et l'adresse IP en question est celle de la BOX SFR (192.168.1.1). Peut-être que le problème vient de là.

Normalement, tu n'as pas besoin de bloquer ce port 139 dans les options de filtrage des flux sortant, puisque logiquement, comme y'a pas de requête possible depuis le WAN, y'a pas de réponse à faire de ce côté là, donc en théorie pas de flux sortant possible vers le WAN.

Erreur de ma part, il s'agit bien du protocole UDP pour les ports 137 & 138.
Le protocole tcp est aussi interdit pour les ports 137 & 139, toujours avec l'adresse IP distant pour le réseau "internet", et il ne me pose aucun problème quant à lui.

Or précédemment, vous dites :

Dans NetBios over TCP/IP, TCP/IP c'est le camion (ou la navette) qui transporte le colis. Le colis, c'est le message NetBios. Donc oui, si tu veux avoir des échanges smb, tcp/ip est requis.

Or en lisant ce lien :
--> https://superuser.com/questions/6944...etbios-and-smb
je comprends que SMB sous windows n'a pas besoin de passer par netbios.
Si j'interdis le netbios, je ne devrais pas avoir de blocage, or ce n'est pas le cas.
Y-a-t-il un paramétrage à indiquer à windows pour dire que SMB n'a pas besoin de netbios ?

Maintenant pourquoi ça te bloque au niveau du LAN ? Ben c'est juste bizarre.

J'ai tout reconfigurer afin d'obtenir l'accès à ma clef usb. Voici les test que j'ai fait :

1) si je désactive "Netbios sur tcp/ip" (soit le service ou soit le paramètre dans la connexion réseau wifi pour TCP/IPv4), je n'ai plus accès dans le voisinage réseau à l'icône de mon ordinateur et à ma clef usb.
Les deux icônes sont dans la même subdivision du voisinage réseau sous le nom de "ordinateur".

2) si je désactive "support de partage de fichier smb 1.0/cifs" dans "activer ou désactiver des fonctionnalités windows", je n'ai plus accès à ma clef usb.

3) si j'active l'interdiction dans le pare-feu la règle USB (port 137 & 138) pour l'adresse IP distante "internet", je n'ai plus accès à ma clef usb.

Conclusion : SMB utilise bien Netbios sur TCP/IP à l'inverse du lien ci-dessus.

J'ai interrogé le service "Station de Travail" et voici ce que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
C:\WINDOWS\system32>Sc.exe qc lanmanworkstation
[SC] QueryServiceConfig réussite(s)

SERVICE_NAME: lanmanworkstation
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k NetworkService
        LOAD_ORDER_GROUP   : NetworkProvider
        TAG                : 0
        DISPLAY_NAME       : Station de travail
        DEPENDENCIES       : Bowser
                           : MRxSmb20
                           : NSI
        SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\WINDOWS\system32>

Dois-je comprendre que l'intervention de Microsoft a été de supprimer le SMB1 de station de travail ? Car seul SMB2 est activé.

@+

[Artemus24]

Salut CTJayce.

Je pense, peut-être, avoir trouvé le problème.

Dans mon dernier message, j'ai interrogé le service "station de travail".
Or comme on peut le voir, il y a une dépendance qui se nomme "mrxsmb20" et qui signifie SMBv2".

J'ai interrogé ce service "mrxsmb20, et j'ai constaté qu'il est désactivé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
C:\Users\Patron>sc query mrxsmb20

SERVICE_NAME: mrxsmb20
        TYPE               : 2  FILE_SYSTEM_DRIVER
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 1077  (0x435)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

C'est un service caché ! Je l'ai activé et j'ai redémarré mon ordinateur (c'est indispensable).

J'ai fait quelques tests en prenant le paramétrage suivant :
1) la fonctionnalité windows "support de partage de fichier SMB 1.0/CIFS" est désactivé, ainsi que "SMB Direct".
2) le service "assistance netbios sur TCP/IP" est désactivé.
3) le paramètre dans la connexion réseau wifi pour TCP/IPv4 est aussi désactivé. J'ai bien "NON" dans le détail de ma connexion wifi pour "netbios pour tcp/ip".
4) le service "station de travail" est activé. Normal car c'est le centre névralgique de SMB.
5) j'ai testé avec le pare-feu désactivé puis avec le pare-feu activé, j'ai le même résultat.

Je constate que je n'utilise pas NETBIOS. Ce qui m'arrange grandement.
Et à ma grande surprise, l'icône de mon ordinateur dans le voisinage réseau qui avait disparu, est revenu avec SMBv2.

Du coup, je comprends mieux l'article où il était question, sous forme de tableau, de la différence entre Linux et Windows.

Par contre, je n'ai pas accès à ma clef usb. C'est peut-être normal car le serveur SAMBA de ma BOX SFR est à la version 3.6.5, fort ancienne (Avril 2012).
Il se peut que nous ayons un problème de compatibilité de version entre SMB de mon ordinateur et SMB de ma BOX SFR.

N'ayant pas d'autres possibilités pour tester les accès en SMB, je ne sais pas trop si ce que j'ai fait est correcte.

@+

[CTJayce]

Attention à ne pas t'y méprendre. Une bonne partie de ta BOX fait bel et bien partie
intégrante de ton LAN.

Pour le tableau auquel tu fais référence, il concerne une ancienne version de samba.
-> https://www.samba.org/cifs/docs/what-is-smb.html

Jusqu'à la version 2.x, une communication smb via tcp/ip nécessite obligatoirement
Netbios. Pour les versions samba 3.x, ça dépend comment smb est configuré dans
le fichier smb.conf, y'a une ligne smb ports = , qui peut prendre 3 ou quatre formes,
445, 139 ou 445 139. Je ne sais pas si t'as un moyen simple d'y accéder sur ta box.
Du coup, sauf une configuration qui obligerait l'utilisation de NetBios sur TCP/IP, ta
version smb de samba est compatible avec celle de Windows.

Cela dit, si tu désactives totalement netbios sur Windows, il est peut être nécessaire
de renseigner les fichiers hosts ou lmhosts. As-tu essayé d'accéder à ton dossier de
partage avec l'adresse IP du "serveur de fichiers", genre \\192.168.x.x\nom_partage ?

Edit:

Ah oui, attention, y'a des samba 3.x qui sont vulnérables. Pense à faire une recherche
et t'assurer que tu n'es pas concerné avec ta version.

[Artemus24]

Salut CTJayce.

Plus je cherche et moins je comprends !

Pour la BOX SFR, oui, je sais qu'une partie est dédié au réseau local.
Mais comme c'est du SFR, je ne suis pas certain que cela fonctionne comme je le pense.
Entre autre, le serveur multimédia de la BOX SFR n'est pas compatible avec ma télé SAMSUNG car je n'arrive pas à lire les vidéos qui se trouve sur ma clef usb.
Et pourtant l'accès au serveur multimédia depuis ma télé est bien reconnu.
Et inversement, quand je mets ma clef usb sur ma télé, aucun problème, j'arrive à lire correctement les vidéos.

Pour le partage des fichiers, à moins de me tromper, l'accès à ma BOX SFR se fait en SMBv1.

En regardant de plus prêt ma BOX SFR, j'ai trouvé une date de révision à 2006.
Et pourtant, j'ai fait l'aquisition en localtion de cette BOX l'année dernière.

Je faisais référence à ce tableau là :

qui indique que la version SMB utilisé ne passe pas par netbios mais encapsulé par TCP/IP.

Jusqu'à la version 2.x, une communication smb via tcp/ip nécessite obligatoirement Netbios.

C'est pourquoi, j'ai fait le test avec netbios activé en désactivant le pare-feu windows.
Et je ne suis pas arrivé à lire ma clef usb sur ma BOX SFR avec la version SMBv2 alors qu'avec SMBv1 j'y arrive.

Pour les versions samba 3.x, ça dépend comment smb est configuré dans le fichier smb.conf,

Où se trouve ce fichier ? Dans la BOX SFR ou dans mon ordinateur Windows ?

J'aimerai savoir comment configurer correctement mon ordinateur pour utiliser correctement SMB ?
J'ai pourtant lu et testé ce lien
Mais ce n'est pas toujours très clair.

J'ai fait mes manipulation à partir des commandes "sc" et je me suis interessé aux services "station de travail" et "mrxsmb20".
J'ai fouillé dans la base des registres, mais je n'ai pas retrouvé les clef "SMB1", "SMB2" et "SMB3".
Je suis sous windows 10 pro, version 1607 (version du système d'exploitation 14393.1593).

Je ne sais pas si t'as un moyen simple d'y accéder sur ta box.

Je peux accéder à ma box en tant qu'administrateur, par "192.168.1.1", mais je n'ai rien vu de tel.

Sinon en passant par CURL, je peux interroger ma box, avec "smb.getInfo", sauf que cela me redonne exactement la même chose que précédemment.
Donc non, je n'ai pas le descriptif de la version SMB utilisé, ni les ports utilisés. Pour information, il s'agit du serveur SAMBA 3.6.5.

Du coup, sauf une configuration qui obligerait l'utilisation de NetBios sur TCP/IP, ta version smb de samba est compatible avec celle de Windows.

Sauf que l'on revient à la version SMBv1. Et oui, avec SMBv1, je peux accéder au partage de fichiers de ma BOX SFR.

Si j'utilise le port 445 seul, celui-ci est ouvert pour mon réseau local mais fermé pour ce qui est d'internet et cela me convient bien. C'est ce que j'ai compris.
Ce n'est pas que je n'aime pas Netbios, mais comme je l'ai dit précédemment, je me retrouve bloqué avec la règle UDP 137 & 138 pour le réseau internet alors que ces ports sont ouverts pour le réseau local.
Soit deux choses l'une, ou bien ma BOX est mal configuré pour le partage fichier (serveur SAMBA) ou bien c'est le pare-feu windows qui ne fait pas son travail correctement.
Or c'est le seul cas de figure que j'ai rencontré en manipulant le pare-feu Windows qui me pose problème (règle usb 137 & 138 internet).

Savez-vous à quoi correspond les déclaratives suivantes dans le pare-feu windows (pour les adresses IP distantes intitulés "groupe d'ordinateurs prédéfini") :
--> passerelle par défaut
--> serveurs WINS
--> serveurs DHCP
--> serveurs DNS
--> sous réseau local
--> intranet
--> réseau d'entreprise distant
--> internet
--> convertisseur lire sur

Est-ce les informations que l'on trouve en faisant "ipconfig /all" ?

Cela dit, si tu désactives totalement netbios sur Windows, il est peut être nécessaire de renseigner les fichiers hosts ou lmhosts.

Vous voulez dire dans le fichier "hosts", faire l'association entre l'adresse IP "192.168.1.1" et "boxsfr".

As-tu essayé d'accéder à ton dossier de partage avec l'adresse IP du "serveur de fichiers", genre \\192.168.x.x\nom_partage ?

Quand j'accède à ma box par l'adresse "192.168.1.1", je tombe sur le panneau d'administration de la configuration de ma box.
Sinon, je n'ai pas trouvé une autre adresse "192.168.x.x" qui pourrait remplacer "boxsfr". Peut-être qu'il fait préciser un port. Oui mais lequel ?

Ah oui, attention, y'a des samba 3.x qui sont vulnérables. Pense à faire une recherche et t'assurer que tu n'es pas concerné avec ta version.

Je n'ai pas pu trouver le moyen de connaitre la version SMB utilisé par windows. Savez-vous comment on pour faire ? Peut-être par "powershell" ?

Il me semble que vous êtes un expert en réseau, je me demande si je peux installer un serveur fichier + multimédia chez moi ?
Il devrait être composé :
--> un point d'accès WIFI qui ne sera pas relié à ma BOX SFR, pour être utilisé uniquement dans mon réseau local.
--> un serveur fichier composé de deux ou quatre disques montés en RAID.
--> un serveur multimédia compatible avec Windows 10 pro et ma smart télé SamSung.
--> pouvoir brancher aussi des clefs usb.
--> le contrôler depuis mon ordinateur.

Et surtout, le point le plus important, quels sont les protocoles et les ports utilisés ?
Par exemple, pouvoir 'connecter un lecteur réseau" sous windows.
Ou bien utiliser SSH avec Putty ou ncore FTP ?

@+

[CTJayce]

Pour ta dernière question, il faut que tu fasses une recherche sur NAS (network
attached storage) et SAN (storage area network). Comme c'est assez récurrent
comme demande, ta recherche t'amènera surement vers de bons fils de discussions.


HS:
Le fait que tu parles d'expert réseau, ça m'a fait penser à IP_Steph, et il n'y
a presque plus de traces de lui sur le forum. Je me demande si les admins (?)
de developpez l'ont "bouffé". Et il y en a plein d'autres, pointus dans d'autres
domaines qui ont disparu aussi. Je crois que je vais pas m'éterniser sur ce
forum. À part ces derniers temps, je ne postais pas énormément. Du coup,
ce sera mes derniers messages, je pense.


Pour voir le degré de vulnérabilité de ta version de samba (de ta box)
https://www.samba.org/samba/history/security.html


Ensuite, pour en revenir au sujet principal, y'a quelque chose qui va pas.
En effet, à force de retirer mes phrases de leurs paragraphes et contextes, tu
les interprètes mal et tu t'emmêles les pinceaux. Du moins, c'est ce que
laissent penser tes réponses. Par exemple, si je parle de samba (implémentation
smb pour Unix* on avait dit) ça concerne forcément ta box, et non pas windows.


Bon si je récapitule vite fait :

Toi t'es dans le cas de la version samba 3.x
Donc sauf configuration contraire, ton serveur (samba, donc sur ta box) prend
en charge le protocole smb (plein, sans netbios over tcp/ip, et sur le port
445).

Ton client, c'est windows, et c'est là que tu souhaites faire tes restrictions.
Et toi, ce que tu veux, c'est pouvoir communiquer avec ta box en n'utilisant
que le port 445.


Voilà comment je procéderais sur Windows :


1. je rétablis la configuration des protocoles smb et netbios à leurs états
d'origines, (configuration par défaut).
2. je m'assure que je peux accéder au serveur avec son nom (la clef usb)
\\nom_machine\nom_partage
---- avec un point de montage réseau
--------- connecter un lecteur réseau via l'explorateur ou
--------- commande net use .... /persistent (cf. aide en ligne, voir aussi
net view...)
3. je démonte le point de montage réseau
4. je m'assure que je peux accéder au serveur avec son IP (la clef usb)
\\192.168.x.x\nom_partage
---- avec un point de montage réseau
--------- j'essaye avec \\192.168.1.1\nom_partage, si ok je passe à l'étape 5.
--------- sinon j'identifie la bonne adresse ip qui est utilisée
(éventuellement lors d'une requête) avec un utilitaire (nbtstat, sinon netstat
ou tcpview (sysinternals) pour les plus simples).
5. je démonte le point de montage réseau basé sur l'ip.
6. je vide la table ou le cache netbios, commande nbtstat -R (paramètre
sensible à la casse)
7. je commence à mettre en place les restrictions, et après chaque petite
modification, passage à l'étape 8.
---- changement de la configuration via l'interface de la carte réseau
(désactivation de netbios sur tcp/ip, activation lmhosts ou hosts, ...),
puis plus tard, filtrage des ports netbios (en entrée et sortie) (137, 138, 139) ,
un port à la fois, sur le pare-feu, puis plus tard, désactivation des services,
mais qu'une modification à la fois.
(exemple: ... , filtrage port 137, passage étape 8, filtrage port 138, passage étape 8, ...)
8- je repasse à l'étape 4 (en utilisant la bonne adresse ip).

Dès que ça devient trop restrictif à ton gout, tu reviens une étape en arrière, et tu passes
à un autre service.

(Le rendu du paragraphe est pas terrible, désolé).

En fait, je pense qu'en désactivant totalement netbios (netbios et netbios over
tcp/ip), y'a plus de mappage automatique. Du coup, soit tu accèdes au serveur
avec son adresse IP, soit tu fais un mappage manuel dans le fichier lmhosts
(ou hosts) pour y accéder avec son nom (encore que c'est pas garanti que ça
fonctionne avec le nom si y'a plus de netbios du tout pour charger ledit
fichier). L'explorateur réseau ne fonctionnera peut-être plus et certainement
d'autres fonctionnalités encore. À voir.

[JML19]

HS:
Le fait que tu parles d'expert réseau, ça m'a fait penser à IP_Steph, et il n'y
a presque plus de traces de lui sur le forum. Je me demande si les admins (?)
de developpez l'ont "bouffé". Et il y en a plein d'autres, pointus dans d'autres
domaines qui ont disparu aussi. Je crois que je vais pas m'éterniser sur ce
forum. À part ces derniers temps, je ne postais pas énormément. Du coup,
ce sera mes derniers messages, je pense.

Bonsoir

Pourquoi faire simple, lorsque l'on peut faire compliqué !

[Artemus24]

Salut CTJayce.

Pour ta dernière question, il faut que tu fasses une recherche sur NAS (network attached storage) et SAN (storage area network).

C'est une question d'ordre général et non en particulier sur le choix d'un matériel. Autrement dit, avez-vous des conseils à me communiquer ?

Du coup, ce sera mes derniers messages, je pense.

Dommage car j'ai tant à apprendre dans le domaine des réseaux.

Par exemple, si je parle de samba (implémentation smb pour Unix* on avait dit) ça concerne forcément ta box, et non pas windows.

Oui Samba concerne ma BOX SFR, mais pour exploiter Samba, il faut aussi que Windows soit en phase sinon cela ne risque pas de fonctionner correctement.

Voilà comment je procéderais sur Windows :

C'est plus ou moins ce que j'ai déjà fait.

Quand je parle de ma clef usb, c'est l'accès au partage fichiers du serveur Samba de ma BOX SFR

Je suis parti de la version de base, à savoir :
(1) --> fonctionnalités windows : " support de partage de fichiers SMB 1.0/CIFS" activé, "SMB Direct" est toujours désactivé.
(2) --> service "assistance netbios sur tcp/ip" activé.
(3) --> service "station de travail" activé.
(4) --> connexion réseau sans fil (wifi), dans détail: "netbios sur tcp:ip" est à oui.
(5) --> un ensemble de règles d'autorisation dans le pare-feu mais sur le "sous-réseau local"
(6) --> un ensemble de règle d'interdiction dans le pare-feu sur le réseau "internet".
(7) --> "Ajouter un emplacement réseau", pour accéder par une icône à ma clef usb.

Le point (7) sert à tester l'accès à la clef usb.

a) J'accède bien à ma clef si j'ai (1), (2), (3), (4), (5).

b) si je désactive (2) ou (4), je n'ai plus d'accès à ma clef usb.
Donc nécessité d'avoir "Netbios sur TCP/IP" pour utiliser SMB.
Peut-on utiliser NetBios sans passer par TCP/IP ?
Ce point-ci n'est pas très clair. Je n'ai pas trouvé d'informations sur ce sujet.

c) Si je mets en place (6), je n'ai plus aucun accès à ma clef usb.
Le point (6) se traduit par la règle d'interdiction sur UDP 137 & 138 sur le réseau "internet.
J'ai testé seul 137 et seul 138, j'ai le même résultat, pas d'accès à la clef usb.
Ce que je ne comprends pas, c'est pourquoi j'ai ce blocage sur le réseau "internet" ?
Cela n'a aucun rapport avec le "sous-réseau local" (???) que j'utilise pour me connecter à ma BOX SFR.
Actuellement, je n'ai trouvé aucune explication.

Ce paragraphe c) est peut-être en relation avec le paragraphe b). Ou alors, c'est un bug du pare-feu Windows.

d) les accès se font nécessairement par le service "station de travail", le point (3).
Le service "MRXSMB10" (SMBv1) est désactivé et ne s'exécute pas tandis que le service "MRXSMB20" (SMBv2) est activé et s'exécute.
J'ai dû désinstaller (1). C'est ce qui est recommandé par windows pour se protéger de "WannaCrypt".
--> https://support.microsoft.com/fr-fr/...ws-and-windows

L'accès à ma clef usb ne se fait plus si je n'ai plus le point (1).
Or , ce que je ne comprends pas, j'ai accès à l'icône de mon ordinateur dans le voisinage réseau.
Cela sous-entend que SMB fonctionne, mais que je n'arrive pas à atteindre ma clef usb.
Dois-je comprendre que Samba de ma BOX SFR fonctionne avec SMBv1 ?

Pourtant, il me semble qu'ils ont rendu la version SMBv2 opérationnelle dans Samba 3.6.5.
--> https://wiki.samba.org/index.php/Rel..._for_Samba_3.6

d) j'ai recherché quelle était la version SMB utilisée lors d'un partage de fichiers.
Sur mon ordinateur, sans utilisé le réseau, j'ai testé sous PowerShell l'accès à un de mes répertoires partagés, et j'ai trouvé (dialect) 3.1.1, soit SMBv3.
Pour obtenir ce genre de résultat, il faut d'abord créer une connexion, puis sous PowerShell, lancer la commande "Get-SmbConnection".

Pour tester ma clef usb, j'ai dû revenir en SMBv1, c'est-à-dire réinstaller le point (1).
Et là, j'ai enfin la confirmation que le serveur Samba 3.6.5 de ma BOX SFR fonctionne en SMBv1, puisque le résultat de la version est (dialect) 1.5 !!!

Conclusion : en désactivant SMBv1, je ne peux plus utiliser le partage des fichiers du serveur Samba 3.6.5 de ma BOX SFR.

@+

[chrtophe]

Voici quelques explications :
Il y a 3 versions de SMB qui sont des évolutions l'une de l'autre. SMB2 a été implémenté à partir de Vista, SMB3 à partir de Wndows 8. Quand 2 machines vont tenter de communiquer, elles vont utiliser la version la plus haute possible, c'est la machine la plus ancienne qui va déterminer la version utilisée.

SMB, c'est un protocole au même titre que FTP, HTTP. servant bien entendu au partage de ressources.
NetBIOS, c'est une API qui est utilisée par le client SMB pour envoyer une commande SMB au serveur SMB. Le serveur est en écoute de commandes des clients.
NetBIOS est remplacé maintenant par TCP/IP. Il est possible d'encapsuler du NetBIOS dans TCP/IP (la trame TCP/IP va transporter une trame NetBIOS un peu comme des poupées russes). Cela s'appelle NetBIOS Over TCP/IP. Mais on a plus besoin de NetBIOS maintenant.

SAMBA est une implémentation libre de SMB utilisé dans les environnements Linux/Unix (et donc dans les BOX). Il gère les protocoles SMB1 à 3 selon la façon dont il est configuré (tu ne peux pas toucher à ce paramétrage dans ta BOX). La version 3 fonctionne en mode Workgroup, la version 4 en mode Active Directory comme celui de Windows 2000.

Si tu désactives des versions antérieures de SMB, tu ne pourras pas communiquer avec des machines les utilisant. Il te font donc connaitre la version utilisée par ta BOX. Si tu es en Windows 8 ou plus, tu peux utiliser la commande PowerShell Get-SmbConnection, sinon, il faut utiliser Wireshark.

Si tu veux te protéger de Wannacry, une mise à jour de tes systèmes suffit.

[Artemus24]

Salut à tous.

La raison de mon sujet ce porte sur les points suivants :

1) Suite à Wannacrypt, j'ai voulu en savoir un peu plus sur comment me protéger mais surtout comment fonctionne le protocole SMB.
Wannacrypt n'est pas un problème en soit pour moi car ma BOX SFR est suffisamment bien configurée pour ne pas laisser passer les flux entrants indésirables.
De plus, avant ce sujet, j'ai travaillé sur l'amélioration de mon pare-feu Windows en bloquant le flux sortant et en interdisant tout ce que je n'utilise pas.

2) Windows a soi-disant corrigé ce problème sur les ordinateurs Windows 10.
Après mes recherches sur le protocole SMB, j'ai constaté que SMBv1 était encore en activité sur mon ordinateur, même pire, SMBv2 n'était même pas activé !
Et pourtant, j'ai bien mis à jour Windows 10 à travers "Windows Update" comme cela a été préconisé.
Donc je suppose qu'il y a beaucoup d'internautes qui croient être protégés alors que ce n'est pas le cas.

3) J'ai suivi les recommandations de Windows en désactivant SMBv1 et j'ai activé SMBv2.
J'ai découvert dans ce travail, qu'il y avait un client et un serveur SMB sur mon ordinateur, ce que j'ignorais.
Mais aussi que le multimédia utilisait le protocole DNLA. Toutes mes manipulations tournaient autour du voisinage réseau.

4) En ce qui concerne le multimédia, j'ai découvert que ma BOX SFR n'est pas compatible avec ma télé Samsung plus récente.
J'ai pourtant accès au répertoire de ma BOX SFR, mais je ne peux pas lire les vidéos, images et musiques.

5) Avant la désactivation de SMBv1, j'avais accès au partage des fichiers de ma BOX SFR.
Le serveur Samba a comme version 3.6.5, et donc compatible avec SMBv2 (soi-disant).
Je me suis dit que je n'aurai donc aucun problème pour accéder à ma clef usb sur ma BOX SFR.

6) après les tests de mise en conformité de mon ordinateur au protocole SMB dans sa version 2, je n'avais plus aucun accès à ma clef usb.
Et pourtant, j'avais bien accès à l'icône de mon ordinateur, ce qui laisse supposer que SMBv2 fonctionne bien sur mon ordinateur Windows 10.
J'avais un doute sur la version SMB utilisée par ma BOX SFR. D'un coté, il semble que c'est la version 2, mais dans les fait, je n'y accède pas.
J'ai cru que j'avais mal configuré mon ordinateur.

7) j'ai rencontré le problème dans mon pare-feu, du blocage par la règle sortante netbios UDP sur les ports 137 & 138, mais sur le réseau "internet".
Normalement, je ne devrais pas avoir de blocage car ces mêmes ports sont ouverts sur le "sous-réseau local".
Sur ce point, je n'ai trouvé aucune explication.

L'adresse de ma BOX SFR est 192.168.1.1, donc aucun rapport avec le réseau internet.
Comme je suis obligé de passer par "netbios sur TCP/IP", je ne sais pas si le blocage vient de là.
Du coup, dans le pare-feu, j'ai désactivé cette règle bloquante.

8) j'ai eu quelques difficultés à comprendre d'où venait le problème de l'accès à ma clef usb de ma BOX SFR.
C'est là, que j'ai découvert que l'on pouvait interroger la version utilisée par SMB.
Et je constate que je suis en SMBv1, et plus précisément en 1.5.
Donc impossible de communiquer avec le partage des fichiers de ma BOX SFR en utilisant le protocole SMBv2.

9) Ma BOX SFR, je l'ai acquise en location en septembre de l'année dernière, donc c'est très récent.
Je ne pensais pas qu'elle était aussi vieille en terme de version. Samba 3.6.5 date de avril 2012, soit il y a déjà cinq ans.
Je ne peux pas utiliser le multimédia de ma BOX SFR car il n'est pas compatible avec ma télé Samsung bien plus récente.
Et je ne peux pas, non plus, utiliser le partage des fichiers de ma BOX SFR car celui-ci supporte que SMBv1.

10) j'ai, par ce sujet, appris à utiliser le protocole SMB et à bien le configurer sur mon ordinateur.
Il reste des questions en suspend comme ce blocage de la règle sortante dans le pare-feu Windows.
Ou encore le fait de passer à SMBv2 suffit-il à se protéger correctement contre Wannacrypt.

SMB, c'est un protocole au même titre que FTP, HTTP. servant bien entendu au partage de ressources.

Par exactement, car SMB est un protocole propriétaire du réseau local Microsoft.
Les autres protocoles FTP, HTTP, sont destinés au réseau internet (WAN) et peuvent passer la barrière du routeur.

NetBIOS, c'est une API qui est utilisée par le client SMB pour envoyer une commande SMB au serveur SMB.

Peut-être, mais j'ai compris que SMB n'avait plus besoin d'utiliser Netbios.
C'est pourquoi, je n'ai pas compris mon blocage dans le pare-feu.
Et je n'ai besoin que d'avoir accès au serveur fichiers dans mon réseau local, pas ailleurs.

Mais on a plus besoin de NetBIOS maintenant.

Alors pourquoi si je désactive Netbios, même en ayant SMBv2, je n'accède plus à l'icône de mon ordinateur dans le voisinage réseau ?
Pouvez-vous me renseigner sur comment paramétrer correctement mon ordinateur ?

Pour l'instant, je ne peux pas faire autrement que d'utiliser Netbios.

tu ne peux pas toucher à ce paramétrage dans ta BOX

Oui et non.

Non car c'est du matériel en location et donc il m'est interdit de bidouiller dedans.
Et oui, car il existe des API qui peuvent mettre à jour la BOX SFR.

La version 3 fonctionne en mode Workgroup, la version 4 en mode Active Directory comme celui de Windows 2000.

Parlez-vous des versions 3 & 4 de SAMBA ?

Si tu désactives des versions antérieures de SMB, tu ne pourras pas communiquer avec des machines les utilisant.

Fallait-il encore savoir que ma BOX SFR fonctionnait encore en SMBv1 sur du matériel récent.

Si tu veux te protéger de Wannacry, une mise à jour de tes systèmes suffit.

Non ! Comme je l'ai dit plus haut, la mise à jour n'est pas suffisante.
Encore que j'ignore en quoi consiste le patch de correction de Windows sur ce problème.
Pour ce protéger contre Wannacrypt, il faut désactiver SMBv1 dans le serveur et le client (MRXSMB10) SMB de l'ordinateur.
Tout est indique dans ce sujet.

@+

[chrtophe]

La box SFR comporte une vielle version de Samba.

Je pense que SMBv1 nécessite Netbios.

Par exactement, car SMB est un protocole propriétaire du réseau local Microsoft.

Ca reste un protocole comme FTP, HTTP comme je l'ai dis, défini par les RFC :

https://www.icir.org/gregor/tools/ms-smb-protocols.html

Non ! Comme je l'ai dit plus haut, la mise à jour n'est pas suffisante.

Je me suis mal exprimé. Le virus se choppe par mail, et une fois que tu l'as ce répend sur le réseau interne via une faille SMB. C'est elle qui est corrigée par les patchs.