Bonjour,
Une question très simple : Est-il possible de créer un serveur de fichier accessible sur le net et sécurisé avec Samba ? J'ai besoin de mettre en place un partage pouvant être monté sur Windows10 et je connais l'utilisation de Samba en local mais je ne l'ai jamais testé "into the wild"…
Ou alors est-ce que vous conseillez plutôt sshfs sachant que l'utilisateur du partage aura besoin d'un accès "temps réel" aux fichiers (Office pour la plupart) pour pouvoir les manipuler sans les télécharger au préalable ?
J'ai bien sûr écumé le net, ai suivi l'histoire de WannaCry, mais cette faille semble corrigée dans les dernières versions. Je préfère tout de même demander l'avis des pros de DLFP… Merci d'avance pour vos conseils.
# Plutôt du Web
Posté par Adminrezo (site web personnel) . Évalué à 2.
Bonjour,
Je te déconseille d'utiliser directement CIFS pour un partage public.
Tu aurais tout intérêt à utiliser un service Web de partage de fichiers comme NextCloud, Pydio, Cozy qui, eux, écrivent leurs données en NFS ou en CIFS.
Ça te permettrais d'avoir un système accessible partout, sur tous types de supports et ça t'éviterais de mettre CIFS en frontal.
Bien sûr l'architecture est un peu plus complexe mais c'est plus propre.
[^] # Re: Plutôt du Web
Posté par Faya . Évalué à 3.
Concernant Nextcloud et Cozy, je préfère ne pas. Ça rajoute une couche de complexité (donc d'autres possibilités de failles) pour me proposer des modules qui font le café mais dont je n'aurai pas besoin. J'aurais souhaité que ce serveur ne serve que des fichiers, pas des pages web.
Par contre je vais le coupler avec un VPN comme judicieusement suggéré par NeoX ci-dessous.
# un VPN
Posté par NeoX . Évalué à 7.
le VPN c'est fait pour ca, et c'est bon, mangez en
non le VPN ne sert pas qu'à faire croire qu'on est aux US pour pouvoir regarder netflix-US depuis la France.
ton utilisateur est à l'exterieur de chez toi (ta socitété),
il se connecte en VPN à la société, il a alors acces à l'integralité des ressources de la société comme s'il etait present dans tes locaux,
y compris au serveur de fichier
[^] # Re: un VPN
Posté par Faya . Évalué à 2.
Tu as complètement raison et le pire c'est que je l'utilise déjà pour faire exactement ça : me connecter à mon réseau interne depuis l'extérieur.
Je n'y ai pas pensé dans ce cas parce que je n'utilise pas Windows donc je ne connais pas les clients VPN qui existent dessus (alors que CIFS est inclus).
Merci.
# En cas de passage par samba...
Posté par feth . Évalué à 3.
et aucune idée que samba soit pertinent, en effet, surtout avec les latences d'un accès Internet… ne pas oublier de limiter le protocole SMB aux versions > 3.1 (de mémoire), pour garantir chiffrement et authentification.
En fait, si jamais c'est samba qui est choisi, une attention toute particulière doit être apportée au suivi des rustines de sécurité.
L'idée de passer par dessus un VPN n'est pas mauvaise.
[^] # Re: En cas de passage par samba...
Posté par Faya . Évalué à 2.
Yep. Je vais encapsuler ça dans du OpenVPN.
Concernant les rustines, je me suis posé la question d'utiliser Arch plutôt que Debian :
Je l'utilise depuis plusieurs années au quotidien sur mes desktops mais j'ai toujours gardé mes serveurs sous Debian. Comme l'ont montré les 0-day de ces derniers mois, le côté bleeding edge peut être un avantage dans certains cas. Ce serveur ne fera qu'une seule chose et je préfère être au plus prêt des màj du service concerné. Le downgrading est simple et rapide en cas de casse. +J'évite les changements de version de l'OS.
Mauvaise idée ?
[^] # Re: En cas de passage par samba...
Posté par feth . Évalué à 3.
Si le VPN est obligatoire, je dirais : peu importe. Si tu dois faire la maintenance souvent, ça veut dire que tu dois couper le service, et éventuellement monter une préprod pour valider que ça fonctionne encore…
[^] # Re: En cas de passage par samba...
Posté par Faya . Évalué à 2.
Les coupures régulières et programmées pour màj ne sont pas bloquantes. Le service sera utilisé par 2 personnes (seulement) qui ne sont pas sur le même fuseau que moi donc backup+update pendant qu'ils dorment. On fonctionne déjà comme ça pour d'autres services.
Mais effectivement le VPN limite la nécessité des updates quotidiens (bien que le VPN aussi peut avoir ses 0-day…)
# SSHFS
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Techniquement, les deux peuvent convenir, puisque ce sont de vrais systèmes de fichiers par réseau, qui implémentent les fonctions de base d'accès à un fichier (open, close, read, write, seek, etc), contrairement à des émulations de système de fichier sur des protocoles de transfert comme FTP.
J'insiste sur ce point : SSHFS utilise SFTP, qui est souvent considéré comme un protocole de transfert et de manipulation de fichiers, alors qu'il s'agit réellement d'un système de fichiers par réseau, il suffit de parcourir en diagonale sa spécification pour s'en convaincre.
Maintenant, s'agissant de faire un truc sécurisé à travers Internet, je ne pense pas me tromper en affirmant qu'OpenSSH a fait ses preuves en la matière, contrairement à Samba qui, si je ne m'abuse, est plutôt conçu pour un usage en réseau local.
Donc, à mon avis, SSHFS.
# webdav
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Il y a aussi webdav qui permet de faire serveur de fichiers via Internet.
[^] # Re: webdav
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Non, WebDAV, c'est un protocole de transfert et de manipulation de fichiers qui est une extension d'HTTP. Il lui manque des fonctions pour pouvoir être un vrai système de fichiers, des trucs comme open, flock, seek, etc.
Il y a certes des pseudo-systèmes de fichiers qui permettent d'utiliser WebDAV, mais ils ne font qu'émuler les vraies fonctionnalités, en téléchargeant et en recopiant le fichier si nécessaire. Ça va se sentir pour certaines utilisations.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.