[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