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

Je n’ai pas eu besoin de corriger avec ceci…
Après j’ai eu un autre problème pour la migration de postgreql 9.6 vers 11
Effectivement on peut supprimer pour ne pas brouiller les pistes. Merci

Bonjour à tous,

Voici quelques news qui pourraient intéresser certains d’entre vous (en particulier @thomas :wink: )

Mon infra faisait gentiment son petit bonhomme de chemin quand il y a 3 semaines, bam… ma Livebox rend l’âme ! :sweat_smile: J’ai pris ça comme un signe du destin…

:zap: En effet, depuis le temps que la Livebox me fatigait (Hairpinning, plantages, DNS par défaut… :face_with_symbols_over_mouth: )… bref, il était temps de changer d’air !

Ni une ni deux, voici les modifications apportées :

Remarque : pour assurer une parfaite stabilité de la connexion derrière l’ONT, j’ai totalement désactivé l’IPv6 sur PFsense.

  • :white_check_mark: Mise en place d’un reverse proxy Squid pour le port 443 (j’avais un besoin spécifique métier depuis quelques semaines avec un accès nécessaire vers un autre serveur physique sur le 443, c’était donc l’occasion de faire d’une pierre deux coups ! :slight_smile:

Au niveau des modules actifs et réglages sur le Pfsense, voici ce que j’ai :

  • Activation de Snort sur le WAN (avec les règles qui vont bien) -> j’avais déjà un Suricata sur l’IPfire, je me suis dit que c’était l’occasion de tester en parallèle et de comparer… etc
  • C’est une habitude chez moi, seuls les ports strictement utiles sont autorisés en sortie sur tous mes serveurs (on peut débattre pendant des heures sur l’intérêt (ou pas) en terme de sécurité, mais croyez moi c’est un exercice formateur pédagogiquement, et cela aide à comprendre le fonctionnement de son réseau)
  • Configuration de Squid en reverse proxy en suivant ce tuto : https://www.it-connect.fr/reverse-proxy-https-avec-pfsense/

Au niveau de la machine utilisée, la première semaine, dans un 1er temps, le soir même, j’ai recyclé un ancien ultrabook pour assurer la fonctionnalité « connexion Internet » en urgence (déployer un Pfsense en urgence en IPv4 derrière un NT, c’est 20 min max clé en main). Au weekend, j’ai mis en place un serveur plus costaud que j’avais en stock (un peu surdimensionné d’ailleurs :joy: avec son Xeon, ses 16Go de Ram et ses petits disque de 300Go SAS… :crazy_face: )

Bon bref, ça tourne comme un charme, mais il me reste maintenant à configurer le module ACME du Pfsense pour gérer les certificats letsencrypt sur le port 443… mais rien d’urgent pour moi !

Bon weekend.
Sangokuss

Merci du ping et du retour d’expérience !
J’ai moi aussi remplacé ma Livebox par PFSense (https://www.notarobot.fr/2020/05/29/remplacer-la-livebox-orange-par-son-routeur/) et c’est on ne peut plus stable. Le seul problème étant de ne pas pouvoir bénéficier de l’IPv6 complètement .
Par contre en reverse proxy j’utilise Nginx dans un conteneur LXC sous Proxmox
Sinon je vois qu’on a la meme config( PFSense, Snort, Fibre Orange,etc…

Il me reste encore a rapatrier toute mon infra Yunhost de ma Dédibox vers mon Proxmox je ne m’y suis pas attelé encore, je bute sur la partie HTTPS que je veux gérer avec mon reverse proxy et non via Yunohost.

1 Like

Bonjour matinal,

Je me réponds à moi même :slight_smile:

Hier soir j’ai activé le plugin « acme » du bastion Pfsense pour gérer la mise en place du certification Letsencrypt sur le reverse proxy Squid et aucun souci en suivant ce tuto :
https://laskowski-tech.com/2017/12/04/acme-plugin-on-pfsense-add-lets-encrypt-cert-to-your-firewall/
(NB : choix DNS-Gandi-LiveDNS puisque mes noms de domaines sont chez eux)

Et ça fonctionne ! :sunglasses:
Bonne journée.
Sangokuss

Heureux que mon site t’ai aidé

1 Like

Edit: English Translation on demand! Feel free to ask :relaxed::relaxed:

Bonjour tout le monde,

Merci pour ce fil de discussion très intéressant sur Proxmox, Ynh, PfSense, etc. Je suis aussi sur Proxmox, avec en VM Yunohost, et PfSense. Mais en datacenter chez SoYouStart (OVH), car chez moi l’upload est bas (ADSL oblige).

J’utilise le nouveau serveur Proxmox Backup Server (en VM) + rsync du datastore vers un RaspBerry Pi + hdd à domicile. (A fiabiliser !)

J’ai un souci de renouvellement des certificats. Si l’un de vous a une idée, j’ai partagé ici mon problème : [✅Solved] Error renew certifcates (Let's Encrypt) - #2 by Sango

Belle journée :sun_behind_small_cloud: !!

2 Likes

Bonjour,

Comme on dit, il n’y a que les imbéciles qui ne changent pas d’avis :sweat_smile:
Bref, à l’occasion de la sortie de Proxmox Backup Server en version 1.0, je me suis finalement décidé à le tester.

La configuration est assez simple. Et l’ensemble est efficace.

J’y ai dédié mon serveur n°2 (ex-OpenMediaVault) avec un HDD pour le système et les 3 autres pour un espace en RaidZ1.

J’essaierai d’en faire un retex prochainement. :wink:

thanks for having me on this i feel great discussion is going on

1 Like

Bonjour à toutes et tous,

On me questionne parfois sur la sécurisation de mon Yunohost (au délà de l’infra décrite ci-dessus), donc voici quelques infos que j’ai posté sur le github Yunohost :slight_smile:

Pour résumer, l’utilisation de l’outil Lynis pour faire un audit général (:warning: c’est un outil indicatif, en aucun cas une solution ultime, hein :wink: ) permet de mettre en évidence quelques soucis simples à corriger.

Lynis renvoie un hardening index (sur 100) avec un code couleur simple : rouge en dessous de 60, orange jusque 79 et vert à partir de 80).

Donc :

  • audit avec lynis (à prendre avec recul),
  • réduction au strict minimum de l’installation et mises à jour rigoureuses,
  • umask à 077
  • /etc/fstab hardened
  • quelques modifs noyaux
  • interface admin uniquement accessible en local (mon serveur étant hébergé à la maison)
  • durcissement ssh

On obtient une bonne base ainsi :wink:

N’hésitez pas si vous avez des questions.
Sangokuss

1 Like

Salut,

Zute, j’avais pas vu ce sujet alors que j’ai (pour projet) d’avoir plus ou moins la même infra.
« Pour projet » car mon serveur Proxmox fait un tel boucan que je peux pas le laisser fonctionner la nuit ! Un nouveau ventilo arrive, en espérant que ça règle le problème.

Pour ceux que ça intéresse :
serveur Proxmox : ASRock Rack X570D4I-2T, AMD Ryzen 7 3700X, 16Go Ram, ssd 1To
Nas : Kobol Hellios64 avec 5HDD en RAID 5

Bref, j’aurais des petites questions sur des points où je doute encore :

  • as-tu des réseaux différents pour tes VM, ton serveur proxmox et les PC/Tablettes/telephones, ou tout est sur le même ?

  • Du coup c’est le Pfsense qui sert de DNS/DHCP ?

  • Je comprends pas bien l’organisation PFSense/Letsencrypt/Squid/Yunohost,
    Le certifica letsencrypt sur du Pfsense sert à quoi ? Il sert aussi pour Yunohost ou Squid redirige vers Yunohost en “pass through” ?

  • la VM yunohost est toujours en DMZ ?

  • c’est tout ton proxmox qui est en ZFS ou juste la VM Yunohost ?

Merci par avance pour les réponses.

Bonjour @gannonwoto ,

Je vais essayer de te répondre au mieux, dans l’ordre :

  • Mon Proxmox est dans un VLAN dédié (celui de ma DMZ publique), mais l’administration des VM/CT, et l’interface d’admin du PVE, sont limiter à une machine dédié (et pour info, les parefeux PVE et VM sont activés et aussi restrictifs que possible → seuls ne sont autorisés que les flux nécessaires) ;
  • Le Pfsense me sert de box mais pas seulement : il fait aussi office de reverse proxy sur le 443 (d’où le certificat lets encrypt :wink: et de filtrage geoip (seuls quelques pays sont acceptés) et d’IDS en mode IPS (un Snort pour être précis).
  • Derrière le pfsense se trouve un bastion IPfire qui lui délimite différents VLAN (DMZ, réseau filaire)
  • oui le Yunohost se trouve bien dans la DMZ (et possède un fail2ban associé à un portsentry)
  • c’est le proxmox qui est en ZFS, pas uniquement le Yunohost.

N’hésite pas si tu as d’autres questions.

Je ne connais pas IPfire, mais d’après ce que je peux lire c’est une alternative à PFsense. Tu pourrais pas tout gérer via PFSense ?
Ton réseau à plus ou moins cet aspect là, c’est cela ? (chaque branche derrière le IPfire étant un VLAN différent

En gros, oui.

Bonne remarque. C’est en effet un choix personnel et historique. Pour ma part, j’aime beaucoup Ipfire, moins pfsense. Mais le pfsense remplace ma box (pas l’ipfire…)…

Sinon, pas de Wifi en ce moment chez moi.

Bonsoir à toutes et tous,

Ayant un peu de temps libre ce soir, j’en profite pour prendre ma plume (numérique) pour vous raconter la suite des aventures de mon infra :slight_smile:

Tout d’abord, les évolution techniques :

  • télétravail obligeant pendant le dernier confinement, je ne souhaitais pas intégrer les postes dédiés à mon infra personnelle. Par conséquent, retour de la Box et placement du Pfsense dans la DMZ de celle-ci (les postes télétravail étant donc placés sur le réseau de la Box). C’est simple et efficace.
  • concernant mon réseau derrière le Pfsense, arrivée d’un nouvel hyperviseur Proxmox (base Dell R220) dans la DMZ (la vraie :wink: ) et protection du LAN réseau des machines desktop/workstation par un second bastion OPNsense (basé sur HardenedBSD) en lieu et place de l’IPfire.
  • l’accès aux services de ma DMZ se fait désormais en grande partie via OpenVPN et l’accès au Nextcloud de mon Yunohost se fait au travail du Proxy Inverse de mon Pfsense.
  • enfin, l’ensemble de l’infra est désormais équipé du SIEM Wazuh et une bascule vers une politique zéro-trust est bien amorcée.
    https://wazuh.com/
    Le modèle Zero Trust | Agence nationale de la sécurité des systèmes d'information

Voilà à quoi cela ressemble désormais (certains penserons peut-être que je ne devrais pas partager un tel document, mais (1) je trouve cela formateur (pour moi comme pour les autres) ; (2) il a déjà un peu évolué et (3) il ne contient pas plusieurs infos clés :wink: ) :

Bref, l’aventure est bien sympa et permets de tester/comprendre tout un tas de choses :sunglasses:
Les infos remontées par cette infra permettent également d’avoir une visibilité intéressante sur les attaques “classiques” (et parfois un peu moins) qu’elle subit et sur ses points faibles.

Si cela intéresse, je ferai une remontée de ces attaques prochainement :wink:

4 Likes

Ca intéresse :o

Ok, avec plaisir :wink:

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… :grimacing:), 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 :slight_smile:

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

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.
https://yunohost.org/en/security_team

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.

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é :sweat_smile: )

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 :wink:

Dans la suite, je vais essayer d’expliciter les menaces (les visibles, hein ! :sweat_smile:) 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 :

Capture d’écran de 2021-09-26 08-33-07

Là où cela devient intéressant, c’est lorsque qu’on jette un œil (les deux plutôt :joy:) 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 :joy: 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).

1 Like

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:

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.

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.

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é.

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

1 Like