Migrer mon réseau local vers du libre

Support Debian
, , ,
Tags: #<Tag:0x00007f4e77981b70> #<Tag:0x00007f4e77981620> #<Tag:0x00007f4e77981030> #<Tag:0x00007f4e77980b58>
#1

Bonjour à tous, désolé pour le titre qui ne veut pas dire grand chose.

J’ai une question concernant la reconfiguration des services sur mon réseau local. Quelques éléments de contexte, le reseau est constitué d’une Freebox pour la passerelle vers internet, d’un NAS Synology vieillissant pour le stockage de fichiers partagés, et divers terminaux hébergeant Windows, Gnu/linux, Android, pour moi-même et toute ma tribu nombreuse… Le NAS et la box sont les deux seuls équipements allumés tout le temps, c’est pourquoi j’ai un schéma de pensée dans lequel ce sont eux qui doivent héberger les services centraux, ce qui me posera probablement quelques soucis à terme, car le Synology traine la patte en termes de rapidité, et il arrivera bien un moment où il ne sera plus supporté pour les maj de sécurité.

Jusqu’à présent, le NAS servait les fichiers partagés sur protocole CIFS, et je me pose la question de migrer progressivement sur du NFS, avec en toile de fond des interrogations du genre, dois-je prévoir pour ça de mettre en place un LDAP pour mes quelques terminaux linux (au nombre de 3 pour l’instant, mais susceptibles de monter à 5) ? Si oui, dois-je prévoir de soulager le Synology de cette tâche, peut-être en désignant une autre machine du réseau pour assumer ce rôle, qui soit réveillée à la demande (wake-on-lan, est-ce un truc de confiance pour ça ?)

Est-ce surdimensionné pour mon usage ? Quels autres éléments sont-ils à envisager, quelles autres considérations sont-elles à prendre en compte ?

Merci d’avance !

#2

Bonjour,
avec du NFS ça ne vas pas être simple pour les équipement Android, voir Windows (surtout pour les utilisateurs).

Si tu met un LDAP c’est pour les utilisateurs normalement (la gestion des comptes).
Mais tu n’en a p as plus besoin que tu n’en avais jusqu’ici.

Non, aucun service central avec du wake-on-èlan.
D’autant que le wake-on-lan n’a aucune sécurité fiable.

En fait, en service central tu n’a besoin que de deux choses (trois éventuellement):

  • Le stockage des fichiers
  • Un DNS interne qui fera un forward vers des DNS publics extérieurs (pas ta BOX car Free comme tous les FAI français est un DNS menteur). Ça te permet, d’une part de garder une gestion DNS locale hors de ta BOX, et de réaliser un lien avec des DNS public sécurisé (https par exemple). Ça te permet aussi de ne plus avoir de machine faisant des requêtes externe (et donc sniffé par ton provider), mais aussi de garantir qui a le droit de faire ces requêtes DNS (et donc de court-circuiter certains malwares).
  • Et optionnellement, de faire un serveur NTP local qui se chargera lui de se mettre à jour à l’extérieur (ce qui évite de trop nombreux accès sur un serveur NTP externe)…
#3

Très intéressant, merci.

J’ai quelques interrogations question sur le DNS interne, ce n’est pas clair pour moi. Comment faire pour qu’il soit au courant des adresses IP dynamiques données par la box ? Dois-je arrêter d’utiliser le DHCP et mettre des baux statiques sur tous les équipements ? Et surtout, comment faire en sorte que tous les terminaux l’utilisent ? Jusqu’à présent, j’imagine qu’ils utilisent par défaut la box pour le DNS car c’est elle qui fournit le wi-fi ?

Et question subsidiaire, si NFS ne convient pas trop à cause des terminaux Windows et Android, tu me préconiserais de rester en CIFS ?

#4

Le DNS d’une machine lui est donné par le DHCP, il suffit donc que tu modifie le paramètre correspondant dans le DHCP de ta BOX.
Pour la mise à jour auto, le DDNS (Dynamic DNS), je ne sais plus/pas si la box de free est capable de le faire.
Tu as alors deux choix si ce n’est pas le cas:

  1. tu configure les baux DHCP ans ta BOX en réservé (i.e.: MAC machine1 to IP1, etc…), et tu configure ton DNS manuellement. Attention ça ne marche pas avec des machines clientes dont l"'adresse MAC change automatiquement (c’est le cas de mon téléphone par exemple).
  2. La plus complexe: mettre en place ton propre serveur DHCP sur la machine centrale qui fera le DDNS sur le DNS présent sur la même machine. Et tu désactives le DHCP de la BOX. Mais c’est une architecture qui n’est pas simple à maîtriser.

Considérant le nombre de machine que tu as, la solution 1 est la plus simple, et sera largement suffisante.

Sur ton Synology tu peux partager le même répertoire en CIFS et en NFS. Et en fonction de tes machines clientes tu utilises l’un pou l’autre. Mais attention à la gestion des droits, ne fait de trucs trop compliqué sinon tu peux avoir quelques effets collatéraux.

#5

Donc en filigrane tu penses que ce serait mieux que mes terminaux Linux utilisent NFS ?

#6

oui, mais NFS v4 de préférence. Le V1 est useless en termes de sécurité

1 J'aime
#7

Un truc m’échappe.

Pour CIFS, mon poste Windows monte le partage en fournissant l’identifiant et le mot de passe d’un compte local du NAS. Au moins c’est facile, il a accès à juste ce qu’il faut, les droits étant gérés utilisateur par utilisateur sur le Synology, directement dans les permissions du système de fichiers. J’ai même mis en place un petit mécanisme de paranoïaque qui est le suivant : par défaut, les utilisateurs du Synology ont les droits en lecture seule sur le partage, et je peux (sur le NAS) au cas par cas ajouter sur un utilisateur un groupe ayant les droits en écriture, juste le temps de déposer des photos par exemple, et retirer le groupe juste après. Ce type de manip, un peu pénible c’est vrai, m’a évité de perdre toutes mes photos quand un ransomware a un jour infecté mon Windows. Le ransomware a crypté tous les documents de mon PC, puis il s’est attaqué au réseau et a crypté les films sur la Freebox, par contre sur le Synology il n’avait pas les droits en écriture, et ça m’a sauvé la mise.

Pour NFS, j’ai l’impression que j’ai le choix entre deux possibilités sur le serveur :

  • AUTH_SYS ne demande aucune preuve d’identité de l’utilisateur qui se connecte :scream:, il fait confiance au client - en espérant qu’il n’est pas compromis - pour lui donner un UID correct, et si je comprends bien c’est à moi de m’assurer dans ma conf que les UID client et serveur correspondent. Pour moi on ne peut pas faire confiance à ce fonctionnement (je pense que c’était pour cette raison que je pensais intuitivement avoir besoin d’un LDAP qui se chargerait ce certifier que les identités client et serveur sont les mêmes, mais peut-être que je me fais une fausse idée du rôle d’un LDAP).
  • Kerberos à l’inverse propose quelque chose de beaucoup plus rigoureux, mais nécessite un centre de distribution des clés (et si j’ai bien compris, c’est un truc que le Synology ne sait pas faire, ce qui veut dire mise en place d’un KDC quelque part d’autre).

Du coup je vais prendre un peu de temps pour réfléchir à tout ça, je veux absolument éviter que les partages réseau ne reposent sur une confiance aveugle en les machines, sous prétexte qu’elles sont sur le LAN.

#8

Quelle version as-tu regardé?
Il faut mettre en place la version NFSv4.

#9

La V4 : NFS(5)

Le client NFS peut choisir n’importe quel port d’origine pour ses tuyaux, mais il choisit en général un port privilégié (c’est-à-dire avec une valeur inférieure à 1024). Seul un processus tournant avec des droits du superutilisateur peut créer un tuyau à partir d’un port privilégié.

Comme décrit plus haut, le schéma d’authentification NFS traditionnel (connu sous le nom d’AUTH_SYS) compte sur l’envoi d’UID et de GID locaux pour identifier les utilisateurs à l’origine de requêtes. Un serveur NFS suppose que si une connexion provient d’un port non privilégié, les numéros UID et GID de la requête NFS ont déjà été vérifiés par le noyau du client ou tout autre programme système local. Ce système est facile à contourner, mais sur un réseau sécurisé d’ordinateurs de confiance, c’est parfaitement adapté.

Pour garder un bon niveau de sécurité tout en ouvrant un maximum de points de montage, il est préférable d’autoriser les connexions clients sur un port non privilégié seulement si le serveur et le client utilisent tous deux une authentification forte, comme celle fournie par Kerberos.

#10

utilise une connexion avec GSS. NFS traditionnel ce n’est pas la V4 en fait.
Il y a des infos là:
https://docs.redhat.com/fr/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/s1-nfs-security

#11

De ce que je comprends, AUTH_GSS = Kerberos ? J’avais déjà parcouru cette page chez Red Hat.

#12

oui.

Perso je suis resté en CIFS pour tous mes équipement, en version 3.1, avec les users définis dans Synology (j’ai un DS418).
Je synchronize avec le client Synology Drive, et sinon, j’utilise l’interface web majoritairement.

#13

Je crois que je vais rester aussi en CIFS, du moins tant que rien n’évolue dans mon archi locale. J’ai un DS411, il est un peu au bout du rouleau en termes de perfs et de fonctionnalités. Je suis bloqué en DSM 6.2 (avec les correctifs de sécurité qui arrivent de temps en temps).

Synology Drive n’est plus disponible en 6.2, alors que dans le passé j’avais une version qui s’exécutait sur DSM 5.x, quel dommage…

J’ai vu que les utilisateurs Linux étaient un peu lésés sur le client Synology Drive, ils n’ont pas accès à la fonctionnalité « file on demand » contrairement aux utilisateurs Windows et Mac, c’est un truc que j’aimerais bien mettre, un de ces quatre, car je trouvais ça très chouette dans Microsoft OneDrive. Nextcloud le propose mais je trouve la pile HTTP/Apache/PHP/MariaDB un peu lourde pour gérer un drive dont je n’utiliserai pas l’interface web.

#14

J’ai des questions de béotien STP : ton client Synology Drive n’est pas dans les paquets Debian, donc j’imagine que tu l’installes depuis un .deb téléchargé ? Je suppose que dans ces cas de figure, tout dépend du degré de confiance que tu accordes à l’éditeur ? Quelles sont les bonnes questions à se poser, et les réflexes à avoir, quand on se retrouve à devoir installer des trucs qui sortent des paquets officiels Debian ?

Je te demande ça car pour ma part, Synology Drive n’est pas compatible avec mon DS411j, je suis donc allé chercher dans les archives Synology son ancêtre, Synology Cloud Station. J’ai trouvé un package (serveur) qui s’installe bien sur le Syno, ainsi que des clients : .exe/.msi pour mon poste Windows, et .deb pour mon Debian, j’arrive donc dans un cas de figure similaire au tien.

#15

l’editeur c’est Synology.
Donc si tu n’as pas confiance dans le client, tu n’a pas plus confiance dans leur matériel que finalement tu n’achètes pas :slight_smile:

Parfait.
C’est le problème quand les équipements deviennent obsolètes.

#16

Oui, si on parle du client Syno je suis d’ac, mais ma question était plus générale, pour tout logiciel proposant un fichier .deb.

#17

j’utilise toujours les dépots Debian.
Pour les autres, soit je connais le produit, soit je connais le fournisseur.
Les autres je ne prends pas.
Typiquement, j’utilise en dépôts externe: webmin, netdata, lynis, brave-browser, Ubiquity Unifi, mongodb, opensuse pour Razer, et ISC (pour KEA, Bind9 et Stork)

1 J'aime