Visibilité de yunohost par shodan

Bonjour
En pleine dé-googlisation je me documente un peu sur l’auto-hébergement.
Je suis sur le point de m’essayer à yunohost “pour voir”.

Je suis tombé sur cet article : https://april.org/auto-hebergement-fausse-bonne-idee-aeris
Qui soulève ce point :

Le genre d’exemple qu’on peut voir aujourd’hui : il y a Shodan9 qui est une interface qui scanne l’intégralité du réseau. Tous les jours IPv4 est passé à la moulinette sur l’intégralité des IP, l’intégralité des ports. C’est entièrement publié sur Internet ; il y a une base de données, vous pouvez faire des recherches dedans. Aujourd’hui, vous tapez « yunohost/admin », vous avez 1113 instances YunoHost qui tournent et vous pouvez les lister. Donc si jamais il y a une faille de sécurité dans YunoHost, vous avez 24 heures pour mettre à jour, sinon Shodan, vous vous le prenez dans la tronche et votre machine est infectée immédiatement.

Et suggère ceci afin de s’en prémunir :

Sur les machines, il faut mettre un vhost Nginx ou Apache par défaut qui serve une page vide, et ne pas mettre un vhost, NextCloud ou Cozy Cloud ou autre, spécifique. Comme ça, quand Shodan passe, il va tomber sur le port 443 par défaut, il va tomber sur le vhost par défaut puisqu’il ne connaît pas le nom de domaine, donc il va avoir la page «Hello world ou It works» en fonction de votre système. Mais ça veut dire qu’il faut que l’utilisateur renseigne un nom de domaine, ça veut dire qu’il faut qu’il renseigne une adresse IP.

Qu’en pensez-vous ?
Et comment faire pour configurer ainsi Nginx ?

Perso je suis assez sceptique par rapport à tout ce qui est décrit dans l’article. Forcément je suis biaisé car je suis dans la team de développement de YunoHost.

Mais l’essentiel de l’article se limite à présenter la complexité de l’informatique comme une fatalité, et que donc “cherche pas, c’est trop compliqué, il faut des gens avec de l’expertise pour faire les choses à la main sinon ça cassera” et que l’UX et la sécurité sont soit-disant des concepts incompatibles…

Pourtant, on travaille tous les jours avec des systèmes qui sont extrèmement compliqués mais sur lesquels on a réussi à construire des abstractions pour cacher cette complexité. Par exemple : ton ordinateur est un condensé d’électronique qui pourrait avoir 1000 raisons de tomber en panne chaque heure qui passe. Pourtant, moins de 0.1% des utilisateurs d’ordinateurs sauraient mettre en pratique la loi d’Ohm et utiliser un fer à souder. Au final, l’abstraction a été tellement paufinée et rendue robuste qu’il n’est plus nécessaire de savoir comment un ordinateur fonctionne au niveau hardware pour s’en servir et le maintenir. On peut voir ça comme une “perte” et on peut souhaiter que les gens devraient connaitre le fonctionnement des ordinateurs plutôt que de les “consommer”, mais il est illusoire de demander aux gens d’avoir un PhD en electronique pour “juste” utiliser un ordinateur.

Actuellement la situation de l’auto-hébergement est similaire à avant la démocratisation des ordinateurs, ou avant l’apparition des premières distro linux “grand public” comme Ubuntu. Il y a une tonne de travail en administration système qui est répétitif, compliqué et fait à la main pour la seule raison qu’il n’y a pas d’environnement standard et que peu de personnes ont cherché à automatiser les choses et à les rendres accessibles pour les profanes.

Bref. Sur le point Shodan spécifiquement :

Donc si jamais il y a une faille de sécurité dans YunoHost, vous avez 24 heures pour mettre à jour, sinon Shodan, vous vous le prenez dans la tronche et votre machine est infectée immédiatement.

Oui, l’interface d’admin est une surface d’attaque supplémentaire. Mais c’est loin d’être la seule. Sur Internet, les serveurs exposent typiquement du SSH, du HTTP(S), du mail, et d’autres choses. Donc cette remarque à propos de YunoHost est aussi valable pour des tonnes de grosses brique comme OpenSSH, SSL, nginx, apache, postfix, dovecot, Debian, PHP, … ou des applications web très répandues comme Wordpress ou Phpmyadmin.

Au final, cette remarque qui vise YunoHost est applicable à tout en général, et peut être résumé de la manière suivante : si tu met un serveur ou un service en ligne, il devient attaquable par n’importe qui. Certes. Est-ce que l’on va éteindre Internet pour autant, parce qu’au final, au premier 0-day concernant SSH, tout l’Internet se transforme en botnet …? En pratique, les failles qui permettent vraiment de rooter des machines par millier en un claquement de doigt ne sont pas légions…

On peut certes brouiller les pistes tel que suggéré, et il serait souhaitable qu’un tel mécanisme soit implémenté par défaut dans YunoHost, mais il faut aussi nuancer le risque avec le fait que (hypothétiquement) rooter 1000 machines me parrait à l’heure actuelle relativement peu intéressant pour un attaquant, comparé à du Wordpress ou du phpmyadmin où il y a un password bidon…

Imho, la vraie solution est à chercher dans le fait de :

  • avoir des vrais audits de sécurité sur les différentes surfaces d’attaques présentes sur un serveur YunoHost ;
  • avoir des temps de réaction raisonnable en cas de révelation de faille de sécurité critique (et possiblement des mises à jour automatiques dans le cas de faille de sécu).

Bref :wink:

Si tu veux vraiment bidouiller ça, je pense qu’il faut regarder dans /etc/nginx/conf.d/yunohost_admin.conf et tu devrais voir une ligne comme ça : https://github.com/YunoHost/yunohost/blob/unstable/data/templates/nginx/plain/yunohost_admin.conf#L53 qui corresponds à la redirection automatique vers /yunohost/admin.

Apriori ce comportement est souhaitable pour que, tant que le nom de domaine n’est pas encore correctement configuré (ou si il n’est plus bien configuré) l’utilisateur puisse tout de même avoir accès à l’interface d’admin juste avec l’IP. Peut-être qu’une solution pour ne pas leaker l’existence de ce /yunohost/admin automatiquement serait d’effectuer ce genre de redirection seulement pour des connexions en réseau local par exemple (et d’interdire son accès si l’on ne connait que l’IP…)

Mais si on creuse la question plus loin, on peut aussi se dire qu’avec les histoires de transparences des autorités de certifications sur l’émission des certificats (et notamment Lets Encrypt), il doit aussi être possible d’établir une liste des noms de domaines qui existent dans la nature :wink: .

5 Likes

merci @Aleks :slight_smile:
Des fois je me demande si vous n êtes pas plusieurs derrière ce compte tellement la variété des réponses et des contenus s’invitent à chacune de tes interventions.

Construire la sécurité dynamique des infrastructures dans une approche système est toujours difficile et quasi évolutive à chaque instant. L argumentaire d’Aeris est juste mais reste valable que dans un contexte d habituation de la sécurité des serveurs.

Yunohost est même dans sa prime jeunesse un outil qui tient la route mais demande effectivement des compétences pour qui l’utilise…et encore elle reste très minime au vu de la qualité du produit et du coût de développement ou de production pour qui veut accéder à l auto-hébergement et une forme de liberté.

Merci à la team Yunohost.

NB et rajout:…en sécurité le maillon faible reste l humain.

4 Likes

Merci pour vos réponses constructives ! Sujet complexe…

Quoiqu’il en soit j’ai un rpi sur le bureau et une sd et un image yunohost ! En route pour l’aventure !!
J’en profite pour remercier tous les humains derrière leurs claviers qui font vivre ce projet :slight_smile:

2 Likes

Je suis très loin d’être un expert en sécurité mais l’argumentaire d’Aeris me semble en effet un peu biaisé. Merci @Aleks pour cette petite mise au point.

Il ne faut pas non plus oublier que chez les GAFAM (et ici en Chine, les NATU, qui sont bien pires encore!) les piratages de comptes sont légion (je ne parle même pas du plus indiscret de tous, le fournisseur de service lui-même)

Ce comportement est souhaitable et m’a déjà sauvé plusieurs fois !
L’enlever poserait également des problèmes à ceux qui, comme moi, on choisit un “demi” auto-hébergement en plaçant leur instance sur un VPS chez un fournisseur tiers.

@xyleme tu ne regretteras pas d’avoir essayé Yunohost. Je trouve qu’il apporte un compromis idéal entre facilité d’usage pour le grand public (bon, je dirais plus le public qui a quelques connaissances basiques ou un ami qui s’y connaît) et souplesse pour les “power users” qui peuvent même s’essayer à packager pour faire bénéficier la communauté de leurs avancées.

3 Likes

Merci pour ton retour !
Je ne doute pas que je vais bien m’entendre avec Yunohost ! Le seul frein sera mon adsl rural (7méga… autant que lorsque j’étais en zone encore plus rurale en wimax…)… L’idée c’est déjà de tester et peut-être de passer sur un vps.
A suivre, merci pour l’accueil !

Est-il possible d’avoir dans le panel d’administration une option qui permettent de limiter cet accès au panneau d’administration à une adresse précise ? Tel qu’un sous-domaine par exemple ?

Pour me faciliter la vie, par exemple, mon Dns indique *.host.truc -> adresse IP.
Ce qui fait que n’importe quelle adresse erronnée emmène sur le panel. :scream:

C’est un choix personnel ce DNS, bien entendu, mais un accès limité, en option, serait cool. :blush:

Je ne lis pas le git (j’y comprends pas grand chose encore), mais peut-être l’issue y est déjà reportée ?

Merci à tous.

Si tu (ou quelqu’un d’autre) se charge de l’implémenter, oui pourquoi pas ¯\_(ツ)_/¯

J’ai l’impression que le soucis n’est pas lié au nom de domaine ? J’ai l’impression qu’il est lié au fait que si tu accèdes à 11.22.33.44 (ton adresse ip) alors tu es redirigé vers 11.22.33.44/yunohost/admin. Ce qui a un aspect pratique quand tu es nouveau, car tu peux simplement dire aux gens d’aller sur l’ip locale, et pas sur l’ip locale / yunohost / admin …

Le problème est même peut-être directement dans le fait que 11.22.33.44/yunohost/admin est une adresse qui fonctionne sur un instance yunohost, et donc de déduire implicitement que le serveur est un serveur yunohost … et là c’est encore plus compliqué d’un point de vue utilisateur de retirer cette fonctionnalité, car c’est souvent bien utile pour dépanner un serveur qui n’a pas de nom de domaine fonctionnel …

En bref ça me semble pas être un problème facile à résoudre. Mais avant ça il faut aussi se demander dans quelle mesure c’est un vrai problème que ton instance soit listable via Shodan … Perso je trouve que c’est peine perdue de vouloir se cacher de Shodan ou de systèmes similaires : a partir du moment où tu as un serveur, il est exposé, et les gens pourront trouver un moyen de connaitre ton nom de domaine et/ou ton OS.

La vraie solution imho, plus compliquée, elle se trouve dans le fait d’avoir des briques logicielles auditée et maintenue à jour, et un temps de réaction rapide de la part des devs / de la commauté. Et on a bien vu avec des cas comme Heartbleed que certaines ne le sont pas assez, en comparaison de leur utilisation généralisée dans les internettes mondiales. Il n’y a pas de “silver bullet” technique qui permette de résoudre le problème : il faut des êtres humains qui investissent du temps (et/ou de l’argent pour acheter ce temps) pour investiguer et corriger les différents problèmes de sécurité des apps ou du core (e.g. est-ce que fail2ban couvre tout ce qu’il y a à couvrir), implémenter une détection automatique des mots de passe faible, etc…

J’aime beaucoup cette réponse. Comme la fois précédente, je réponds que je verrai cet été, quand je serai en vacances et que j’aurai plus de temps. :blush:

Heu, mais du coup, mon option ne sert à rien… je verrai bien cet été je suppose en farfouillant les codes.

Là je ne te suis plus. Comment peut-on avoir un panel de contrôle hors de l’instance ? Tu veux en faire une app séparée ?

Pour moi le problème est surtout le petit malin qui voudra tenter de craquer un mdp pour montrer qu’il peut y arriver… ou l’étourdit qui va choisir un mdp facile à trouver.
Après, je peux le limiter, ce problème, en modifiant ma politique de dns et enlevant le sous-domaine “*”.

Salut,
I think that Aleks thinks to put a random url like /yunohost/admin146444646789 for example that only the admin knows

Je pense plutôt qu’Aleks pense… (désolé pour la tournure de phrase) que tu pourrais par exemple mettre une url aléatoire connu uniquement par l’administrateur, lors de l’installation.

1 Like

Comme Alex a suggéré, j’ai personnellement changé le redirect ici https://github.com/YunoHost/yunohost/blob/unstable/data/templates/nginx/plain/yunohost_admin.conf#L60 en google.com
Comme ça si un petit curieux tappe mon IP directement il se fait GAFAMiser plutôt que de découvrir que j’utilise YunoHost …
Même si j’avoue qu’une redirection vers yunohost.org serait plus en accord avec les principes :grinning:

1 Like

Pourquoi tu ne le diriges pas sur Qwant (ou autres navigateurs) ou Yunohost ? ce serait plus cool. :wink:

Où se trouve ce fichier ?

Perso taper mon ip renvoie vers un message " Welcome to nginx! […]"

Si je tape ip/yunohost/admin, j’ai le pacman infini (j’avais bidouillé un truc pour que la page admin ne soit joignable que par le réseau local).

(ce serait cool de poser ta question dans un nouveau topic car ton problème n’a rien à voir avec le fil initial qui date de 2018 …)