Partager des fichiers depuis Linux : Samba et NFS

Samba est le logiciel libre qui fait d'un serveur Linux un serveur de fichiers Windows : il parle le protocole SMB, celui des lecteurs réseau \\serveur\partage, et peut devenir membre d'un domaine Active Directory. NFS est le système de fichiers réseau natif du monde Unix, utilisé entre serveurs Linux et par les hyperviseurs. Ce chapitre compare les deux, monte un partage Samba simple, puis un partage Samba membre du domaine avec winbind, exporte un dossier en NFS pour les sauvegardes, et remplace le vieux FTP par SFTP.

SMB ou NFS : lequel choisir

Chez Sorbier, les partages des services sont sur srv-fichiers, le serveur Windows, et le stockage de masse (machines virtuelles, sauvegardes) sur le NAS TrueNAS, qui utilise lui-même Samba et NFS. srv-partages, la petite VM Debian de ce chapitre, a deux usages précis : un partage SMB Etiquettes pour les modèles d'étiquettes de l'entrepôt, et un export NFS qui reçoit les sauvegardes des serveurs Linux. Pour une copie que même un administrateur compromis ne peut pas effacer, ces sauvegardes partent ensuite sur le NAS, protégées par des snapshots ZFS en lecture seule (snapshots ZFS, réplication et Cloud Sync).

Installer Samba

sudo apt install samba
systemctl status smbd --no-pager
smbd --version
# Version 4.22.x-Debian-4.22.x+dfsg-0+deb13u1

Le protocole SMB 1, obsolète et vulnérable (c'est par lui que s'est propagé le rançongiciel WannaCry en 2017), est désactivé par défaut depuis Samba 4.11 : ne le réactive jamais.

Un partage simple, pour une maquette

Sans domaine, Samba est un serveur autonome : il a ses propres comptes, associés à des comptes Linux. C'est la configuration d'un TP ou d'un petit site sans annuaire. Remplace /etc/samba/smb.conf (garde une copie de l'original) :

[global]
   workgroup = SORBIER
   server role = standalone server
   server min protocol = SMB3_00
   server smb encrypt = desired
   disable netbios = yes
   map to guest = never
   log file = /var/log/samba/log.%m
   max log size = 1000

[Etiquettes]
   path = /srv/samba/etiquettes
   valid users = @logistique
   read only = no
   create mask = 0660
   directory mask = 2770

Prépare le dossier, le groupe et un compte :

sudo groupadd logistique
sudo mkdir -p /srv/samba/etiquettes
sudo chown root:logistique /srv/samba/etiquettes
sudo chmod 2770 /srv/samba/etiquettes

sudo useradd -M -s /usr/sbin/nologin -G logistique ldurand   # compte Linux sans shell ni dossier personnel
sudo smbpasswd -a ldurand                                   # mot de passe Samba de ce compte

testparm -s
sudo systemctl restart smbd
sudo systemctl disable --now nmbd

Un compte Samba doit correspondre à un compte Linux, qui porte les droits sur le disque, mais ce compte n'a besoin ni de shell ni de mot de passe Linux. Teste depuis un autre Linux, puis depuis un poste Windows (\\srv-partages\Etiquettes dans l'Explorateur) :

smbclient //srv-partages.ad.sorbier.example/Etiquettes -U ldurand -c 'ls'

L'accès effectif dépend de deux contrôles, comme les permissions de partage et NTFS sous Windows : ce que smb.conf autorise (valid users, read only) et les droits Linux du dossier. Un utilisateur listé dans valid users mais sans droit d'écriture sur le dossier ne peut rien écrire.

Samba membre du domaine, avec winbind

Dans un réseau Active Directory, des comptes Samba locaux seraient une régression : les utilisateurs ont déjà un compte du domaine, avec la politique de mots de passe et les groupes. Samba devient alors membre du domaine : il authentifie les utilisateurs par Kerberos auprès des contrôleurs, et un service, winbind, traduit les comptes et les groupes de l'annuaire en comptes Linux.

1. Les paquets

sudo apt install samba winbind libnss-winbind libpam-winbind krb5-user

2. Kerberos. /etc/krb5.conf :

[libdefaults]
    default_realm = AD.SORBIER.EXAMPLE
    dns_lookup_realm = false
    dns_lookup_kdc = true

3. smb.conf :

[global]
   workgroup = SORBIER
   realm = AD.SORBIER.EXAMPLE
   security = ADS
   server min protocol = SMB3_00
   server smb encrypt = desired
   disable netbios = yes

   # Correspondance entre identifiants Windows (SID) et Linux (UID, GID)
   idmap config * : backend = tdb
   idmap config * : range = 3000-7999
   idmap config SORBIER : backend = rid
   idmap config SORBIER : range = 10000-999999

   template shell = /usr/sbin/nologin
   template homedir = /home/%U
   winbind refresh tickets = yes

   # Droits Windows (ACL) enregistrés dans les attributs étendus du disque
   vfs objects = acl_xattr
   map acl inherit = yes

[Etiquettes]
   path = /srv/samba/etiquettes
   read only = no
   valid users = @"SORBIER\GG_Logisticiens"

4. La jonction, avec un compte autorisé et l'OU des serveurs :

testparm -s
sudo net ads join -U adm1-clambert createcomputer="Sorbier/Serveurs"
# Password for [SORBIER\adm1-clambert]:
# Using short domain name -- SORBIER
# Joined 'SRV-PARTAGES' to dns domain 'ad.sorbier.example'

5. Les comptes du domaine dans Linux. Dans /etc/nsswitch.conf, ajoute winbind aux lignes passwd et group :

passwd:         files systemd winbind
group:          files systemd winbind

sudo systemctl restart winbind smbd
sudo systemctl disable --now nmbd
wbinfo -t                       # le secret partagé avec le domaine est valide
# checking the trust secret for domain SORBIER via RPC calls succeeded
wbinfo -g | grep -i logisticiens
# SORBIER\gg_logisticiens
getent group 'SORBIER\gg_logisticiens'
# SORBIER\gg_logisticiens:x:11129:SORBIER\ldurand,SORBIER\npetit

Avec le backend rid, le groupe de RID 1129 reçoit le GID 10000 + 1129 = 11129.

6. Les droits du dossier. Donne le dossier au groupe du domaine, puis affine les droits depuis Windows si besoin (onglet Sécurité, avec un compte d'administration) :

sudo chown root:'SORBIER\gg_logisticiens' /srv/samba/etiquettes
sudo chmod 2770 /srv/samba/etiquettes

Depuis un poste du domaine, l'utilisateur ouvre \\srv-partages\Etiquettes sans saisir de mot de passe : Windows présente son ticket Kerberos. Le lecteur peut être connecté par une GPO, comme ceux de srv-fichiers (cours Windows Server).

NFS : partager entre serveurs Linux

Chaque nuit, srv-glpi produit une sauvegarde de sa base et de ses fichiers (chapitre 5). Pour qu'elle ne reste pas sur le serveur sauvegardé, il l'écrit dans un dossier exporté en NFS par srv-partages, qui la copiera ensuite vers le NAS.

Sur le serveur srv-partages :

sudo apt install nfs-kernel-server
sudo groupadd -g 2001 sauvegarde
sudo useradd -u 2001 -g 2001 -M -s /usr/sbin/nologin sauvegarde
sudo mkdir -p /srv/nfs/sauvegardes/glpi
sudo chown -R sauvegarde:sauvegarde /srv/nfs/sauvegardes
sudo chmod 755 /srv/nfs/sauvegardes          # dossier parent : traversable, sinon le montage NFSv4 échoue
sudo chmod 750 /srv/nfs/sauvegardes/glpi     # le dossier exporté, réservé au compte sauvegarde

Pourquoi deux droits différents ? En NFSv4, le client parcourt les dossiers situés au-dessus de l'export avec les options par défaut : son root y devient nobody, qui doit pouvoir traverser /srv/nfs/sauvegardes. Seul le dossier exporté porte all_squash et le compte sauvegarde.

/etc/exports :

/srv/nfs/sauvegardes/glpi  192.168.10.184(rw,sync,no_subtree_check,all_squash,anonuid=2001,anongid=2001)

sudo exportfs -ra
sudo exportfs -v
# /srv/nfs/sauvegardes/glpi  192.168.10.184(sync,wdelay,hide,no_subtree_check,anonuid=2001,anongid=2001,sec=sys,rw,secure,root_squash,all_squash)

NFS (sans Kerberos) fait confiance à l'UID que le client annonce : un root du client qui serait root sur l'export pourrait tout y faire. root_squash l'empêche, et all_squash va plus loin : quoi que fasse le client, il écrit sous le compte sauvegarde, propriétaire du seul dossier exporté.

Sur le client srv-glpi :

sudo apt install nfs-common
sudo mkdir -p /mnt/sauvegardes
sudo mount -t nfs4 srv-partages.ad.sorbier.example:/srv/nfs/sauvegardes/glpi /mnt/sauvegardes
df -h /mnt/sauvegardes

Pour un montage permanent, une ligne dans /etc/fstab ; _netdev attend le réseau au démarrage, nofail évite qu'une absence de srv-partages bloque le démarrage de srv-glpi :

srv-partages.ad.sorbier.example:/srv/nfs/sauvegardes/glpi  /mnt/sauvegardes  nfs4  defaults,_netdev,nofail  0  0

sudo systemctl daemon-reload
sudo mount -a

Le pare-feu local de srv-partages n'accepte le port TCP 2049 que de 192.168.10.184 (chapitre 13).

Et le FTP ?

Le FTP envoie identifiants et fichiers en clair, et son mode de fonctionnement (une connexion de contrôle et une connexion de données sur un port négocié) complique le filtrage. Pour échanger des fichiers avec un partenaire, on utilise aujourd'hui SFTP, le transfert de fichiers d'OpenSSH, déjà installé et chiffré.

Pour un transporteur qui dépose ses bordereaux sur srv-partages, sans pouvoir ouvrir de shell ni voir le reste du serveur, ajoute à la fin de /etc/ssh/sshd_config :

Match Group sftp-partenaires
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

sudo groupadd sftp-partenaires
sudo useradd -M -s /usr/sbin/nologin -G sftp-partenaires transports-rhone
sudo mkdir -p /srv/sftp/transports-rhone/depot
sudo chown root:root /srv/sftp/transports-rhone            # la racine du chroot doit appartenir à root
sudo chmod 755 /srv/sftp/transports-rhone
sudo chown transports-rhone:transports-rhone /srv/sftp/transports-rhone/depot
sudo sshd -t && sudo systemctl reload ssh

Le partenaire se connecte avec sftp transports-rhone@… (de préférence avec une clé), arrive dans son dossier comme s'il était la racine du système, et ne peut déposer que dans depot. Si un partenaire exige vraiment du FTP, on le chiffre (FTPS, avec vsftpd et un certificat) : jamais de FTP en clair sur Internet.

Exercices