[gull] [Resolu] Samba SMB2 - "smb encrypt" et public share sans login

Fri Aug 6 19:07:31 CEST 2021

Pendant deux ans, j’ai laissé une configuration erronée dans un serveur Samba, qui refusait systématiquement l’accès sans mot de passe à un share pourtant public, ouvert aux invités, et donc censé ne réclamer aucun mot de passe. J’avais fini par créer un compte et un mot de passe faibles, donnés à tous, le genre de « workaround » dont on n’est pas fier.

Et voici la solution, pour qui chercherait des informations sur le web à propos du paramètre « smb encrypt ».

 - 1 - L’erreur

Dans les paramètres globaux, j’avais défini:

> smb encrypt = desired

La documentation indique qu’existent encore les paramètres « off » et « enabled » (exigence plus faible) et le paramètre « required » (exigence plus forte).

Eh bien, c’était le paramètre « desired » le coupable. Il suffit à imposer au client SMB une négociation de clés, au moins sur cette version SMB v4.7.6. Et s’il faut négocier des clés, il faut s’authentifier. Impossible donc d’accéder au partage public sans fournir un identifiant et un mot de passe.

 - 2 - La solution

Tout rentre dans l’ordre quand on abaisse le paramètre « smb encrypt »:

# Global
...
# Security context
        map to guest = bad user
        smb encrypt = enabled          <------
        server min protocol = SMB2_10

dans la configuration globale, et seulement dans les shares personnels, professionnels, etc, qui exigent l’authentification, on définit:

# Shares definition

[Public]
        ...
        public = yes
        guest only = yes
        force group = users
        writeable = yes

[Private]
        ...
        valid users = user1
        force group = group1
        writeable = yes
        smb encrypt = desired          <------

 - 3 - La morale de l'histoire

C’est comme l’oeuf de Colomb, ça parait tout simple quand on a trouvé, mais je peux vous dire que la documentation reste totalement muette sur cet effet indésirable de "smb encrypt = desired » (après tout, « desired », ça reste optionnel, ça ne devrait pas provoquer d’échec à la négociation), et qu’après des heures de lecture et de test, on abandonne comme je l’ai fait.

J’espère que cette info économisera le temps du prochain qui cherchera sur Google et tombera sur la liste de discussion du Gull...

Bonne chance à lui!

--
Frédéric Dumas
f.dumas at ellis.siteparc.fr

> Le 1 déc. 2019 à 21:42, Frederic Dumas <f.dumas at ellis.siteparc.fr> a écrit :
> 
> 
> Bon, après quelques kilo de doc, je n'ai pas trouvé beaucoup de paramètres pour imposer aux clients SMB une politique de signature et de chiffrement plus qu'une autre, dès qu'on utilise SMB2/3 et qu'on interdit toutes les versions antérieures.
> 
> J'ai l'impression qu'il y avait beaucoup plus d'options liées à la sécurité qu'il fallait paramétrer avec précision en SMB1.
> 
> 
> Si j'ai bien compris:
> 
> - le client et le serveur négocient le protocole le plus sûr
>   sur lequel il leur est possible de se mettre d'accord;
> 
> - si on utilise SMB2, les échanges peuvent être signés
>   mais ne peuvent pas être chiffrés;
> 
> - si on utilise SMB3, les échanges peuvent être signés et chiffrés,
>   mais ce n'est pas obligatoire.
> 
> 
> Donc, comme lors de la phase de négociation, le client peut imposer ses choix, et dégrader la sécurité dans l'espoir d'améliorer le taux de transfert par exemple, il y a intérêt coté serveur à ce que l'administrateur serre les boulons.
> 
> Dans un premier temps, je préfère un client SMB qui ne peut se connecter, et on va chercher pourquoi, plutôt que de voir tous les clients se connecter sans problème, certains (la plupart?) désactivant silencieusement la signature des paquets par exemple.
> 
> 
> 
> Côté options à mettre dans le fichier smb.conf [1], je n'ai trouvé que trois options utiles à ajouter.
> 
> 
> server min protocol = SMB2_10
> 
> Pour éliminer tout usage par des dialectes SMB antérieurs à Windows 7. Pas de SMB1, ça simplifie la suite du paramétrage.
> 
> 
> client signing = mandatory
> 
> Pour obliger les clients SMB à utiliser des paquets signés, c'est à dire infalsifiables pendant leur transport; j'essayerai de tester si on voit une différence sur le taux de transfert.
> 
> 
> smb encrypt = desired
> 
> Ici, difficile d'imposer le chiffrement pendant le transport, sauf à exclure tous les clients SMB que ne le supportent pas.
> 
> A priori, se sont les machines Windows 7 qui ne supportent pas le chiffrement, mais peut-être aussi des clients sous Linux, car le chiffrement n'a été ajoutée à Samba qu'à partir de la version 4.1. Samba implémente peu à peu les nouvelles fonctions, mais pas toutes d'un coup. Coté OS.X, d'après ce que j'ai lu, l'OS supporte depuis 10.10 le chiffrement [2].
> 
> 
> Deux autres options semblent ne pas devoir être explicitement ajoutées au smb.conf:
> 
> encrypt passwords = yes (activé par defaut)
> 
> server signing = mandatory (redondant avec client signing)
> 
> 
> 
> Je ne suis pas sûr pour autant d'avoir tout vu dans la doc. Si vous avez d'autres conseils, je suis preneur.
> 
> 
> Bonne semaine qui commence.
> 
> 
> 
> [1] https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
> [2] https://help.apple.com/deployment/macos/#/ior96b240d12
> 
> --
> Frederic Dumas
> f.dumas at ellis.siteparc.fr
> 
> 
> 
> 
> Le 28/11/2019 à 11:54, Frederic Dumas a écrit :
>> Bonjour à tous,
>> l'essentiel étant fait (les postes clients parviennent à se connecter au serveur Samba), la prochaine étape serait d'ajouter au fichier smb.conf les bons paramètres pour forcer les clients à se connecter avec la sécurité la plus élevée offerte par notre serveur et avec laquelle ils restent compatibles.
>> Clients: Windows 7 et Windows 10
>>          Ubuntu 18.04.x et Linux Mint 19.x
>>          OS.X 10.13.x
>> Server:  Samba 4.7.6
>> Bien sûr, les pages man, google et autre KB peuvent être mes amis, mais n'économisent jamais de faire pas mal de tests. J'ai l'espoir de gagner un jour ou deux grâce à vos bons conseils.
>> Merci.
>> Frédéric.