[gull] Samba SMB2 - bonnes pratiques securite ?
Frederic Dumas
f.dumas at ellis.siteparc.fr
Sun Dec 1 21:42:26 CET 2019
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.
More information about the gull
mailing list