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.du...@ellis.siteparc.fr
> Le 1 déc. 2019 à 21:42, Frederic Dumas 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
