Auto-hébergement et NAS

[pluton212+]

Bonjour,

que pensez vous de cet article vu sur:

linuxfr.org ?

Merci pour vos commentaires.

 

"Auto-hébergement et NAS

Sécurité: moyen
Simplicité: excellent
Fonctionnalités: bon, mais…

Les NAS "physiques" (comprendre: Synology, QNAP, etc.) offrent généralement un système de paquets logiciels permettant d'étendre leurs fonctionnalités: serveur web, serveur multimédia, serveur mail, etc. Cela permet de grandement simplifier leur installation bien sûr, mais au détriment - généralement - de leur "paramétrabilité".

Quand on a un accès root au système sous-jacent, les manques sont rapidement comblés par les connaisseurs. Quant aux utilisateurs lambda, ils utilisent ce qu'ils ont sous la main.

Le problème avec les NAS concerne surtout leur niveau de sécurité. Plus exactement, leur niveau de sécurité dépend de la réactivité des constructeurs à sortir des mises à jour en cas de problème. L'actualité récente (HeartBleed, ShellShock, etc.) nous a montré - si besoin était encore - que les systèmes fermés contraignent les utilisateurs à attendre que les constructeurs sortent des correctifs. Un paradigme insupportable pour les défenseurs du Libre, à juste titre puisque cela affecte la sécurité et la confidentialité des données. Cela soulève donc la question de la confiance que l'on choisi d'accorder à un système de stockage de données qui contiendra - a fortiori - des données privées. Autrement dit, confier ses données à un NAS dont le système n'est pas (totalement) libre serait équivalent à confier ses données à un hébergeur dans le cloud.

Au final, les NAS offrent une grande simplicité (l'installation peut se faire en un gros quart d'heure), au détriment des fonctionnalités et surtout de la sécurité. Je ne crois pas qu'il s'agisse d'une bonne solution pour faire de l'auto-hébergement à cause de ça. Quand on veut s'auto-héberger, c'est pour contrôler le stockage, et donc avoir confiance dans son système de stockage."

[Fenrir]

En premier lieu, cet article commence à dater.

Il aurait été intéressant que tu indiques ton point de vu sur l'article, à défaut voici le mien.

En version courte :

• sécurité : si votre modèle de menace se limite aux scripts-kiddies ou aux bot, un Synology correctement configuré (et sauvegardé !!!) sera bien largement assez sécurisé pour faire de l'auto hébergement
  • en tout cas très probablement plus qu'un système monté à la main par un non spécialiste
  • si votre modèle de menace inclut des états ou des groupes criminels, vous vous trompez de débat
• simplicité : même en étant spécialiste de l'auto hébergement, une personne seule ne pourra pas rivaliser
• fonctionnalités : si le syno ne suffit pas, rien ne vous empêche de lui adjoindre un compagnon (un rpi par exemple), il se sentira moins seul

---

En version longue

L'article se veut assez objectif dans l'ensemble (il faut lire au delà de ton extrait), mais certains points me semblent exagérés, d'autres sont faux.

Citation

la réactivité des constructeurs à sortir des mises à jour en cas de problème

Vrai mais Synology fait plutôt parti des bons élèves sur ce point.

Citation

L'actualité récente (HeartBleed, ShellShock, etc.) nous a montré - si besoin était encore - que les systèmes fermés contraignent les utilisateurs à attendre que les constructeurs sortent des correctifs

Vrai mais les utilisateurs de distrib Linux ont aussi du attendre que les éditeurs fassent de même, certes ça peut aller très vite (quelques heures pour HeartBleed), mais ça peut aussi prendre bien plus de temps => dans un cas comme dans l'autre, sauf à être à la source, on reste dépendant d'un ou plusieurs intermédiaires => c'est une histoire de confiance

Citation

confier ses données à un NAS dont le système n'est pas (totalement) libre serait équivalent à confier ses données à un hébergeur dans le cloud.

Faux : en premier lieu rien ne nous oblige à rendre le NAS accessible depuis n'importe où, de plus on en contrôle les accès physique et logiques (certains pourront dire que le nas peut contenir une backdoor ou envoyer des données sur le net, un bon firewall est c'est réglé dans 99.999% des cas) enfin le jour où votre hébergeur en ligne dira - "pour accéder à vos nos c'est 10€ par Go (ou mois) maintenant" - vous ferez quoi ?

<spoil>certains l'on déjà fait (amazon, google, apple, ...)</spoil>

Citation

Au final, les NAS offrent une grande simplicité (l'installation peut se faire en un gros quart d'heure), au détriment des fonctionnalités et surtout de la sécurité.

Je ne suis pas d'accord.

Pour les fonctionnalités, la charge de travail pour arriver à faire un système approchant ce qui est intégré à un NAS est tout simplement inatteignable pour un particulier (même très compétent). Il ne faut pas oublier qu'en face c'est une entreprise avec des dizaines/centaines de développeurs, administrateurs, graphistes, ...

Un truc tout bête, mettre en place un équivalent à SHR est déjà hors de portée de la quasi totalités des utilisateurs. Faire en sorte que toutes les applications soient en SSO est encore plus complexe.

Pour l'aspect sécurité, j'aurai plus confiance en un nas pas mis à jour depuis 5 ans qu'en un serveur applicatif monté la veille par un amateur. Installer un OS de manière sécurisée est relativement simple, il suffit de partir sur une bonne base (OpenBSD par exemple, ou Debian ou encore CentOS), mais à dès qu'on commence à y ajouter des applications, à modifier la configuration (qui a dit 777) et à l'ouvrir au monde extérieur, les choses se gâtent.

Sécuriser correctement (je ne parle même pas de NSAproof, juste d'anti scripts kiddies) un système et ses applications c'est un métier à plein temps qui nécessite des connaissances très variées et très pointues.

Certains diront qu'on trouve plein de tuto qui expliquent tout (c'est partiellement vrai), qu'ils ont bloqué l'authentification par mot de passe en ssh (c'est bien, mais vous avez aussi changés les ciphers par défaut j'espère ...), qu'ils ont "installé" iptables (iptables n'est pas un parefeu ... quid de l'ipv6 et des paramètres du noyau ?) et qu'ils utilisent la dernière version de php (l'ont ils configuré au moins ?).

Et lorsqu'on essaye de bien faire les chose, on se retrouve souvent avec des problèmes lors des mises à jour (la fameuse mise à jour qui casse tout ou la règle de sécu qui bloque la mise à jour). Trop souvent on fait le choix de laisser des trous (ou d'en créer) pour que ça fonctionne. Dans le cas des NAS, on fait confiance à une entreprise et à ses dizaines voir centaines de développeurs, admin, ingé, ... pour tester et empaqueter les mises à jour de manière à ce qu'elles ne cassent pas tout.

À un moment, il faut bien faire confiance sinon on n'avance pas.

<un peu hs>Linux par exemple (vraiment linux, le noyau), les sources sont dispo donc on peut le compiler soit même, mais parmi les rares utilisateurs qui compilent eux même leur noyau (je ne parle pas de arch ou gentoo, la compilation est pré mâchée), combien sont aller lire et contrôler l'ensemble des lignes de code. Admettons que certains l'aient fait (en pratique ce n'est humainement pas possible, c'est devenu trop gros), qui a lu le source de son compilateur et l'a compiler soit même (et avec quoi ?) ? On peut aller loin comme ça, dans l'absolu il faudrait graver soit même le processeur et tous les chip de la carte mère ... à la main car sinon on devrait faire confiance à la machine de gravure, à son électronique et ses logiciels ...</hs>

Au final, quelqu'un dont c'est le métier arrivera sans aucun doute à monter un système avec plein de fonctions et plus sécurisé qu'un nas grand publique mais pour la plupart des utilisateurs, c'est tout simplement mission impossible. Et pour les amateurs qui essaieront, il y a fort à parier qu'ils laisseront pleins de gros trous de sécurité par méconnaissance ou simplement par manque de temps (c'est comme ça qu'on se retrouve avec des millions d'appli "open" sur shodan).

Quelques exemples pour illustrer mes dires :

1. cherchez "apache authentification" dans votre moteur de recherche préféré
   • Les quasi totalité des liens va vous proposer de créer un .htaccess dans le dossier de votre application en ajoutant la directive "AllowOverride all" :
     • le .htaccess est quelque chose que même apache recommande de n'utiliser qu'en dernier recours
     • et quand bien même, pourquoi autoriser TOUTES les exceptions de configuration alors qu'un "AllowOverride AuthConfig" serait suffisant ?
2. cherchez maintenant : "installer apache php"
   • vous allez trouver à chaque fois libapache2-mod-php (ou un truc du genre)
     • le fait d'utiliser le module php compilé pour apache bride les performance de ce dernier
     • ça diminue aussi la sécurité et la stabilité de votre serveur (apache et php on les mêmes droits et se partagent le même espace mémoire)
     • et vous empêche de sécuriser vos applications (comme il n'y a qu'une seule instance php, toutes les applis se partagent les mêmes droits sur les fichiers, donc votre petite appli de test pourra aller lire les mots de passe de votre base de données dans la conf de votre CMS)
3. et pour ceux qui ont déjà installé un serveur web, combien ont ne serait ce qu'entendu parler des entêtes Content-Security-Policy, XSS-Protection, Referrer-Policy ?

Citation

Serveur home-made : ...

Citation

Sécurité: excellent

FAUX pour les raisons que j'ai expliqué avant, sauf à être du métier et à n'avoir que ça à faire

Citation

Cas du client mail

Il prend l'exemple des webmail mais comme son article est un peu vieux je passe ses critiques qui ne sont plus vraies pour la plupart, par contre il omet totalement d'indiquer qu'une webmail sans un serveur pour recevoir/envoyer (MTA) les mails et un autre pour gérer les boites ça ne sert à rien ! Et les groupware sont tout sauf sécurisés (même maintenant) et rarement compatible avec autre chose qu'eux même.

Citation

Le cas de la gestion des utilisateurs

Contrairement à ce qu'il indique, le problème n'est pas d'avoir un système centralisé de gestion des comptes et des droits, il en existe plein, mais d'arriver à ce que toutes les applications utilisent le même système ou (comble du luxe) fassent du SSO (SAML 2.0 par exemple). Sur ce dernier point, je vous souhaites bien du courage.

Citation

Conclusion

L'auto-hébergement est vital. C'est peut être long et fastidieux, mais c'est enrichissant, intéressant, en plus d'être gage de protection de la confidentialité.

Malheureusement, tant qu'on ne retrouvera pas la diversité des applications existantes avant l'avènement du cloud, et tant qu'elles ne conjugueront pas la simplicité des applications livrées avec les NAS avec l'exhaustivité typique des applications Libres, je crois que l'auto-hébergement (hors NAS) restera plus ou moins marginal, réservé à une population de connaisseurs, et par conséquent, et malgré les faits d'actualité, le commun des mortels ne pourra pas pleinement mesurer son importance.

Je partage en grande partie sa conclusion.

--------

ps : je viens de voir que la plupart des points que j'ai évoqué l'ont déjà été dans les commentaires de l’article

[pluton212+]

Salut,

mon avis est que les failles sont (à mon goût) patchées assez rapidement sur nos syno.

Ce sont les premières lignes de l'article qui m'ont fait réagir:

Citation

"Auto-hébergement et NAS

Sécurité: moyen
Simplicité: excellent
Fonctionnalités: bon, mais…"