Retour d'expérience : migration de mon infra sur Proxmox (VM)

[Sango]

Ok, avec plaisir

Je vous propose de faire cela par étapes, en plusieurs postes, au gré de mon temps libre. N’hésitez pas si vous avez des questions. Le tout en essayant de contextualiser avec la mise en place de mon infra.

NB : juste une petite remarque préalable sur laquelle il est bon d’insister, les bonnes pratiques ont toujours été respectées (mdp complexes, installation du strict nécessaire,…).

Bref, commençons par le début : comme beaucoup, lorsque Yunohost a été rendu public, j’ai rapidement voulu tester et, se faisant, la facilité et la richesse des applications de l’époque incitaient à parfois mutualiser, sur un même serveur, différents services. Pour ma part, il s’agissait de Nextcloud, TTRSS, WebAPP, Jirafeau et XXXX.

[Je ne reviens pas sur cet article : Auto-hébergement, fausse bonne idée - aeris | April (mais il est bon d’y jeter un œil).]

J’avoue qu’à l’époque, je n’avais pas étudié de près le code des applications (ni même le process de publication de ces apps… ), mais j’aurais dû ! Le serveur n’était d’ailleurs à ce moment là que placé dans la “DMZ” de ma box… et donc directement exposé aux bots, … à tout vent…

Il n’aura suffit que de quelques semaines pour que mon joli serveur Yunohost ait des soucis. La cause ? L’application XXXX victime d’une intrusion / détournement pour diffusion d’images pornographiques…
→ Observations : à priori, seule l’application en question avait été touchée. Du moins en apparence au regard de mes analyses de l’époque.
→ Moralité :

• première réinstallation complète (dans un cas comme celui-ci, ça ne se discute pas),
• réduction au strict minimum des applications et surtout, je jette désormais un œil au git de l’appli à installer avant (nombre de développeurs/commits/…),
• je n’expose plus publiquement les ports SSH et l’interface admin de mon Yunohost, ce qui réduit la surface d’attaque de manière sensible. Au début, j’avais choisis de n’administrer mon serveur qu’en local, puis avec le temps, j’ai mis en place un serveur VPN pour y accéder.

Vous me direz sans doute que ce n’était rien de bien grave (et vous n’auriez pas tords !), mais c’est bien la preuve que l’auto-hébergement nécessite une vigilance de tous les instants et une administration rigoureuse.

@suivre

EDIT: message édité par ljf pour des raisons de sécurité

[ljf]

@Sango

L’application XXXX victime d’une intrusion / détournement pour diffusion d’images pornographiques…

Il y a eu très peu de topic (ou d’email à security@) à propos d’instance de prod vérolées ou détournées jusqu’ici, ça se compte précisément sur les doigts d’une main. Il est encore temps, toi ou d’autres qui auraient des situations similaires à raconter, de nous envoyer un mail (chiffré ou pas) ou un mp histoire d’expliquer ce qu’il s’est passé exactement, afin que tout le monde puisse éventuellement bénéficier d’un correctif.

Security team | Yunohost Documentation

Ceci dit il reste possible que c’était un comportement normal de l’app en question, c’est pourquoi il faut discuter des détails exacts.

[Sango]

Bonjour @ljf ,

Tout d’abord, comme indiqué, il s’agit d’un évènement ancien qui, je l’espère a été corrigé (de mémoire, c’est le cas).
Ensuite, non, ce n’était pas un comportement normal (sinon, je n’en aurais pas parlé )

Enfin, il me paraît sain, sur un retex, d’en parler librement (lorsque l’évènement est passé). Je suis convaincu de l’intérêt, des bénéfices et de la solidité apportés par Yunohost, mais il ne faudrait pas non plus l’imaginer comme une forteresse imprenable.
Et à mon sens, le plus gros point faible vient justement des apps, dont il existe une grande variété, et que par défaut (comportement naturel), l’utilisateur lambda aura envie de déployer/installer, sans forcément penser aux conséquences.

Sans doute d’ailleurs qu’un indicateur de qualité (comme nous avions avant, mais qui devrait tenir compte de la sécurité évaluée) serait facilitant dans les choix.

Ceci n’est que mon avis

[Sango]

Dans la suite, je vais essayer d’expliciter les menaces (les visibles, hein ! ) auxquelles mon instance Yunohost est soumise.

Évidence (ou pas) à rappeler : les bots (quelques soient leurs origines et/ou objectifs) représentent clairement l’essentiel des requêtes non sollicitées.

Tout d’abord, comme précisé plus haut, mon instance Yunohost est uniquement à usage personnel. Par conséquence, je bloque les pays d’origine (via Pfsense) qui n’ont aucun intérêt pour mon usage. Plus précisément, seules les requêtes venant de FR, UK,US et DE sont acceptées (même si les US sont également de grands fournisseurs de bots).

L’origine géographique des requêtes est un premier filtre intéressant. Avec un tel premier filtre, les deux tiers des requêtes ne passent pas (parfois plus certains jours). Ici les données des dernières 24h :

Là où cela devient intéressant, c’est lorsque qu’on jette un œil (les deux plutôt ) au fichier /etc/hosts.deny du serveur Yunohost.

Rappel : mon bastion Pfsense filtre déjà pas mal de trucs, mais j’apprécie l’utilitaire Portsentry sur Debian/Yunohost qui va permettre de détecter les scans de ports. Pour le dire autrement, le Portsentry installé sur Yunohost fonctionne comme un second rideau de défense qui piège certains utilisateurs (ou bots) malveillants qui auraient passé le premier et qui ne s’attendent pas forcément à trouver ce genre de piège ensuite.

→ Lien : Portsentry — Le Wiki de debian-fr.xyz

Résultat : et bien certaines IP (rares, peut-être 1 à 2% max) d’origine normalement bloquée par le filtre Geoip passent tout de même et parviennent à scanner mon Yunohost (mais se font bannir par Portsentry du coup).

Moralité : la défense périmétrique a du plomb dans l’aile Plus sérieusement, ou pas, il convient de bien rester vigilant, et de durcir au mieux (en fonction de l’enjeu et de l’usage) chacune des machines, car tout le monde est une cible potentielle. Et de vrais attaquants motivés, il y en a ! (noyés au milieu des milliers de requêtes des bots).

[ljf]

Pour pas que tu es le doute, je tiens à préciser que je trouve ton topic très intéressant et je te remercie pour cette contrib’. Ceci étant dit, j’insiste sur le fait d’envoyer un mail à security@ , j’explique pourquoi:

@Sango

Tout d’abord, comme indiqué, il s’agit d’un évènement ancien qui, je l’espère a été corrigé (de mémoire, c’est le cas).

Peut être, mais il n’ y a jamais eu d’issue à ce sujet sur le paquet, ni d’annonce de sécurité, pas de titre de PR explicitent non plus, ni de discussion en réunion des contribs (j’en ai pas souvenir en tout cas). Ça ne veux pas dire que ce n’est pas corrigé, il se peut très bien que c’est une faiblesse générale du packaging de l’époque qui était exploitée, mais je pense qu’on (YunoHost) préférere savoir exactement quel était le soucis.

@Sango

Ensuite, non, ce n’était pas un comportement normal (sinon, je n’en aurais pas parlé )

J’ai dit ça parce que l’app en question a quand même des modules en lien avec la pornographie, donc ça serait possible que le détournement se base sur ça.

@Sango

Enfin, il me paraît sain, sur un retex, d’en parler librement (lorsque l’évènement est passé).

J’ai pas de soucis à ce qu’on parle librement de failles du passé, tant qu’elles sont bien dans le passé et qu’il y a plus trop de machines concernées. Si c’est pas le cas, alors faut tout de même faire gaffe et s’assurer que tout le monde puisse sécuriser sa machine à temps.
Donc le plus simple, c’est de nous expliquer d’abord l’histoire par mail, histoire qu’on soit sûr que c’est réglé.

@Sango

Je suis convaincu de l’intérêt, des bénéfices et de la solidité apportés par Yunohost, mais il ne faudrait pas non plus l’imaginer comme une forteresse imprenable.

J’ai pas dit le contraire, j’ai juste encouragé les personnes qui ont eues des soucis, à le signaler, de sorte que les contribs YunoHost aient une meilleure représentation des problèmes.

—> Security team | Yunohost Documentation

[Sango]

Bonjour,

Je poursuis ce soir la description des évènements rencontrés au quotidien sur mon infra ciblant (mais pas que !) mon instance Yunohost. Bien entendu, je souligne qu’ici je ne parlerai que des attaques et recherches de renseignements “agressifs” détectées par définition par mon bastion Pfsense (Parefeu, Proxy Inverse et Suricata) ou l’instance elle-même (rappelons que par définition, c’est généralement ce qu’on ne voit pas, ou que l’on voit trop tard, qui représente finalement le vrai danger !)

Bref, voici ce que j’ai recueillis :

• un grand nombre de scans d’IP classées comme malveillantes (par ex via AbuseIP) à la recherche de ports ouverts, de services exposés,… que du classique quoi !
• de nombreuses tentatives de connexions sur des ports ciblés classiques (SSH, HTTP/HTTPS,…),
  [NB : ces deux premiers items représentent 99% des remontées “agressives”]
• assez amusante, j’ai quelques tentatives de connexions ciblant des url précises (type wordpress, SPIP,…) basée sur mes différents noms de domaines, mais qui ne correspondent à aucun service déployés
• plus intéressantes, j’observe des tentative de connexion ciblant des url bien précises par exemple celle de l’interface admin du serveur ou celle de mon Nextcloud (qui dans mon cas n’est pas accessible / visible sur Shodan, Censys & cie, et qui n’est de toute façon pas accessible depuis l’extérieur).
  [Dans ces cas, rien de concret, les bonnes pratiques suffisent à stopper et bannir]

Autrement dit, parmi l’ensemble du visible par mes différents outils, il n’y a pas grand chose pour la grande majorité des évènements.

Moralité : pas franchement de quoi s’inquiéter donc, mais ce qui laisse en effet à penser qu’il vaut mieux tenir son infra exposée (et donc son Yunohost) rigoureusement à jour pour limiter les risques.

Prochain post, je vous ferai un retour plus précis sur un exemple d’IP m’ayant ciblé de manière beaucoup déterminée. Ce qui ne représente qu’une poignée d’IP motivées sur une année (sur 2021, je n’en ai repéré que 3 pour le moment), mais qui, forcément, représente une menace bien plus importantes que les autres alertes.

Bonne soirée

[prog-amateur]

Sur tout le topic, j’ai dû comprendre environ 40% à cause de mes connaissances réseau limitées (Proxmox, Shodan, et compagnie), mais je trouve la discussion vraiment très intéressante. Merci de partager ton retour d’expérience.

PS :

@Sango

Je me suis dit ce matin qu’une petite photo de l’infra serait sympa

à gauche, c’est bien un cluster de Raspberry pi ? tu bosses dans le domaine de la science de données ?

[Sango]

Bonjour @prog-amateur ,

Il ne faut pas hésiter à me questionner sur le vocabulaire. J’essaie de simplifier/vulgariser sans pour autant tomber dans l’écueil du “trop simple, donc trop éloigné de la réalité”, mais l’exercice, aussi sympathique soit-il, n’est pas toujours facile !

Pour répondre à tes deux questions :

1. Non, je n’utilise plus de RaspberryPi sur mon infra (en fait, il ne m’en reste plus qu’un, dans la DMZ privée, qui fait office de serveur multimédia Jellyfin). Je trouvais les débits réseaux trop faibles et surtout l’utilisation des micro-SD trop limitée → l’utilisation de vrais serveurs, qui m’ont permis de virtualiser mon Yunohost, …Etc a transformé l’expérience en facilitant grandement l’administration (et les tests associés)
2. Pour mon job : je suis prof de sciences à l’origine, actuellement en détachement ailleurs (mon profil précis n’est pas bien compliqué à trouver ).

Bonne journée,
Sango

[Sango]

Bon, je parle, je parle, … mais quelques images ça aussi aider parfois (en tout cas, ça aère un peu le post )

Ayant personnalisé hier l’interface de mon SIEM Wazuh avec un joli thème « dark » (ah les goût et les couleurs ), voici quelques captures d’écran de l’outil :

Ainsi que le thème que j’utilise pour mon interface ( GitHub - yunohost-themes/Yunohost_StarWars_Theme: Un thème inspiré de l'univers Lego Star Wars. )

[prog-amateur]

Après recherche, j’ai trouvé ton profil effectivement, ça fait plaisir de voir des professeurs engagés dans l’éveil des jeunes malgré certains choix contestables fait par l’éducation nationale.

J’ai également commencé à m’héberger avec un RockPi 64 (concurrent du Raspberry Pi 3B+) car il possédait 2GB de RAM (énorme à l’époque), et j’y ai installé NextcloudPi (je n’avais pas assez compris les possibilités qu’offraient Yunohost et j’avais aussi peur que l’OS soit abandonné quelques années après son lancement).

Si la machine fait vraiment bien le travail concernant quelques tâches quotidiennes (lecture vidéos, hébergeur de fichiers), en plus d’être économe en consommation énergétique, ça a été un peu frustrant lorsque j’ai voulu utiliser des documents office à plusieurs ou quelques applis non disponibles sur Nextcloud.

Yunohost a pour moi été comme une bouffée d’air frais, il est installé sur un serveur x86-64 Intel avec un disque SSD et 8GB de RAM permettant un confort et une rapidité impressionnante pour mes besoins, tout en restant économe en conso.

Mais qui sait… peut-être qu’au travers de ton topic, je découvrirai Proxmox et que ce sera la prochaine étape !

Intéressant ton graphique : le pic à 21:00 correspond à une série de tentative d’attaque (genre brute force par des bots, trackers, etc.) ? Si c’est le cas, c’est assez intéressant.

[Sango]

@prog-amateur

Après recherche, j’ai trouvé ton profil effectivement, ça fait plaisir de voir des professeurs engagés dans l’éveil des jeunes malgré certains choix contestables fait par l’éducation nationale.

Thx, j’ai fait de mon mieux à l’époque (même si je suis désormais pour qq temps (toujours peut-être !) par choix dans un ministère)

@prog-amateur

Intéressant ton graphique : le pic à 21:00 correspond à une série de tentative d’attaque (genre brute force par des bots, trackers, etc.) ? Si c’est le cas, c’est assez intéressant.

En effet, il s’agit d’une attaque (hors bot) un “peu construite” de type Scan puis brute forcing sur l’interface utilisateur de l’un de mes sites. L’attaquant a également tenté d’accéder à l’interface admin du site (non accessible depuis l’exterieur ).

En l’occurrence ici, le site est relativement solide et surtout l’attaquant ne s’était pas renseigné (tant mieux pour moi ) sur l’outil utilisé

[prog-amateur]

Promis ce n’était pas moi : trop peu compétent et je regardais le match de la Ligue des Champions à cette heure-ci ^^

Trêve de plaisanterie, c’est encore plus inquiétant que des êtres humains soient encore à la recherche d’attaque brute force. L’être humain n’a pas la rapidité d’exécution d’un bot, mais il possède un “flair” que ne possède pas le bot.

Voilà une bonne piqûre de rappel. Je ferais mieux de réfléchir à une stratégie efficace de protection pour mon serveur, même si je n’y héberge pas de données sensibles actuellement.

[Sango]

Bonsoir,

Petit poste de fin de week-end suite à la nouvelle évolution de mon infra. En effet, j’ai souhaitez amorcer une transition de mon serveur Yunohost, qui hébergeait dans sa dernière version uniquement trois services (xmpp, mails et Nextcloud), vers trois serveurs construits de zéro dans l’objectif de les isoler au mieux et ainsi gagner en flexibilité et sécurité.

[Juste avant suppression de mon Nextcloud, j’avais testé l’upgrade vers 22.2.3 sur le Yunohost et je vous confirme que tout a fonctionné parfaitement. Bravo à l’équipe Yunohost une nouvelle fois ! ]

Bref, je vous passe les détails, pour vous donner le résultat :

• aujourd’hui, sur mon Yunohost, seul le service XMPP est désormais utilisé (Nextcloud a été désinstallé et les ports du serveur mail fermés) → je souhaite mettre en place une VM OpenBSD dédiée à XMPP, mais pas eu encore le temps ;
• un container non privilégié Proxmox (Debian 11) a été créé pour déployer un beau Nextcloud tout neuf ;
• une VM OpenBSD 7.0 sur laquelle j’ai déployé mon serveur mail (pas simple, mais le résultat est vraiment sympa et solide).

Bref, je m’émancipe peu à peu de mon Yunohost

Sangokuss.

[Sango]

Bonjour à toutes et tous,

Et voilà, c’est officiel, je viens de couper mon serveur Yunohost !

Comme vous le savez, j’avais amorcé une migration de chacun des services et j’ai enfin eu le temps de finaliser mes migrations. Bref, voici donc ce que ça donne au final :

• serveur mail (base OpenBSD 7.0 / Postfix - Dovecot)
• serveur XMPP (base Debian 11 / Prosody)
• serveur Nextcloud (base Debian 11 / Nextcloud -PostgreSQL)
• serveur web (base OpenBSD 7.0 / httpd - php)

Tous ces serveurs sont durcis au mieux (certains diront peut-être “au moins pire” ) et mon premier retour est finalement le suivant : il est bien pratique pour les administrer d’avoir séparer les services dans des VM distinctes. Et franchement, ça ne consomme pas vraiment plus de RAM, chaque serveur étant assez bien optimisé.

Bref, me voici un adminsys heureux. Si Yunohost m’aura permis d’héberger certains de mes services pendant pas mal d’années, il faut savoir qu’il y a comme un petit sentiment de liberté à s’en émanciper définitivement.

Encore merci aux devs, contributeurs, etc pour le travail accompli (qui m’ont fait gagner pas mal de temps au quotidien pendant des années ). Je souhaite le meilleur à toute l’équipe (et resterai présent sur forum pour suivre l’évolution du projet, bien entendu, et continuer d’échanger !).

Sangokuss.

[nvrcx]

Moi qui m’apprête à me lancer dans l’aventure avec Yunohost, ça me fait presque réfléchir

Est-ce bien judicieux de commencer sur une voie pour changer ensuite ? Pourquoi ne pas directement partir vers une solution similaire à la tienne @Sango ?

Que me conseille la communauté Yuno ?

Je suis débutant.

[Sango]

Bonjour @nvrcx,

Selon moi, je dirais que tout dépend du temps que tu es prêt à consacrer à l’administration de tes serveurs et de tes compétences techniques.
A titre d’exemple, gérer son propre serveur mail est… comment dire… une expérience chronophage et technique ! (certains diront « un vrai merdier ! » )

En indiquant que tu te positionnes comme « débutant », je te conseille de commencer par Yunohost pendant quelques temps puis lorsque tu te sentiras à l’aise, tu pourras (ou auras l’envie) de monter d’autres services distincts. Et, petit à petit, l’adminsys fait son nid

Sangokuss.

[nvrcx]

Tout à fait, ça fait du sens. Merci pour ta réponse.

[nath5394]

J’ai le même conseil, commence par yunohost c’est top pour débuter, on a vite un résultat satisfaisant (des services en ligne qui marche), et si on est curieux on peut voir comment tout est configuré ce n’est pas du tout une boite noire, bien au contraire.

[Sango]

Bonjour à tous,

Pour ceux que cela intéresse, j’ai commencé la rédaction d’un wiki qui rassemble mes notes sur mon infra et la manière dont j’utilise mes différentes machines (cloisonnement, hardening, etc) : https://www.svtux.fr/
C’est encore en cours de rédaction, tout n’y est pas, et c’est parfois encore très brouillon, merci d’avance pour votre compréhension

Sangokuss

[polochon]

@Sango ton lien semble cassé
Sinon, je suis en train de migrer de serveur et je me disais: pourquoi ne pas essayer proxmox?
J’ai commencé par installer une VM debian. Le 1er truc qui me chiffone ce sont les VM qui sont connectées en mode NAT. Avec une IP qui va changer j’imagine, et du coup je me dis “mais comment je fais pour faire la redirection de port proprement dans ma freebox avec ça?”.
Si quelqu’un a un tuto qui explique comment bien faire les choses, je suis preneur.
Thanks!