Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)

  • État En attente de réponse
  • Type de tâche Anomalie
  • Catégorie LAN
  • Assignée à Personne
  • Système d'exploitation Freebox Server V7 (Delta)
  • Sévérité Moyenne
  • Priorité Normale
  • Basée sur la version 4.3.2
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
Concerne le projet: Freebox Server (Pop V8/ Delta V7 / Revolution V6 / Server Mini 4K)
Ouverte par D.-C.M. (Freemagician) - 30/05/2021
Dernière édition par Marios Makassikis (mmakassikis) - 03/06/2021

FS#34944 - SMBv2 - Suppression du SMB1 et Modification non sollicitée des noms de partage (changement de casse)

1) Suppression du protocol SMB1

L’activation du SMBv2 rend inactif le SMBv1 contrairement à ce qui était sous entendu sur la page principale de votre site, sauf si j’ai mal compris.

J’ai personnellement encore certains zinzins qui ne se connectent qu’en SMBv1, alors que Windows 10 et Linux réclament le SMBv2 par défaut, mais bon.... je ne dois pas être un cas commun. Outre les problèmes de sécurité du SMB1, le SMB2/3 est quand même plus performant, d’où l’intérêt que j’aurais à mixer les protocoles.

En fait j’ignore si l’activation simultanée des 3 protocoles est vraiment possible, je n’ai pas encore fait de test approfondi sur mes systèmes, mais j’avais cru voir dans la doc “Samba” les paramètres min et max protocol de /etc/samba/smb.conf

Donc si on place

min protocol = SMB1
max protocol = SMB3

Théoriquement le serveur pourrait accepter l’authentifcation cumulée selon les 3 protocoles..... sous réserve de tests. Peut-être que le cumule n’est possible que sur les deux derniers protocoles...

Dans tous les cas, ça pose un souci.
Pour des raisons de sécurité certaines personnes ne veulent absolument plus que le serveur serve le protocole SMB1 (c’est juste moi qui suis dans un cas particulier et j’assume le risque qui va avec), donc placer min protocol à SMB2 semble répondre à la demande majoritaire.

Pour résoudre le problème des gens qui pour certaines raisons ont besoin des protocoles cumulés 1, 2, 3 ça implique donc que l’interface Freebox OS soit modifiée.

La Freebox par défaut active les protocoles 2/3 et on a une case à cocher SMB1, qui permet explicitement d’activer le SMB1 EN PLUS (avec un petit écran d’avertissement sur les problèmes de sécurité induits) si tant est que le cumul des 3 protocoles est vraiment possible.

Bien entendu, lors de la mise à jour, pour ne pas disturber les utilisateurs la case SMB1 est automatiquement cochée si un serveur est déjà paramétré selon ce protocole, mais pour les nouveaux clients, la box doit décocher par défaut le SMB1 et activer par défaut SMB2 / SMB3

2) Modification des noms de partage

Lorsque l’on active le SMBv2, il semblerait que le serveur Samba de Freebox OS modifie les noms de partage contenant des majuscules en passant tout en minuscule. Si ce n’est pas en soit critique, c’est ennuyeux car ça implique de modifier tous les informations d’identification au niveau des clients.

Dans les standards Windows, contrairement à Linux, les minuscules et majuscules sont discriminantes par défaut. En revanche je ne sais pas ce qu’il advient des caractères accentués... en effet, dans l’univers Windows l’utilisation de noms de partages contenant des caractères accentués est monnaie courante, contrairement au monde Linux.

Il faut donc s’attendre à ce qu’un nombre important de réclamations alléguant l’impossibilté de se connecter viennent d’un changement de casse.

Normalement c’est un simple paramètres dans Samba qui indique si minuscules et majuscules sont discriminantes.
Du reste, il suffit de revenir en SMB1 et comme par magie tout revient en ordre.

NB : Pour rappel la fameuse faille de sécurité ne conduit pas directement à un black out du PC. Le virus par définition doit être activée sur un poste client via par exemple une pièce jointes d’un email, et le virus s’il détecte la présence de serveurs Samba SMB1 va exploter la faille pour se diffuser à travers tout le réseau. Le risque est donc essentiellement pour les entreprises qui peuvent voir tous les postes de l’entreprise progressivement infectés

Cette tache ne dépend pas d'autre tache

Marios Makassikis (mmakassikis)
lundi 31 mai, 2021 08:20:39

Bonjour,

Lorsque SMBv2 est activé, la version du protocole utilisée dépend de ce que négocie le client. Un client SMB1 devrait être en mesure de se connecter même si SMB2 est activé. Le firmware précédent (4.3.2) contenait une régression sur l’authentification des clients SMB1 qui rendait la connexion impossible. Est-ce que vous rencontrez aujourd’hui un problème de connexion avec des clients SMB1 ? Pouvez-vous m’indiquer plus d’informations sur les clients ?

Pouvez-vous également m’indiquer sur quel(s) système(s) vous rencontrez un problème avec la casse ? Est-ce qu’un code d’erreur est remonté ?

D.-C.M. (Freemagician)
vendredi 11 juin, 2021 18:28:35

Sous Opensuse, j’ai un script qui dérive d’un script standard fourni avec les distro Linux qui permet à AUTOFS de découvrir des partages SMB et de se connecter automatiquement lorsque je me déplace avec un explorateur de fichiers.

Lorsque j’entre dans le serveur Freebox, le système liste les partages mais passe tout en minuscule.
L’explorateur d’un poste Windows 10 confirme bien le passage des noms de partage en minuscule, il ne s’agit donc pas d’un problème spécifique à Linux ou d’un problème de script

En revanche ça ne pose pas de souci de connexion tant sous Windows que sous OpenSUSE, le seul problème est que ça fout en l’air certains de mes scripts bash qui cherchent des fichiers de config sur le serveur Samba de la Freebox qui sert de dépôt pour une bibliothèque de scripts et fichiers de configurations partagées.

J’ai forcé les paramètres en appliquant vers=1.0 et OpenSUSE semble bien se connecte, confirmé par la commande ‘mount -l’ qui renvoie le paramètre vers=1.0
Donc OpenSUSE se connecte sous les deux protocoles

En fait j’ai un souci avec des postes FreeBSD.... lui ne connait que le SMB1 et les dévs de FreeBSD en ont rien à cirer de Samba, donc on n’est pas près de voir débarquer une évolution du kernel. Lorsque la Freebox passe en multiprotocol SMB2, quelque chose ne lui plait pas (j’ai bien sûr tenté les deux connexion sur noms de partages en majuscules et noms de partage en minuscules)

Vu le nombre très réduit de gens qui utilisent FreeBSD, je pense que vous n’allez pas perdre votre temps avec cela.
Sous FreeBSD la solution est de passer par le paquet SMBNETFS qui exploite la librairie officielle libsmbclient incluse dans le serveur Samba.
Le seul souci est que lorsque l’OS est sous maintenance, comme lors d’un upgrade de version, ces fameux paquets ne sont pas forcément actif, d’où l’intérêt de se connecter en SMB via le kernel plutôt que via une application issue d’une paquet tiers.

Pour FreeBSD j’ai l’impression que lorsque le client fait une tentative de connexion, il n’informe pas le serveur de la version de protocole qu’il initie, donc à mon avis le serveur de la Freebox réclame par défaut du SMB2 ou SMB3

Je ne suis par certain qu’il y ait de solution car par définition à l’époque du développement de ce morceau de kernel, le SMB2 ou SMB3 n’existaientt pas, donc il n’y a pas comme dans le kernel Linux une option du type ‘vers=’

En revanche il faudrait se concentrer sur ce problème de changement de casse... sous Windows c’est clairement visible

D.-C.M. (Freemagician)
vendredi 11 juin, 2021 19:10:45

Eventuellement...

Il y a peut-être dans les paramètres Samba un paramètre qui définit le protocole par défaut qu’il faudrait passer à SMB1 pour assurer la plus grande compatibilité possible, notamment avec d’anciennes appliances sorties à des moments où SMB2 n’existait même pas.

Mais la solution la plus “safe” est d’inverser la présentation par rapport à la situation courante

- min protocol SMB2
- max protocol SMB3

Par défaut, et si l’utilisateur coche la case SMB1, on passe à min protocol SMB1 et Default protocol (ou un truc du genre) SMB1, avec un petit message d’information sur la sécurité

Chargement...